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


"...I hope that anyone out there running Linux is just as surprised as I was that this ancient attack still works on the default installation of so many high profile Linux distributions."


While investigating some reports of recent Unix compromises, I ran into a message from the SecurityFocus Incidents mailing list that was forwarded to me by the moderator, Daniel Hanson. It was a lengthy post detailing the compromise of a Linux machine. The post contained an awkward IRC-based discussion between the server administrator and the guy who had broke into the machine.

Reading through this discussion, I discovered the following exchange which immediately piqued my interest:

[15:16:53] but I mean, I could have killed ur box
[15:17:04] no, you couldn't have.
[15:17:08] wanna bet ?
[15:17:27] forkbomb it

I'll admit that I thought his statement was pretty funny. How did this guy expect to bring down a Linux machine by fork bombing it as a non-root user? Not being as intimately familiar with the various Linux distributions as I am with the three BSDs, I figured that I'd have a quick peek into his claim and see what happens.

I wrote up a very simple bourne shell script on my work machine, which runs Mandrake Linux, and executed it under my non-privileged account. Within seconds, the machine was brought to its knees -- totally crippled and unusable. I stared at my screen in disbelief for a few moments, totally stunned with what had just happened.

After the deer-in-headlights look had left my face, I gave my head a shake and started to question my belief that none of the BSD machines that I administer were susceptible to this truly ancient attack. I'll admit that I held my breath for a few seconds as I keyed the script into my NetBSD laptop, and then ran it. I was pleasantly surprised when the attack had no effect, confirming that I wasn't losing my mind after all -- limits had been put in place to prevent a normal user from crippling the entire system. Exactly as one would expect.

I then proceeded to fork bomb every Unix machine I could get my hands on. My FreeBSD server at home shrugged it off (even after inviting other connected users to try), as did my OpenBSD gateway. This, too, is exactly what I expected to happen.

Next, I asked several my associates who use Linux to try it out on their machines, and we didn't have to go far to find more Linux distributions that succumbed to the same painfully effective fork bomb attack. Both Gentoo and Red Hat followed in the footsteps of Mandrake, and each died quicker than you can say "unreasonable default settings." I'll quickly mention here that Debian did not suffer the same fate as the others; congrats to the Debian development team.

For those who are not aware, let me briefly explain the cause of fork bombing. First, the shell must be configured to operate with what I consider to be unreasonable limits. This itself has nothing to do with the kernel. Second, the kernel must allow many more processes to be created than should be. Since shells often default to the maximum number of processes supported by the kernel, together we have a problem.

While the fork bomb example clearly isn't a kernel-specific problem, it is a Linux problem -- and it's something that the kernel could certainly haved prevented.

For the record, I hope that anyone out there running Linux is just as surprised as I was that this ancient attack still works on the default installation of so many high profile Linux distributions. I personally don't understand how usability can supersede security when the consequences are so grave.

Why the kernel is so important

When you look at the security of an operating system, everything relies on the kernel. If you can compromise the kernel, the game is over. If you look at security as a game of chess, check-mating your opponent would be analogous to a root-level compromise; in other words, you just lost. However, in keeping with our analogy, a kernel-level compromise would mean the attacker can wipe the entire board away with just one of his pawns, should he choose to do so. That's pretty bad.

For this reason, the kernel is a special case in security, and it needs special attention from the developers to ensure that it's not susceptible to tampering.

Security is not a product

I said it in my last article, but I need to say it again. Security must be a part of the kernel, not something that gets added in by a select few who probably have the least use for it. There are so many great projects that add security to the Linux kernel. GRSecurity and PaX come to mind immediately. But these products could do so much more if they, or at least some portions of their technology, were included in the base Linux kernel.

Many features of PaX are already present in OpenBSD (W^X), and NetBSD has started to support non-executable pages. Again I must ask, why are products like GRSecurity and PaX, or at a minimum their non-intrusive features, not ending up in the base Linux kernel?

Please, we must make security a priority and not something that has to be patched into the kernel. The whole idea of having to patch in security features, many of which are perfect candidates for inclusion in the base distribution in the first place,is ridiculous.

Make proactive security a priority

According to the SecurityFocus vulnerability database, there have been 21 vulnerabilities reported in the Linux kernel in 2005. I don't want to use this as a metric of security, because as we know, vulnerabilities happen. But where do we draw the line? Twenty-one vulnerabilities in the kernel in less than 3 months? Am I the only one who thinks this is excessive? When will we understand that even though vulnerabilities happen, it doesn't mean that we have to let them happen? The point is, some of these vulnerabilities could have been avoided with a proactive approach to secure programming.

Sometimes it seems like developers are giving up the security battle far too easily. Just as people should not rely on chroot() for security, any given implementation of chroot should not be escapable in some trivial way either. 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. This attitude that there is any one panacea really bothers me. All of these issues I mentioned should be legitimate concerns.

There are kernel-specific issues and there are issues specific to individual distributions that are not clearly kernel developer problems. But from my perspective as a security analyst and researcher, all of these issues work together to become an operating system, and they have negatively affected my perspective of "Linux security."

Don't get me wrong. Linux doesn't suck. But I do believe that the Linux kernel team (and some of the Linux distributions that are still vulnerable to fork bombing) need to take proactive security a little more seriously. I'm griping for a reason here -- things need to be change.

Let's end things on a positive note, though. In case you had any doubt: if I had to maintain a large critical server infrastructure, you can bet I'd still choose Linux over Windows any day of the week.