linux-kernel - Re: Fork Bombing Attack

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <11733.1179510556@turing-police.cc.vt.edu>
Date:	Fri, 18 May 2007 13:49:16 -0400
From:	Valdis.Kletnieks@...edu
To:	Anand Jahagirdar <anandjigar@...il.com>
Cc:	"Ahmed S. Darwish" <darwish.07@...il.com>,
	linux-kernel@...r.kernel.org, Coywolf Qi Hunt <coywolf@...dg.org>
Subject: Re: Fork Bombing Attack

On Fri, 18 May 2007 22:52:15 +0530, Anand Jahagirdar said:

> output is 8050. when root or any other user changes ulimit by typing
> "ulimit -u value",.ulimit value is changed for that session and not
> permantely.

Right.  That value is only applied to that process, and its children. Or more
correctly, those children that don't themselves change the value again - the
distinction is crucial in this case.

>             actually ulimit should help to prevent fork bombing attack

Right. It *helps* prevent it.  But it isn't by itself a total cure.

> but it wont and fork bombing attack still take down the machine having
> latest linux distributions.
> 
> will any please tell me why this is so?

Because it only requires *one* process not subject to the ulimit, or a group of
cooperating processes subject to the limit, to bypass that particular
protection.

ulimits are a fairly good and inexpensive way to guard against *accidental*
runaway processes from trashing the system.  They're at best a 95% solution,
and won't stop *every* case.

Consider - you determine that a small fork bomb that launches more than
7,500 processes will kill your system, so you set the ulimit to 7000.

I, as an attacker, am using a compromised userid on your system (think about
it for a moment - if I'm a *legit* user of the system, and use my own userid
for it, I'm a self-limiting problem, as I can only do it once, after which I
have to worry about getting fired, possible legal/criminal action, etc).

1) Fork bomb 6,500 processes - and have each one check the 'ulimit -m' value
and proceed to malloc() and then dirty that amount minus 5 or 10 megabytes.

2) Instead of using *one* compromised userid, I use two, and launch 6,000
processes from each...

3) Lots of *other* possibilities.....

Content of type "application/pgp-signature" skipped