Unix/Linux Forkbomb Vulnerability

[spankers]

Interesting link over at /. to a forkbomb vulnerablity in most distros:
http://www.securityfocus.com/columnists/308?ref=rssdebia

I tried the Python exploit and it locked my Debian Unstable box up tighter than a .... (fill in the blank).

Here's the one line Python exploit (DO NOT RUN ON A PRODUCTION MACHINE!):
python -c 'while 1: __import__(os).fork()'

Looking at my machine, user limits were not enforced:
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
To fix this on Debian I had to add the following line to /etc/security/limits.conf
#<domain> <type> <item> <value>
* hard nproc 500
Which limits user processes to 500...

And uncommented the following line from /etc/pam.d/login
session required pam_limits.so
It's hard to believe that most distros leave user limits wide open... even harder to believe that pam_limits is disabled. Wow!

[k2]

kinda reminds me of when writing a file to a screen crashed linux. there's always odd ways to crash it.

[spankers]

No root compromise though... just local attack denial of service. The attacks that bug me are the ones that end up with the attacker getting:
root@localhost:~#

Linux isn't totally secure or stable by any means.

[k2]

hehe nah .. but atleast the fixes come fast than retail software.

[spankers]

the fixes come fast than retail software
Yes they do for the critical vulnerabilities. Not for lesser ones though. A local DoS vulnerability can remain unfixed for quite some time... forkbombs have been around forever.

It's gotten better though I remember the old Red Hat 6 install I was running way back... all services turned on out of the box. Akin to being naked and bent over with your cheeks spread.

[k2]

yeah .. but this one is simply a config issue that's gone unresolved. i'll be sure to correct the setting anytime i need to.

[spankers]

My thought would be to start out with limits set and relax them as necessary... not the other way around.

That was the problem with Red Hat 6... everything turned on. One of the things that makes OpenBSD so cool is that the OS is locked down out of the box.

[llbbl]

hmm forkbombs bad . I wonder how you can tell if u are vulnerable without possibly crashing the system.

[k2]

look at your limits..

[llbbl]

/etc/security/limits.conf
?

WTF are limits anyways eh how long processor can loop through something before dieing?

[k2]

O_o

set a limit for how many processes a user can start; no forkbomb.

[spankers]

/etc/security/limits.conf
?
WTF are limits anyways eh how long processor can loop through something before dieing?

You can limit per user:

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) 500
virtual memory (kbytes, -v) unlimited

The limit that was not set in Debian was Max User Processes. A fork bomb takes advantage of this and spawns a huge number of processes, effectively eating up all your system resources.... a local DoS. As you can see above, I've set the max user processes to 500. This is a huge number of processes but will defeat the fork bombs I've tried.
how long processor can loop through something before dieing?
Forever perhaps. If limits are not set a fork bomb could make your box unusable until you reboot.

With /etc/security/limits.conf you can assign user limits set by PAM during login (if PAM module pam_limits is enabled in /etc/pam.d/login ... which it was not on my install).

Take a look at user limits by executing 'ulimit -a'. If your number of user processes is unlimited, you're vulnerable.

[llbbl]

Ok thanks explanation Spankers . I'll check it out!!

[llbbl]

I guess it helps to read the article :P

[llbbl]

what if the limits.conf file is commented out . how do you check to see if PAM is enabled ?

[llbbl]

Almost all Linux distributions ship with PAM support making it universally available. PAM limits provide a single standardized interface to setting user limits, instead of having to write complex shell configuration files (such as /etc/profile) you simply. . .Almost all Linux distributions ship with PAM support making it universally available. PAM limits provide a single standardized interface to setting user limits, instead of having to write complex shell configuration files (such as /etc/profile) you simply edit the "limits.conf" file. As well applying limits selectively through the command shell is very difficult, whereas with PAM applying limits globally, on groups or on individual users is quite simple. Documentation is available on PAM usually in the "/usr/share/doc/" tree. To enable PAM limits you need to add a line such as:

session required /lib/security/pam_limits.so

to the appropriate Pam configuration file (i.e. /etc/pam.d/sshd).

http://www.linuxsecurity.com/content/view/112039/151/

[llbbl]

http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/ref-guide/ch-pam.html

Ok i am reading now :P

[spankers]

Here are my /etc/security/limits.conf and /etc/pam.d/login files with nproc limits enabled (File names mangled to post as attachment).

[llbbl]

Hey i found some good info.

Here is the details on the configuration of the PAM files.
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-4.html

RHEL3 was having this forkbomb problems previous to Update 2.

Here is the page for update 2.
http://rhn.redhat.com/errata/RHSA-2004-188.html

Here is more info on the submitted bug.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112764
http://www.redhat.com/archives/taroon-list/2003-December/msg00312.html

I did a ulimit -a and it says for me.
max user processes (-u) 7168

So I should be ok :) since PAM is enabled and the user processes isn't unlimited.

[spankers]

max user processes (-u) 7168

Wow... over 7000. Is this a server? For a desktop that is huge. My laptop currently has:
eherr@chernobyl:~$ ps -A | wc -l
63

[llbbl]

duel Xeon 2.8 Ghz server w/ 2 GB of RAM.

[spankers]

Even for a server that still seems high. Given, Apache can fork like a mofo but I can't imagine >1000 processes on any Intel box.

I'd like to see what the peak process load looks like on a 16-way SMP box used for web apps.

[llbbl]

well I don't mind having 2x-4x the max number of peak processes as long as it is below the number when the system starts to lockup. preventing local DOS attacks is a gud thing!