Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
Linux Kernel Security, Again
Jason Miller, 2005-03-16

It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.

Comments Mode:
silly article 2005-03-17
Anonymous (4 replies)
silly article 2005-03-18
Anonymous
silly response 2005-03-18
Anonymous
silly comment 2005-03-18
Anonymous (1 replies)
silly article 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-17
Karyl Stein (1 replies)
Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-17
Anonymous (3 replies)
Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (3 replies)
Linux Kernel Security, Again 2005-03-17
mrsad (1 replies)
Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)
Linux Kernel Security, Again 2005-03-18
Anonymous (2 replies)
Linux Kernel Security, Again 2005-03-18
crf (2 replies)
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-20
Anonymous
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-19
CrossChris
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Anonymous
simple fork bomb? 2005-03-17
Anonymous (1 replies)
simple fork bomb? 2005-03-17
Jason V. Miller (Author) (3 replies)
simple fork bomb? 2005-03-17
Anonymous
simple fork bomb? 2005-03-17
Anonymous (1 replies)
"No, they weren't."

Then don't blame the distribution or the kernel.

Vendors DON'T have any way to know how you want to use the system. They can ask basic questions - "do you want Server, Workstation, user, minimum..."

Most people on a workstation take responsibility for overload/oversubscribed resources.

On a server - You SHOULD decide how much to support for YOUR workload. Vendors cannot determine that.

I HAVE crashed (as in down for the reboot) even Solaris 9 with such misconfigurations. What was the "default"? 27GB process memory limit... The default process limit... 16K (computed based on the fact that the server had 64 processors and 128GB of memory).
Now, how big is the swap/page file... 6 GB. Just barely enough to dump the Kernel + IO queues.

Guess what... a single user CAN crash the system: 16K * 27GB = 432000GB of memory. Which is WAY oversubscribed for 6GB+128GB or 134GB of usable memory.

So immediately afterward (well, after the hour it took to reboot) the user process limit was dropped to 4K. Still not enough, but it WAS enough to catch the fork bomb before all of memory got consumed. Swap space got bigger too... 128GB got allocated shortly after that episode - Still not enough, but it got through the existing work load.

BTW - you ALSO need to turn on "no oversubscription of memory" to prevent the above crash too..

ANY default configured system can be crashed/DOSed when it is operated OUTSIDE of the planned workload. (ESPECIALLY if you exceed the available memory).

This is true of every UNIX/Linus system in existance.

1. Nobody wants to be memory limited - without oversubscription, you need 2-3 times the normal amount of physical memory + swap space. Disabling oversubscription means that the kernel must assume that every fork will require a complete duplicate of the original process memory space. Even if it is only forking to do an exec of a different program image. The specific message that shows up on most systems is "cannot fork - no memory"

2. Nobody wants to see "cannot fork" messages for the same reason. "cannot fork - no process space", though usually it just says "no memory" because that is simpler to explain; and is true from a certain point of view - memory for an additional process slot is not available.

3. Since people are NOT willing to spend the money to guarantee no resource starvation occurs, they MUST accept the occasional hang.

"It took three hours for a root login..."

So your system wasn't down. It didn't crash. It WAS a DOS, but obviously a preventable one had the resource limits been restricted to what you could physically support.


