linux-kernel - Re: evading ulimits

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]

Date:	Sun, 24 Dec 2006 02:20:33 -0500
From:	John Richard Moser <nigelenki@...cast.net>
To:	Valdis.Kletnieks@...edu
CC:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	linux-kernel@...r.kernel.org
Subject: Re: evading ulimits



Valdis.Kletnieks@...edu wrote:
> On Sat, 23 Dec 2006 19:42:10 EST, John Richard Moser said:
>>
>> Jan Engelhardt wrote:
>>>> I've set up some stuff on my box where /etc/security/limits.conf
>>>> contains the following:
>>>>
>>>> @users          soft    nproc           3072
>>>> @users          hard    nproc           4096
>>>>
>>>> I'm in group users, and a simple fork bomb is easily quashed by this:
>>>>
>>>> bluefox@...box:~$ :(){ :|:; };:
>>>> bash: fork: Resource temporarily unavailable
>>>> Terminated
>>>>
>>>> Oddly enough, trying this again and again yields the same results; but,
>>>> I can kill the box (eventually; about 1 minute in I managed to `/exec
>>>> killall -9 bash` from x-chat, since I couldn't get a new shell open)
>>>> with the below:
>>> Note that trying to kill all shells is a race between killing them all firs
> t
>>> and them spawning new ones everytime. To stop fork bombs, use killall -STOP
>>> first, then kill them.
>>>
>> Yes I know; the point, though, is that they should die automatically
>> when the process count hits 4096.  They do with the first fork bomb;
>> they keep growing with the second, well past what they should.
> 
> This may be another timing issue - note that in the first case, you have :|:
> which forks off 2 processes with a pipe in between.  If the head process fails,
> the second probably won't get started by the shell *either*.  In the second
> case, you launch *3*, and it's possible that the head process will start and
> live long enough to re-fork before a later one in the pipe gets killed.
> 
> Does the behavior change if you use 4095 or 4097 rather than 4096?  I'm
> willing to bet that your system exhibits semi-predictable behavior regarding
> the order the processes get created, and *which* process gets killed makes
> a difference regarding how fast the process tree gets pruned.
> 

I will test this later (sleeping now)

> Do you have any good evidence that the second version manages to create much
> more than 4096 processes, rather than just being more exuberant about doing so?
> I'm guessing that in fact, in both cases the number of processes ends up
> pseudorandomly oscillating in the 4090-4906 range, but the exact order of
> operations makes the rate and impact different in the two cases.

I haven't gathered evidence; I rather look for evidence that fork() is
failing, like bash complaints.  I get those in abundance in the first
case; but see none in the second case.

Trying again, I can't reproduce the phenomena.  It crashes out in 3
seconds.  Either just weird that it ran for so long last time before I
had to manually kill it off; or a race.  I don't have sufficient data to
decide.


-- 
    We will enslave their women, eat their children and rape their
    cattle!
             -- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam:  https://bugzilla.mozilla.org/show_bug.cgi?id=229686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/