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."
Fork bombs only work if you can log into the system in question. This is a bit lower priority than your usual vulnerabilities which allow outside attacks.
Sorry, brain fart. I meant hard ulimits
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
You were running bash then :p
:) .login or .bash_rc files.
I recognise that one... which is always good
just don't leave your box unlocked and have some "funny" person drop it in your
If you had read the article, you'd have realized that this was not Windows vs Linux. It was a report on how a fork bomb can take down default Linux installs, but not default BSD installs. Also, the article was clearly not concerned about single-user installs, but multi-user. Or if the box is hacked into, this is an extra bit of protection.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
A good vm should do enough accoutning to allow you to log back in and kill those.
So, try this in FreeBSD, and be amazed, now try it in any 2.4 or 2.6 linux kernel, and be disgusted.
No. I've played with fork bombs in Windows with SFU or Cygwin, and they didn't bring down the system. Seems like there was a sane ulimit on processes.
:|:& };:" (without the quotes) on your bash prompt to see if you are vulnerable.
Try ":(){
while(1) { malloc(1); }
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.
Unless you use genkernel, there is NO default kerenel configuration, verions or anything else. No serious admin uses genkerenel as anything other than a starting point - PERIOD.
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.
Spell check? Why bother. That is what grammer/spelling Nazi freaks who waiste band width posting "spell right" are for.
man ulimit
Specifically ulimit -H -u <number> in their startup file.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
On my Win2k box, running ":(){ :|:& };:" at a Cygwin bash prompt DOES kill the system. I don't know enough about Windows admin (and I don't care enough to learn) what would prevent a forkbomb.
If God had meant for man to see the sunrise, He would have scheduled it later in the day.
(forkbomb.sh)
#!/bin/bash
./forkbomb.sh
while true; do
done
You can put a hundred kill.bat's in there but they never get called. It will transfer control, you need to use "call kill.bat" if you want to continue in the same script.
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.
You are in a maze of twisty little relative jumps, all alike.
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..
My Linux Command of the Day site : LCOD