Re: forkbombing Linux distributions

From: Natanael Copa
Date: Wed Mar 23 2005 - 07:38:55 EST


On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> On Tue, 22 Mar 2005 07:50:25 -0500, Hikaru1@xxxxxxxxxxx
> <Hikaru1@xxxxxxxxxxx> wrote:

> > While I have figured out how it'd be possible in theory to prevent things
> > from grabbing so much memory that your computer enters swap death, I haven't
> > been able to figure out what reasonable defaults would be for myself or
> > others. Soooo, I suggest everyone who is worried about this check the
> > manpage for 'limits' which tells you how to do this. My machine runs various
> > rediculously large and small programs - I'm not sure a forkbomb could be
> > stopped without hindering the usage of some of the games on my desktop
> > machine.

See patch below.

> > /etc/limits does a better job at stopping forkbombs.

but does not limit processes that are started from the boot scripts. So
if a buggy non-root service is exploited, an attacker would be able to
easily shut down the system.

> > This is an example of a program in C my friends gave me that forkbombs.
> > My previous sysctl.conf hack can't stop this, but the /etc/limits solution
> > enables the owner of the computer to do something about it as root.
> >
> > int main() { while(1) { fork(); } }

I guess that "fork twice and exit" is worse than this?

> I find that this forkbomb doesnt always kill the machine. Trying a
> small forkbomb, I saw that either the forkbomb process, or the parent
> process (of forkbomb) will be killed after a while (by the kernel)
> because of "out of memory" error. The problem is that which process
> would be chosen to kill? (I have no idea on how kernel choose the
> would-be-kill process).

It kills the process that reaches the limit (max proc's / out of mem)?

> If the kernel choose to kill the parent process, or the forkbomb
> itself, damage can be afford. Otherwise, if the more important
> processes are killed (like kernel threads or other daemons), things
> would be much more serious.
>
> Any idea?

Limit the default maximum of user processes. If someone needs more, let
the sysadmin raise it (with ulimit -u, /etc/limits, sysctl.conf
whatever)

This should do the trick:

--- kernel/fork.c.orig 2005-03-02 08:37:48.000000000 +0100
+++ kernel/fork.c 2005-03-21 15:22:50.000000000 +0100
@@ -119,7 +119,7 @@
* value: the thread structures can take up at most half
* of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);

/*
* we need to allow at least 20 threads to boot a system


--
Natanael Copa


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/