Some Linux Distros Found Vulnerable By Default 541
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."
Grep Bomb (Score:5, Interesting)
So what would a good limit to the number of processes spawned be?
I mean what can say what is good for everyone?
Saying that if you think the fork bomb is good grep bombs are more fun and particularly good for silincing the mass of Quake 3 players in an undergraduate lab:
'grep foo
Oh hang on did i just discover a new exploit
Retarded (Score:4, Interesting)
Sure, maybe if you're running a server that allows remote logins, you want to restrict how many processes a user can run. But as a single-user system, I want to be able to run as many processes as I choose, not be restricted by the distribution author's ideas of what's good for me.
Debian not vulnerable? (Score:5, Interesting)
In case anyone is interested, here's the obfuscated fork bomb:
"Secure By Default"? (Score:3, Interesting)
I'm all for making special install kernels and distros "out of the box" to be as hardened as possible. I would love see many distros do a "paranoid" configuration. There are plenty of things OpenBSD does right but that does not excuse OpenBSD. Just like Linux and every other operating system out there, they can still strive to do better.
Reminds me of DoS: Pingfork! (Score:5, Interesting)
In pseudocode:
while (true) {
ping(target)
fork()
}
I seriously thought of posting this to a few script kiddie sites, so the kiddies could crash themselves long before the pinging does any damage
--buddy
Re:Grep Bomb (try it in freebsd) (Score:1, Interesting)
Re:Sheesh, it's a fork bomb (Score:2, Interesting)
Users use resources. If an admin wants to starve their untrustworthy users of resources, they can (and, if they've a lot of untrustworthy users, its highly recommended), but there is simply no compelling reason why it should be turned on by default.
I missed the part..... (Score:2, Interesting)
(can we PLEASE not bring genkernel into this? it sucks.)
Re:Big Fuss (Score:3, Interesting)
Re:Sheesh, it's a fork bomb (Score:1, Interesting)
Windows Crashes, as well. (Score:2, Interesting)
it will bring your system to a halut (mine at least).
Currently I've got a 2.8Ghz 512Mb ram, XP SP2.
I couldnt even get into my task manager, I got about 10 virtual memory errors. Then I rebooted and tried with the task manager open. Once the VM graph shot striaght up past 1GB, it stopped refreshing (4 seconds).
Re:In other news... (Score:3, Interesting)
Is there a ulimit equivalent for Win32?
Just as an after thought, why don't people run public Windows servers and allow people to login, like Unix shell servers?
Re:Sheesh, it's a fork bomb (Score:5, Interesting)
*shuffles nervously* So, out of curiousity, for my.. . err... desktop... how do I stop this exactly?
Re:Sheesh, it's a fork bomb (Score:2, Interesting)
Maybe I'm just biased, because last year, I had a horrible time overcoming some hard-coded limits (on stack size) when trying to run some Fortran code on a SunOS box.
I remember forkbombing myself (Score:5, Interesting)
while [1] do
fubar &
done
Then I did chmod +x fubar, and typed "fubar &"
oops.
The system load started climbing and everyone else on the machine started bitching. I thought it would crash, and went over to the local admin and fessed up. Of course, we were all interested in what would happen. Nobody could get in to kill it, and the processes were spawning so fast that we couldn't catch it. It was taking forever just to log int. But the load leveled off, and it wasn't going to crash. The admin was going to reboot it, but then I said "wait a second!" I went back to my window that was open. Know what I typed?
rm -f fubar
I suppose you could make it more nasty by making the file name create a copy of itself and name it the process id, so that you wouldn't be able to rename it.
cp $0 .$$
./.$$ &
This will leave all the process files laying around, but you could code something to remove them. But this gets the point across.
Re:In other news... (Score:1, Interesting)
Re:Grep Bomb (try it in freebsd) (Score:3, Interesting)
grep:
I don't think they're killed automatically. They seem to be running out of memory.
Of course, the same thing on my OpenBSD box doesn't run out of memory... Either a the GNU grep has a memory leak or the BSD grep has a check for something (long lines?).
Re:Sheesh, it's a fork bomb (Score:2, Interesting)
Re:Thank god I use Windows (Score:3, Interesting)
cmd
cmd
cmd
cmd
cmd
cmd
cmd
cmd
cmd
cm
cmd
kill.bat
kill.bat
kill.bat
I can drop my ath 2000 512mb system in say oh 10 seconds. Increase the amount of cmd's and kill.bat's for added effect
Re:"Secure By Default"? (Score:5, Interesting)
Taking away the ftpd binary wouldn't stop the user from doing exactly the same thing by some other means. For example, they could simply download the source and compile a new one by themselves. Or use Perl. Or compile a binary somewhere else and download that.
Re:Sheesh, it's a fork bomb (Score:3, Interesting)
Re:Not a vulnerability. (Score:1, Interesting)
Here's another example... it sounds OK to allow a user to run 24 processes, right? And it sounds OK to allow them to allocate 100MB of memory, right? But that's 2.4GB of memory you just permitted! And there's no way (due to lack of per-page inspection for performance reasons) for the kernel to distinguish if they've really got 2.4GB or if each process is sharing 98% of that memory with the rest.
Machines that are locked down enough to actually _prevent_ (not detect, but prevent) resource exhaustion are usually quite useless. Very few scenarios require you to do this, it's often enough to prevent trivial fork-bombs and put up a big warning saying "We catch you breaking it, we make you pay".
Linux ignored a lot of rlimits until recently? (Score:4, Interesting)
I found some earlier kernels ignored RLIMIT_CPU, RLIMIT_RSS, and RLIMIT_NPROC, and setting the CPU and RSS limits in Apache was ineffective. This was in the Red Hat 9 / 2.4.20 kernel days. I have not researched this in a year or so. If all this stuff works now, let me know so I can insert a "ulimit -Hu 10" in future startup scripts as a "courtesy" to inattentive programmers.
Re:Sheesh, it's a fork bomb (Score:2, Interesting)
For instance, imagine writing a recursive program to calculate the factorial of a number (note: no error checking included, and I'm letting the kth factorial number for k
Now assume that instead of typing (x-1) in the recursive call on the next to last line, the user types (x+1). If the user calls this with x > 2 and you don't have some limit on the number of recursive calls a function can make, this program will never end (unless you exceed the stack limit, which is not a graceful way to exit.) If there is a limit, the program will hit that limit and error, giving the programmer a chance to catch their typo. If the user really was interested in blowing the stack and they have the authority to change the recursion limit, they can do so if they want
Re:Run this: (Score:3, Interesting)
That's what job limits [microsoft.com] are for. Shameless plug: get jobprc, a GPL'd command-line job creator (written by me) here [comcast.net].
Re:Sheesh, it's a fork bomb (Score:3, Interesting)
How? I thought by default that you have to be root to change the ulimit (either up or down) I tried the
Re:Thank god I use Windows (Score:3, Interesting)
start cmd
start cmd
start cmd
start cmd
start cmd
start cmd
start cmd
start cmd
start cmd
start kill.bat
start kill.bat
start kill.bat
start kill.bat
start kill.bat
start kill.bat
Try it! My machine has been freezed in about 15 seconds.
Re:Not a vulnerability. (Score:3, Interesting)
There's probably some more obvious ones, if I thought about it a bit.
I guess I wouldn't mind if Fedora came with defauts that stopped a forkbomb on my box, if I was stupid enough to run one ... but if they fucked it up and set it too low I guarantee I'd be very pissed.
Re:vulnerable because of ssh, not like cmd (Score:3, Interesting)
Re:vulnerable because of ssh, not like cmd (Score:2, Interesting)
Re:Sheesh, it's a fork bomb (Score:3, Interesting)
Fail - The OS grinds to a halt and after waiting five minutes, there is no recourse other than cutting power and rebooting.
Pass (one/a) - The OS grinds, but the user can navigate to a feature (console, Control-ESC in KDE, etc) that allows the user to quickly kill the offending process(es).
Pass (one/b) - The OS grinds or not, but regardless automatically kills the offending process. I consider this to be a worse level than the following.
Pass (two) - The OS grinds and automatically offers the user a method to kill the offending process(es). (KDE had something like that at one point. It may still). Sometimes you may want to let it run.
Pass (three) - The OS does not grind and upon approaching resource limits, offers the user an option to shut down the process or let it run.
And finally...
Pass (four) - The OS does not grind and upon approaching resource limits, offers the user an option to increase limits, potentially by moving the process to another machine or allocating more systems to the process. Presumably the migration would be automatic (and transparent) if the resource limits were higher than the local machine.
Obviously, "user" may be a combination of user and admin in certain cases (multi-user machine, accessing other machines off a local cluster, etc).
--
Evan