To: Anand Jahagirdar <anandjigar@gmail.com>
Cc: "Ahmed S. Darwish" <darwish.07@gmail.com>, linux-kernel@vger.kernel.org,
       Coywolf Qi Hunt <coywolf@sosdg.org>
Subject: Re: Fork Bombing Attack
In-Reply-To: Your message of "Fri, 18 May 2007 22:52:15 +0530."
             <25ae38200705181022l35e0b364p98fc39e5739612b@mail.gmail.com>
From: Valdis.Kletnieks@vt.edu
References: <25ae38200705170745t4a80e7eer413b3c2bb0c5a327@mail.gmail.com> <4051.1179414105@turing-police.cc.vt.edu> <25ae38200705180413s741cac1bw9fe0dc57cecc2a91@mail.gmail.com> <1865922a0705180619g2a997c2ch5d13be3e023630e0@mail.gmail.com>
            <25ae38200705181022l35e0b364p98fc39e5739612b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1179510556_4061P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 18 May 2007 13:49:16 -0400
Message-ID: <11733.1179510556@turing-police.cc.vt.edu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2425
Lines: 64

--==_Exmh_1179510556_4061P
Content-Type: text/plain; charset=us-ascii

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

--==_Exmh_1179510556_4061P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFGTecccC3lWbTT17ARAsu7AJ4yTl6bvA2UhziYQkEoxxStQlRowgCfZEMG
mikQT0IRzSrL2zTJ4NfrvsA=
=cbps
-----END PGP SIGNATURE-----

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