Posted on 03/19/2005 6:59:08 PM PST by Bush2000
Linux Kernel Security, Again
by Jason Miller, SecurityFocus.com
It's a sad day when an ancient fork bomb attack can still take down most of the latest 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] <@darks> but I mean, I could have killed ur box
[15:17:04] <+IronBar> no, you couldn't have.
[15:17:08] <@darks> wanna bet ?
[15:17:27] <@darks> 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 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 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.
I hate Linux.
There's no such thing as a free lunch...you just haven't been charged for it yet. Similarly, there's no such thing as attack-proof software (or hardware)...it just hasn't attracted the attention of the world class hackers yet.
You prefer Windows?
It's better than Microsoft's security through obscurity. And with open software, you can hire your own programmer to fix the problem instead of waiting months to years for the vendor to provide a patch, if ever. (Hello, Microsoft?)
For the record, this exploit has never once affected a single one of my BSD boxes. Har de har har.
Well, no need for open-source fanatics or Microsoft haters to prepare lunch for tomorrow. Crow all around! Eat hearty, boys and girls, then hurry and fix your systems.
This is not possible. Everyone knows Linux is un-hackable, and Microsoft is full of holes.
The fork() command is NOT an exploit. It's just a unix system call that anyone who has done any unix system programming knows about.
To say that this is a linux security flaw is as ridiculous as claiming that the "del" command in Windows's dos box is a security flaw. Anyone can bring down a Windows machine by typing something like "del \windows\*.exe" or something like that. Does this mean Windows has a serious security flaw? Of course not.
And what makes it even more absurd is the fact that the fork system call exists in Windows too! (because Windows is posix-compliant). So everything claimed in this article about linux applies to Windows.
Anyways, any sysadmin worth a dime knows not to allow non-privileged users to run fork() in an infinite loop or anything similar.
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.
I assume he can also do it on Windows, but it would probably take a bit more work than typing one line at a command prompt. Either a crazy batch file or a binary.
The issue, I think, is that most Linux distributions don't have sane ulimits set, or don't have an easy way for them to be set during the install process. Given the message traffic on the Redhat list and Linux websites -- consisting mostly of, "It's the admin's fault, man ulimit, hurr hurr hurr," -- this won't be fixed, or if it is, very quietly.
I've been running Debian since 2000. Looks like I chose wisely.
The other thing is...this is pretty dumb. It assumes shell access, and non-existent administration.
I know that if I was going to have shell users, I'd pay a lot closer attention to /etc/security/limits.conf.
My,my! This can really "fork" up a person's computer. If it happens to you, you can say you have just been "forked."
There are lots of ways to bring Windows down by typing a single command at the dos prompt. This is not unique to Linux.
Is your son obsessed with "Lunix"?
BSD, Lunix, Debian and Mandrake are all versions of an illegal hacker operation system, invented by a Soviet computer hacker named Linyos Torovoltos, before the Russians lost the Cold War. It is based on a program called "xenix", which was written by Microsoft for the US government. These programs are used by hackers to break into other people's computer systems to steal credit card numbers. They may also be used to break into people's stereos to steal their music, using the "mp3" program. Torovoltos is a notorious hacker, responsible for writing many hacker programs, such as "telnet", which is used by hackers to connect to machines on the internet without using a telephone.
Your son may try to install "lunix" on your hard drive. If he is careful, you may not notice its presence, however, lunix is a capricious beast, and if handled incorrectly, your son may damage your computer, and even break it completely by deleting Windows, at which point you will have to have your computer repaired by a professional.
If you see the word "LILO" during your windows startup (just after you turn the machine on), your son has installed lunix. In order to get rid of it, you will have to send your computer back to the manufacturer, and have them fit a new hard drive. Lunix is extremely dangerous software, and cannot be removed without destroying part of your hard disk surface.
Has your child asked for new hardware?
Computer hackers are often limited by conventional computer hardware. They may request "faster" video cards, and larger hard drives, or even more memory. If your son starts requesting these devices, it is possible that he has a legitimate need. You can best ensure that you are buying legal, trustworthy hardware by only buying replacement parts from your computer's manufacturer.
If your son has requested a new "processor" from a company called "AMD", this is genuine cause for alarm. AMD is a third-world based company who make inferior, "knock-off" copies of American processor chips. They use child labor extensively in their third world sweatshops, and they deliberately disable the security features that American processor makers, such as Intel, use to prevent hacking. AMD chips are never sold in stores, and you will most likely be told that you have to order them from internet sites. Do not buy this chip! This is one request that you must refuse your son, if you are to have any hope of raising him well.
Are you finding programs on your computer that you don't remember installing?
Your son will probably try to install some hacker software. He may attempt to conceal the presence of the software in some way, but you can usually find any new programs by reading through the programs listed under "Install/Remove Programs" in your control panel. Popular hacker software includes "Comet Cursor", "Bonzi Buddy" and "Flash".
The best option is to confront your son with the evidence, and force him to remove the offending programs. He will probably try to install the software again, but you will be able to tell that this is happening, if your machine offers to "download" one of the hacker applications. If this happens, it is time to give your son a stern talking to, and possibly consider punishing him with a grounding.
Sincerely interested in your thoughts on this.
The takeaway here is you can't just thow any OS out there without securing it.
Compare the length of the list of Windows DOS exploits (99), to the length of the list of Linux DOS exploits (22), at the Denial of Service Database, before you waste too much time trying to claim that Linux is seriously deficient in comparison to Windows, on this matter.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.