[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/308/30979#30979
simple fork bomb? 2005-03-17
Jason V. Miller (Author) (1 replies)
simple fork bomb? 2005-03-18
Stephen Samuel (3 replies)
simple fork bomb? 2005-03-18
Eric F.
simple fork bomb? 2005-03-18
Michael Ayres
simple fork bomb? 2005-03-20
Anonymous
simple fork bomb? 2005-03-20
Anonymous
Linux Kernel Security, Again 2005-03-17
Todd Knarr
Intended use dictates the limits 2005-03-17
Erik Keller (1 replies)
Intended use dictates the limits 2005-03-17
Jason V. Miller (Author) (4 replies)
Intended use dictates the limits 2005-03-18
Erik Keller (1 replies)
Maybe just use proper distros where needed? 2005-03-20
Michael Shigorin
Intended use dictates the limits 2005-03-23
Anonymous
Linux Kernel Security, Again 2005-03-17
Anonymous (2 replies)
Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)
LSM is in the standard kernel. 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Anonymous (1 replies)
Linux Kernel Security, Again 2005-03-18
Anonymous (1 replies)
Linux Kernel Security, Again 2005-03-19
PaX Team
Once again... 2005-03-18
Anonymous (1 replies)
re: Once again... 2005-03-18
editor
Debian not vulnerable? 2005-03-18
Wilmer van der Gaast (2 replies)
Debian not vulnerable? 2005-03-18
k_the_c
Debian not vulnerable? 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Matthew
Linux Kernel Security, Again 2005-03-18
Gentoo User (1 replies)
Linux Kernel Security, Again 2005-03-18
Another Gentoo User (2 replies)
Linux Kernel Security, Again 2005-03-18
Gentoo/Debian/OpenBSD user (1 replies)
Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)
Linux Kernel Security, Again 2005-03-18
FreeBSD user (2 replies)
Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)
Debian IS vulnerable! 2005-03-18
Anonymous (2 replies)
Debian IS vulnerable! 2005-03-18
Anonymous
Debian IS vulnerable! 2005-03-18
Anonymous (2 replies)
Get SuSE 2005-03-18
Anonymous
Debian IS vulnerable! 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Gentoo User
Linux Kernel Security, Again 2005-03-18
Anonymous
Linux Kernel Security, Again 2005-03-18
Angel Freire
Gentoo vulnerable? 2005-03-18
Anonymous (1 replies)
Gentoo vulnerable? 2005-03-18
dk
Linux Kernel Security, Again 2005-03-18
Saltine (1 replies)
Linux Kernel Security, Again 2005-03-20
Anonymous
Linux Kernel Security, Again 2005-03-18
Stef (1 replies)
Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)
Jason's opinion is too biased 2005-03-18
Anonymous (2 replies)
Jason's opinion is too biased 2005-03-18
Anonymous
Jason's opinion is too biased 2005-03-18
Jason V. Miller (Author) (1 replies)
Jason's opinion is too biased 2005-03-23
Anonymous
Linux Kernel Security, Again 2005-03-18
Anonymous
Take the first step author. 2005-03-18
EG (2 replies)
Take the first step author. 2005-03-18
Anonymous (1 replies)
Take the first step author. 2005-03-18
Anonymous
Take the first step author. 2005-03-18
Jason V. Miller (Author)
Solution was?... 2005-03-18
Anonymous (2 replies)
Solution was?... 2005-03-18
Anonymous
Solution was?... 2005-03-19
Anonymous
Not quite a valid criticism... 2005-03-18
Anonymous (2 replies)
Not quite a valid criticism... 2005-03-20
darwin lopez
Not quite a valid criticism... 2005-03-20
Anonymous
Silly IDS kid needs to learn C. 2005-03-19
OpenBSD is for Girls
Linux Kernel Security, Again 2005-03-19
Anonymous
Linux Kernel Security, Again 2005-03-19
Anonymous
Linux Kernel Security 2005-03-19
Anonymous
Does it work on Mac OS X? 2005-03-19
huwr
Fresh FreeBSD 5.3 install 2005-03-20
Anonymous
Try, disk I/O and mem. alloc 2005-03-20
Bipin Gautam
Solaris 10 vulnerable, too 2005-03-20
Anonymous
Why its Valid! 2005-03-21
Anonymous
Mandrake 10.1 didn't freeze... 2005-03-21
Anonymous
DEBIAN 2005-03-21
Anonymous (1 replies)
DEBIAN 2005-03-22
Anonymous (1 replies)
DEBIAN 2005-03-23
Lucio
Linux Kernel Security, Again 2005-03-23
Anonymous
Linux Kernel Security, Again 2005-03-24
Anonymous
PAM 2005-03-24
Maestr0
Linux Kernel Security, Again 2005-03-28
Anonymous
Linux Kernel Security, Again 2005-03-29
Anonymous







 

Privacy Statement
Copyright 2009, SecurityFocus