linux-kernel - Re: A long overdue fork-bomb defense ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <112094.1302389083@localhost>
Date:	Sat, 09 Apr 2011 18:44:43 -0400
From:	Valdis.Kletnieks@...edu
To:	Robert Hailey <lkml@...dok.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: A long overdue fork-bomb defense ?

On Sat, 09 Apr 2011 17:25:48 CDT, Robert Hailey said:

> Is there a better way to handle the integer overflows?

Oh, is that for overflow handling? My (admittedly quick) review
of the code made it look like it was an exponential-decay feature.

Might want to think about what situations will cause an integer overflow
here.  What has to happen before an overflow is a concern?

> >> 		for ( p : process_table) {
> >
> > Ditto.
>
> Thankfully, this logic would only be triggered when the process table
> is full. At that point I doubt anyone would miss the compute time of
> even the most painful lock :)

If you get to the point where it's full, you've already lost.

> Presuming for a moment that it works, I think the worst case is
> actually a single (perhaps compromised) process spawning child fork
> bombs. For that matter it could be a bash shell with the user setting
> them off. In that case it might *never* cause enough forking it to get
> itself automatically killed, but the system would still be [somewhat?]

bash$ :(){ :|:&};:

Try it and see. ;)

> responsive through the attack b/c it no longer denies a legitimate  
> fork, i.e. logging in & using a shell work, even while the process  
> table is *FULL* of active fork bombs.

I suspect recent patches that allow an entire process tree to be sent SIGSTOP
will be a more productive approach.

> Even if a fork bomb is downgraded from "fatal" to "makes things darn  
> slow", it's worth considering, no?

Depends why a fork bomb was allowed to be fatal in the first place...

Content of type "application/pgp-signature" skipped