Slashdot Mirror
Some Linux Distros Found Vulnerable By Default
TuringTest writes "Security Focus carries an article about a security compromise found on several major distros due to bad default settings in the Linux kernel. 'It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions', says the writer. The attack was performed by spawning lots of processes from a normal user shell. Is interesting to note that Debian was not among the distros that fell to the attack. The writer also praises the OpenBSD policy of Secure by Default."
Sorry but the ability for a non-privileged user to run as many programs as the like is a feature, not a bug. Inability to turn that feature off would be a bug, but given that few modern Linux boxes are actually used as multi-user remote-login accounts, it's a completely unecessary overhead.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
A forkbomb is just a relatively simplistic way to mount a resource exhaustion attack. I would be extremely wary of anyone who claims that their UNIX class operating system is immune to resource exhaustion from a local user. There's just too many resources that can be commandeered, and to lock them all down would leave you with a system that's so restricted as to be nearly useless as a general computing platform.
/. if they're reporting this as news.
It must be a slow day on
No, I understand the article. I just couldn't resist the jab. The fact is that GNU/Linux ought to be the best it can be in and of itself. That some distributions are screwing that up and making very poor defaults is not to be forgiven. Not at all. Especially when it isn't difficult to do better.
How to use coral cache: http://slashdot.org.nyud.net:8090/~oscartheduck
On the 3 distros listed as vulnerable, the default settings would stop any remote person from having a chance of getting a shell open on the box to perform the fork attack in the first place.
If a person has enough access to the machine to be able to "forkbomb" it, then there's plenty of other nasty things you could do to it.
All my servers have multiple users. Those users are system accounts to run different software, and I do not want any of them to be able to cause a problem to the entire server. Reasonable limits should be in place by default, and those of us who actually need higher limits for certain users, can raise those limits.
Even on a single user desktop machine, its nice to have limits so shitty software can't take down my entire machine. With limits I can just log in on another terminal and kill the offending program, without limits you get to reboot, and lose any work you were doing.
Looks like everyone out there on slashdot think this is not really a problem. Remember when it was discovered that you could get into a xp installation locally with a win 2000 boot cd? Oh, the howling that was heard.
Here is a issue that can be done remotely with only a user account.
Humor from a Genetically Molested Mind
It's funny, isn't it, that on the same day we have a story about Linux distros being insecure by default, EXCEPT Debian, we have another story where Debian is being criticized for not releasing updates more often.
Maybe, and here's a thought, just maybe, it's wise to take a decent, stable distro and perfect it, instead of taking a distro and submerging it in a state of perpetual flux with constant updates.
Just a thought. I might be biased because it's a Debian-based distro that finally put a working Linux on my laptop. But you know what? Every now and then the bias is there for a reason...
Most linux systems are used as desktops, if you use them as a server you don't use the defaults. Now a user being able to crash his own system is nothing new. It ain't nice but as long as it is the user doing it then no problem. Now if this fork could be used to make apache explode and bring down the system THAT would be a boo boo.
Ideally yes the system should not do things that bring it coming crashing down but this is close to blaming a car for allowing me to plow into a wall. Not sure if I want a car/computer telling me what I can and cannot do.
As to how to set the limits on the number of forks. Maybe I got this completly wrong but could it be that this depends entirely on your hardware? Perhaps the latest IBM mainframe can handle a few more then an ancient 386? How the hell is the distro supposed to know what I got?
Security is other people doing stuff on my computer that I don't want and or know about. Me screwing stuff up is my business.
BSD is very solid, this is known. It is also known that BSD has been along long before linux and but has been sucking it exhaust fumes ever since it arrived. For every story about how much more secure BSD is there are a dozen stories about linux actually making a mark on the world. So good. Your BSD survived a forkbomb. But why exactly was the author running a linux desktop then if BSD is so much better?
Another non-story on /. Is the internet going to the way of tv?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
*Any* local exploit is *also* a potential remote exploit (just like the IRC conversation shows). I had someone nearly pwn a box of mine by using an exploit in a buggy PHP script, then trying to elevate privileges through a local exploit.
Had I not considered local exploits important, I'd have had one nicely hacked box.
Oolite: Elite-like game. For Mac, Linux and Windows
Right, it's a feature, but the question isn't whether it should ever be allowed, but what the default setting should be. I think the article made a pretty good case that default should be no.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).
First, I think a lot of unix people would be shocked to find that's on by default as the writer was. Second, that basically means that anyone who successfully hacks into a user account takes the machine down. That applies for your desktop machine, not just "old-style" unix type servers. Third, you mention the relative scarcity of old style servers these days - they're still more common than a user who needs to run an INFINITE number of programs. Even capping somewhere in the thousands would work, keeping anyone from being hampered in their work.
Basically, this is a case of idea vs. reality. You want the IDEA that you can run as many programs as you want, though you'll never need to. So in REALITY, a sane cap never hurts you. However, a lack of a cap provides very REAL security problems, either from a user or from someone who manages to hack a user account. Again, you really don't want EVERY userland exploit to lead to a kernel takedown, do you?
Two things: 1. Just because you don't care doesn't mean other people won't care. A lot of people (especially in a business environment) do have more than one person logging. 2. The article is trying to point out something that Linux installs could improve on. That is all.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
Just how many regular users expect to run 20000 processes at once? (or even 200?) When that happens it's almost always caused by a bug (or malicious activity). Right now, I have 50 user processes running. I'm a power user, but I'd probably never get blocked by a limit of 1000 unless I was doing something really wierd -- and something that weird should come with instructions on modifying the kernel settings.
Yes, it should always remain possible to set up your system so that you can run massive numbers of processes and/or threads, but the default should be to keep numbers to a dull roar in favour of system stability. People whose needs are such that they actually and legitimately want to fork massive numbers of processes are also the kinds of people who wouldn't have a hard time figuring out how to change the kernel settings to allow it.
As such, the default should err on the side of security, but allow a knowledgable user to do whatever the heck he wants.
Thing is, though, that local resource-exhaustion exploits are difficult to set. You want to allow a user felatively free reign -- even to the point of stressing the system, but still allow enough of a reserve so that an admin cam login and shut down a user who'se gone overboard. You also want to set a limit that will be reasonable 5 years down the road when processors are 10 times as fast (and/or 20-way SMP is standard issue)
Something to note here in Linux's favour: Even though the forkbomb brought the system to it's knees it stayed up. Although it might have taken 1/2hour to do, an admin may have been actually able to login and kill the offending process.
Free Software: Like love, it grows best when given away.
We aren't saying that default limits will be perfect for everyone. We are saying that its better to have to raise your limits IF YOU NEED TO, then to have your machine vulnerable to being completely taken down trivially, very possibly by remote users with no accounts, just from making your services work harder than you expected.
If you are running a server than needs hundreds of apache processes running, then you know that and can raise it. Someone who is new to linux won't need that, and won't know how to setup limits for themselves. So you make the machine secure by default, and allowed advanced users with advanced needs to tweak things as they need.
The best thing I can think of to illustrate the point to you is your apache example. By default apache won't let you have more than 150 users connected. This is a sane default to protect from resource exhaustion. If you need more than that, you can set it yourself. People have some protection by default, but advanced users can customize the settings for their needs.
I cannot believe in 2005 I am arguing with someone who thinks secure by default is a bad idea because it might invonvenience you.
This level of fanboyness is unbelievable. Well actually I should not be surprised, blindness to linux's faults is endemic here on Slashdot.
The author is not "Running around screaming...", he is simply very surprised that a local user can exhaust a system so easily. Maybe every single admin should think of all n possible security problems every single time they take a box live, but people are human.
Which one is worse: limits in place by default so that an admin needs to know how to raise them when necessary and the forkbomb would not work, or no limits in place and having to know to set them or else the box can be brought to its knees? Secure by default or free for all.
I suppose you think every default install should also have telnetd enabled by default because any admin with half a brain should know how to turn that off? Point is admins are fallible, the default should be the lower total risk/cost option. I think which one that is is clear here.