« Track Traffic With Webalizer | Main | Lame Journalism 102 »

March 22, 2005

Lame Journalism 101

Well it seems that not everybody at Security Focus should be writing about Security: this article, Linux Kernel Security, Again breathlessly talks about how Linux is "vulnerable" to the venerable fork bomb and takes Linux distributions to tasks for not "doing something" about it.

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

Background: In *ix of all kinds, new processes are created with the fork() system call (more or less like CreateProcess() in Win32), and a "fork bomb" is a program (shell script or C code) that does nothing but recursively launch copies of itself over and over. Eventually this fills up the process table, and it's long been an effective way to drop a machine because you have to kill all of the forkbomb processes at the same time (they keep respawning themselves).

It's so easy to do that friends do it to friends all the time. Ha ha ha.

This is a local denial-of-service attack, and all systems provide ways of limiting this behavior: max # of overall processes, per-user limits on process creation, and reservation of the last process slot for root, who presumably is going to run the "shutdown" command to make it all go away. "ulimit" is the admin's friend for this.

Jason chastises Linux vendors for shipping with unreasonably high defaults:

Said by article:
Even though a local user should be somewhat trusted, that doesn't mean you should hand them a silver platter with the ability to take down the entire machine.

It's not really a silly argument until one looks at the wider picture: this is just a single example of a local resource-exhaustion attack, of which the fork bomb is just one. There is also the "disk space bomb", a "CPU bomb" or a "memory bomb". I can think of at least three more, and surely others can too.

But only the fork bomb warrants this special attention? By Jason's reasoning, shouldn't disk quotas be enabled by default? After all, how hard could it be to pick a reasonable quota that applies to everybody out of the box?

When a user has the ability to consume a resource, he can abuse that resource, and I challenge anyone to come up with a broad set of default options works for everybody in limiting bad stuff but not the good stuff.

This is the classic "security versus usability" tradeoff, but unlike the Windows-insecure-by-default that many of us have noted, resource-exhaustion attacks are second-level attacks that are achieved by users who are already on the box (and "compromise" doesn't mean that you have to flatten your box).

If valid users are doing this, you RTFM, tune the limits and/or kick them off the system, and move on. If launched by an unauthorized user, then you have security issues a lot deeper than running out of process slots.

But there is no set of limits that works for everybody, and leaving them for the admin of the box seems perfectly reasonably to me. He suggests that BSD has picked some reasonable limits, but if he gives me fifteen minutes on his box with a C compiler, I'll drop it. There are lots of resources to exhaust (syslog bomb, anyone?).

I am dramatically more concerned about what unauthorized users are doing on my boxes than I am about the authorized ones, and "local denial of service attacks" are very low on my list of concerns. In more than 20 years of commercial system administration across a wide range of enterprises, I have yet to come across a customer with a hostile local user that required these ameliorations. Not even one.

Justin put this really well:

the issue is really only of concern to administrators who run multi-user boxes with shell access in tough environments... and they have probably been more than aware of the various resource limits necessary to keep things running safely, for ages.

The author could have written a perfectly useful article that addressed how to deal with local resource tuning - I suspect most *ix users don't even know such things exist - but instead resorted to sensationalism about a legitimate tradeoff that has been made for decades.

It is indeed a sad day: for technology journalism.

Posted by steve at March 22, 2005 07:41 AM

Trackback Pings

TrackBack URL for this entry:
http://www.unixwiz.net/mt/trackback/30

Comments