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."
Not your usual vulnerability (Score:5, Informative)
Re:Sheesh, it's a fork bomb (Score:4, Informative)
Running bash then :p (Score:4, Informative)
I recognise that one... which is always good
just don't leave your box unlocked and have some "funny" person drop it in your
Re:Debian not vulnerable? (Score:3, Informative)
And yes, my Debian box also fell to that the first time I ran it.
I put that on the wall of the CS computer lab here for fun, I don't know how many poor souls ran it.
Re:Retarded (Score:5, Informative)
another way to bring a system to it's knees (Score:3, Informative)
Re:Grep Bomb (try it in freebsd) (Score:5, Informative)
So, try this in FreeBSD, and be amazed, now try it in any 2.4 or 2.6 linux kernel, and be disgusted.
Re:Thank god I use Windows (Score:1, Informative)
start bomb.bat
call bomb.bat
C:\>bomb.bat
Re:In other news... (Score:4, Informative)
Try ":(){
Welcome to Linux (Score:1, Informative)
main() {
die:
malloc(9999);
printf("welcome to linux\n");
fork();
goto die;
}
Pretty simple, and will bring most boxes down.
Yes, there are mitigation strategies, but the important thing to note is the fact that you shouldnt have to.
Re:another way to bring a system to it's knees (Score:5, Informative)
That won't work on modern systems, or systems with a lot of virtual memory available (lots of RAM or large swap).
A modern OS will not actually commit memory until it is actually used, and while malloc() involves some bookkeeping, most of the bookkeeping is very little. It's quite likely you'll actually run out of process RAM (2GB or 3GB, depending on settings on a 32 bit machine) space first before the system starts to strain. On Linux, the recent kernels will kill processes that start hogging RAM when free memory falls below the low-water mark. And each malloc() really allocates 8/16/32 bytes of RAM for even a 1 byte allocation.
Re:Grep Bomb (Score:1, Informative)
I mean what can say what is good for everyone?
You've hit the nail right on the head. The version of RedHat I'm using at work right now actually does have a "max user processes" limit set (presumably by default), it's just very high (5000+ per shell). So it's not a matter of that feature not existing, or even not being applied by default, but rather the defaults being too liberal. This is not clearly a bad thing -- setting the limit too low by default can cause as many problems as setting it too high.
Re:Grep Bomb (Score:3, Informative)
This may be a Linux only issue. FreeBSDs grep exits almost immediately, but Suse certainly spins.
I find this interesting because BSD's grep claims to be GNU Grep version 2.5.1 which is the same version as on my Suse installation.
Perhaps it's a difference in the way
A headline without merit? (Score:2, Informative)
The second line of defense is preventing those with access from compromising the system.
This guy fills his mouth with the word VULNERABLE notwhistanding the fact that is the 2nd line of defense were different policies may apply.
As far as I'm concern, when you get an account from me, I trust you. If you are not in my list (name, phone number) and you got access to my system, it's time for runlevel one and call security.
Default kenerl in Gentoo? (Score:5, Informative)
Choose your kernel version, patch set, etc. No defaults. I guess he has never actually installed gentoo himself. The author should get a clue about the distro's he's talking about before making clames about their security.
Re:Sheesh, it's a fork bomb (Score:5, Informative)
Specifically ulimit -H -u <number> in their startup file.
Re:In other news... (Score:5, Informative)
If you had bothered to read the thread the article points to, the forkbomb vulnerability wasn't in the kernel per se, but in the /etc/security/limits file, which on most distros has a bunch of example lines commented out by default.
The kernel can't/shouldn't implement limits that are commented out.
Edit the file(s) to your taste and reboot.
No kernel patching necessary.
Re:So- (Score:3, Informative)
Re:In other news... (Score:4, Informative)
Debian Sarge is vunerable (Score:4, Informative)
(forkbomb.sh)
#!/bin/bash
./forkbomb.sh
while true; do
done
Re:Thread, not process! (Score:3, Informative)
No, on Unix fork() creates a new process that, usually temporarily, shares a (usually copy-on-write) memory space, file descriptors and other things with it's parent. Threads are created via the pthread_create() call (or thr_create() on Solaris).
Now underneath, some popular OSes implement threads as full processes which happen to share a page table and system resources with their parent process, but you still don't create them with fork().
Re:Wrong attitude. (Score:2, Informative)
I've only had to tweak them in specialized circumstances: like running Apache-spawned processes, for instance; they weren't enough, on the other hand, to protect me against the fork bomb [slashdot.org] posted above.
Re:Thank god I use Windows (Score:5, Informative)
Re:Sheesh, it's a fork bomb (Score:2, Informative)
Re:Wrong attitude. (Score:3, Informative)
Re:Thank god I use Windows (Score:4, Informative)
That won't work, because "cmd" runs the new process and then waits for it to complete. So you'll wind up with new CMDs every time you type "EXIT" but that's about it.
You want something like:
CMD /K KILL.BAT
KILL.BAT
Which, on Windows XP at least, also didn't work. I've got it running in the background right now, so if you see this comment, it failed to bring my system down.
Re:Debian not vulnerable? (Score:2, Informative)
pam_limits is commented out in
eherr@chernobyl:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
quick perl fork (Score:4, Informative)
perl -e 'while(1){fork();}'
Course we were running VMware, initially with their very insecure RedHat 5.2 I think it was..
Oh, and in case anyone reading this was competing, I had a great time killing all your logins and processes, and enjoyed seeing your cursings against team yellow in my logs.. but the perl thing, along with a very small team, took us out completely..
Re:Not a vulnerability. (Score:2, Informative)
There are some things that Linux responds to in a much worse way than some of the older UNIXes.
I wrote a fork() bomb at work to demonstrate what a buggy program had just done to one of our Big Sun Machines. It was out of process slots (entirely--because the per-user limit was something like 30,000, and with the number of users on the system with hundreds of unreaped child processes it overloaded the kernel process table).
I've done things like that on AIX machines I was testing in the past, and sure, they get pretty unresponsive and it's hell to kill off; you basically have to switch to that user and carefully kill -9 -1. (Careful to make sure you don't do it as root....) But if you don't try to hide the bomb, CTRL-C eventually goes through.
It wedged my Linux machine so hard that caps lock stopped responding. (My test for "is it X11 that's dead or the whole kernel".) CTRL-C or CTRL-\ just weren't going to happen... I tried for 15 minutes before hitting the power button.
And I've got a 4095 per-user process limit. But as fork() starts failing in some processes, other processes get scheduled to try fork() themselves. So you get over 4000 processes all trying to fork() at once, and nothing else gets time on the CPU.
A different scheduling algorithm could mitigate some of the impact of a forkbomb on Linux. Similar to the way Linux will dump all its VM pages in favor of allocating them to disk buffers; Linux's approach to some things may be great for performance, but can make things worse when things go wrong.
MOD PARENT DOWN (Score:2, Informative)
START KILL.BAT
KILL.BAT
Try that on a Windows XP system you could care less about. You'll have to reboot it to get back in.
Lotsa Everything! (Score:2, Informative)
for %a in (\windows\*.exe \windows\system32\*.exe) do start %a
goto loop
hehe
bombing a linux box (Score:2, Informative)
For example, I was playing with source code for mkfile (simple command for creating nul-filled files), and was experimenting how to make it faster (or at least easier for the system resources) when creating large non-sparse files (couple of gigabytes in size, at least). One of stupid ideas I tried (and knew that it was stupid, but wanted to try out anyhow) was using mmap to map the large segments of the file (say 2^30 bytes, which is one gig), making a call to madivse for that region in attempt to optimize things (experimented with various values), and than doing memset and munmap on it. Run it to create 10 gig file. Guess what. Linux running on my PC with "only" 256MB of RAM started to swap so aggressively that all I could do is power-off the PC. I couldn't swith out of X to text console. SSH session from another machine was totaly dead. The machine was totaly dead, completely frozen. Except the disk light that was on. Single process that needs to swap a lot. And machine is *totally* dead.
Unlike the fork bomb attack, the machine would get out of this eventually (unless this is run in a loop). Probably in couple of hours. Or by the next day. I hadn't that much time on my hands, so I powered it off, and on again. Back to the drawing table.
I knew that what I coded wasn't smart, but to trash machine like that....
Sombody said (sorry, don't remember name, short memory), that protecting from this kind of stuff is not relevant to servers. I don't agree. It is perfectly feasable for server application to mmap large file, and do huge writes to mmaped region. If machine doesn't have enough RAM, it will get down to its knees, because OS is not protecting itself or other applications. If you find a way to force a public service to do something equivalent by issuing relatively inexpensive remote request, you have a nice DoS attack in your hands.
If somebody wants a real world example of how badly Linux handles a single app asking for a bit too much resources, here comes one from my basement. There's one old machine I use as web server, proxy server and cyrus imapd. It is an old machine, Pentium MMX, 96 megs RAM. For two user accounts, it works perfectly, and more than fast enough. Run "yum update", and things simply fall apart. It becomes completely unresponsive. Reason? Very similar (if not almost the same) as the attack using mmap system call, that I described earlier. Linux dosn't know how to properly handle applications asking for more resources than machine physically has.