Re: Fork Bombing Attack

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

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.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]