, 2005-03-16
It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.
Expand all |
Post comment
silly article
2005-03-17
Anonymous (4 replies)
Anonymous (4 replies)
silly article
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-17
Karyl Stein (1 replies)
Karyl Stein (1 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (3 replies)
Anonymous (3 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (3 replies)
Jason V. Miller (Author) (3 replies)
Linux Kernel Security, Again
2005-03-17
mrsad (1 replies)
mrsad (1 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
simple fork bomb?
2005-03-17
Anonymous (1 replies)
Anonymous (1 replies)
Intended use dictates the limits
2005-03-17
Erik Keller (1 replies)
Erik Keller (1 replies)
Intended use dictates the limits
2005-03-17
Jason V. Miller (Author) (4 replies)
Jason V. Miller (Author) (4 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (2 replies)
Anonymous (2 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-18
Gentoo User (1 replies)
Gentoo User (1 replies)
Linux Kernel Security, Again
2005-03-18
Another Gentoo User (2 replies)
Another Gentoo User (2 replies)
Debian IS vulnerable!
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Linux only? perhaps across the board problem? Conflict of interest?
2005-03-18
glotfeltys@gmail.com (1 replies)
glotfeltys@gmail.com (1 replies)
Jason's opinion is too biased
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Take the first step author.
2005-03-18
EG (2 replies)
EG (2 replies)

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