[CentOS] Regarding fork bomb in a CentOS 4.4 Server!

Tue Apr 24 19:03:07 UTC 2007
Scott Lamb <slamb at slamb.org>

On Apr 24, 2007, at 12:25 PM, <israel.garcia at cimex.com.cu> wrote:

> Hi again, I was reading from the net
> http://www.kriptopolis.org/node/4067 about a forkbomb and ran it  
> from a
> root console  in a non-critical machine running CentOS4.4 and the  
> serevr
> goes down... the command I ran was :(){ :|:& };:
> Please, does anyone knows how to aboid this on  CentOS?

Easy: don't forkbomb your own system as root.

First, understand that it didn't "go down". The system was working as  
designed. There's a limit to the number of processes that can be  
running, and you exhausted it. No new processes could start, so you  
couldn't log in again, or even use any functionality not built into  
the shell (ps, etc). Besides that, the load was quite high from many  
processes trying to fork as fast as they possibly could (even though  
all those fork() calls were failing with EAGAIN), so the system was  

Since you were sitting at the shell that caused the problem, you  
could have hit ctrl-Z to suspend the first forkbomb subshell, then  
"kill -9 0" (a bash builtin) to kill the entire process group, and it  
would recover. Likewise if you happened to know the pid of the  
process group leader, "kill -9 -PID" would work. Or if you have a  
root shell running with a lot of builtin utilities (like BusyBox),  
you could use those to find the offending process group. Otherwise,  
you're screwed.

It's possible to prevent unprivileged users from hogging all of the  
system resources (processes running, RAM, whatever) through the  
ulimit facility. But Linux (unlike other Unix systems) does not honor  
root's process limit. [1] Even if it did apply, hitting that  
artificially lower limit would still mean you couldn't fork() as  
root, so killing root processes would still be tricky - probably  
impossible without setup work.

So basically, you can prevent unprivileged users from doing this but  
not root. That matches the Unix philosophy - root's supposed to know  
what he's doing:

"UNIX was not designed to stop its users from doing stupid things, as  
that would also stop them from doing clever things." – Doug Gwyn


[1] - <http://groups.google.com/group/mlist.linux.kernel/ 
browse_thread/thread/f771d3d01478babb>. More precisely, it's  
controlled by capability bits. In general, root has those bits set  
and other users don't.

Scott Lamb <http://www.slamb.org/>