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."

Comments

Grep Bomb

[cheezemonkhai]

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 /dev/zero &' fun about 5 of them and watch the box grind to a screaming halt then eventually recover.

Oh hang on did i just discover a new exploit :P

Retarded

[0123456]

Sorry, but this article seems pretty retarded to me. Windows is insecure because people can use IE bugs to install scumware that takes over your entire machine... Linux is insecure because ordinary users who are legitimately logged into your machine can fork off as many processes as they want? Huh?

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?

[lintux]

I really wonder what kind of Debian installation he runs. Just a couple of weeks ago I had to reboot my Debian box after some experimenting with an obfuscated fork bomb. Won't work again now that I set some ulimits, but they're not there by default.

In case anyone is interested, here's the obfuscated fork bomb: :(){ :&:;};:

Reminds me of DoS: Pingfork!

[nullset]

I came up with the idea of a ping/fork DoS attack (mostly as a joke)

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:Sheesh, it's a fork bomb

[Xugumad]

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).

*shuffles nervously* So, out of curiousity, for my.. . err... desktop... how do I stop this exactly? :)

I remember forkbombing myself

[gosand]

I was working at my first job, and we had 10 people to a Sun server. I was writing shell scripts, and wrote one called fubar that was this:

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:"Secure By Default"?

[ArbitraryConstant]

Please explain how the ftpd binary (not suid) can be used to exploit the system in ways that the user otherwise could not.

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.

Linux ignored a lot of rlimits until recently?

[wsanders]

In the past I've been awakened in the dead of night by my IDS'es detecting a fork bomb and it's always been self inflicted - some dumbass^H^H^H^H^H^H^Hmisinformed programmer not understanding why it's important to check the return status of a fork() or set alarms to kill off hung sockets.

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.