2007-05-17 14:45:47

by Anand Jahagirdar

[permalink] [raw]
Subject: Fork Bombing Attack

Hello All
I have set per user process limit ( ulimit) for both
root and guest account as 8000 by using option ulimit -u 8000.this is
Hard limit. still fork bombing attack killed the box and machine
needed reboot. will any body please tell me why this is so? i have
tried all this attack on machine with FC6 and Linux kernel 2.6.18.

Regards
Anand


2007-05-17 15:01:54

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: Fork Bombing Attack

On Thu, 17 May 2007 20:15:32 +0530, Anand Jahagirdar said:
> Hello All
> I have set per user process limit ( ulimit) for both
> root and guest account as 8000 by using option ulimit -u 8000.this is
> Hard limit. still fork bombing attack killed the box and machine
> needed reboot. will any body please tell me why this is so? i have
> tried all this attack on machine with FC6 and Linux kernel 2.6.18.

Convince me that your machine in fact has sufficient resources to spawn 8000
processes.

Then retry it with "ulimit -u 100", and then do a binary search from 100 to 8000
to find out what value it stops working at.


Attachments:
(No filename) (226.00 B)

2007-05-18 11:13:59

by Anand Jahagirdar

[permalink] [raw]
Subject: Re: Fork Bombing Attack

Hello All
I tried to execute a program which creates 8152 process.(
i=0; while( i<14) i++ fork(); ) with ulimit 8200. This program
created 8152 processes and then stopped and came back to command
prompt. this proves that my machine do have sufficient resources to
create 8000 processes.

I found one more interesting thing on the same machine
having FC6 distribution and Linux Kernel 2.6.18. i have set "ulimit -u
100". after setting this limit i tried to execute fork bombing program
with guest account. after executing it

expected result:- guest uesr should not able to fork another single
process when it reaches to 100 processes count.

actual result :- kernel allow me to create another processes without
giving error. due to this i tried to execute same fork bombing program
on another terminal with guest account and this fork bombing attack
killed the box completely and machine needed reboot.

will any please tell me why this is so?

Regards
Anand

On 5/17/07, [email protected] <[email protected]> wrote:
> On Thu, 17 May 2007 20:15:32 +0530, Anand Jahagirdar said:
> > Hello All
> > I have set per user process limit ( ulimit) for both
> > root and guest account as 8000 by using option ulimit -u 8000.this is
> > Hard limit. still fork bombing attack killed the box and machine
> > needed reboot. will any body please tell me why this is so? i have
> > tried all this attack on machine with FC6 and Linux kernel 2.6.18.
>
> Convince me that your machine in fact has sufficient resources to spawn 8000
> processes.
>
> Then retry it with "ulimit -u 100", and then do a binary search from 100 to 8000
> to find out what value it stops working at.
>
>

2007-05-18 13:07:42

by Michael Tokarev

[permalink] [raw]
Subject: Re: Fork Bombing Attack

Anand Jahagirdar wrote:
[]
> I found one more interesting thing on the same machine
> having FC6 distribution and Linux Kernel 2.6.18. i have set "ulimit -u
> 100". after setting this limit i tried to execute fork bombing program
> with guest account. after executing it
>
> expected result:- guest uesr should not able to fork another single
> process when it reaches to 100 processes count.
>
> actual result :- kernel allow me to create another processes without
> giving error. due to this i tried to execute same fork bombing program
> on another terminal with guest account and this fork bombing attack
> killed the box completely and machine needed reboot.

Do you know ulimits are a *process* property, not uid property?

That is, if, in some process of a giving user, you set ulimit value,
it does NOT affect other processes of the same user already running
at the same time, but only new processes forked off of this process
where you've set the limit. Limits are inheritable from parent to
child, but not the reverse and especially they don't "migrate" to
"brothers" or "brothers-in-law".

> will any please tell me why this is so?

It's because of the way ulimit works - on Linux and on other systems.

When you set limit of number of processes in some session, you can't
fork more processes *in this session* if total number of processes of
this user is >= the limit value you set. Other sessions are unaffected.

It's unclear what did you mean by ``i have set "ulimit -u 100"''.
Where did you set it?

Note also that when you log in (on a terminal, or over ssh, or using su
command), the limits are usually set to whatever specified for that user
in /etc/security/limits.conf - so for example, if you set a limit and
use su to change uid, your limit is reset.

/mjt

2007-05-18 13:20:08

by Ahmed S. Darwish

[permalink] [raw]
Subject: Re: Fork Bombing Attack

On 5/18/07, Anand Jahagirdar <[email protected]> wrote:
> Hello All
> I tried to execute a program which creates 8152 process.(
> i=0; while( i<14) i++ fork(); ) with ulimit 8200. This program
> created 8152 processes and then stopped and came back to command
> prompt. this proves that my machine do have sufficient resources to
> create 8000 processes.
>
> I found one more interesting thing on the same machine
> having FC6 distribution and Linux Kernel 2.6.18. i have set "ulimit -u
> 100". after setting this limit i tried to execute fork bombing program
> with guest account. after executing it
>
> expected result:- guest uesr should not able to fork another single
> process when it reaches to 100 processes count.
>
> actual result :- kernel allow me to create another processes without
> giving error. due to this i tried to execute same fork bombing program
> on another terminal with guest account and this fork bombing attack
> killed the box completely and machine needed reboot.
>

I think if you want resource limiting per _UID_ (and not per _process_
as you did), you should use PAM module pam_limits.so. You can edit
those limits using the file /etc/security/limits.conf

Regards,
--
Ahmed S. Darwish
http://darwish-07.blogspot.com

2007-05-18 17:22:30

by Anand Jahagirdar

[permalink] [raw]
Subject: Re: Fork Bombing Attack

Hello All
I found one more interesting thing related with fork
bombing attack. i have set following in /etc/security/limits.conf file

#@root hard nproc 3000
#@anand hard nproc 500


I have tried to execute fork bombing program on the same machine. it
killed the box completely and machine needed a reboot. will any body
please tell me why this is so? even after setting limits in
/etc/security/limits.conf file.

about ulimit:
ulimit are by default set to some value for all users.. root, guest.
on my machine with FC4 distribution when i typed command "ulimit -u"
it gave me output as 3055 and another machine having FC6 distribution
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. actually ulimit should help to prevent fork bombing attack
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?

Regards
Anand

On 5/18/07, Ahmed S. Darwish <[email protected]> wrote:
> On 5/18/07, Anand Jahagirdar <[email protected]> wrote:
> > Hello All
> > I tried to execute a program which creates 8152 process.(
> > i=0; while( i<14) i++ fork(); ) with ulimit 8200. This program
> > created 8152 processes and then stopped and came back to command
> > prompt. this proves that my machine do have sufficient resources to
> > create 8000 processes.
> >
> > I found one more interesting thing on the same machine
> > having FC6 distribution and Linux Kernel 2.6.18. i have set "ulimit -u
> > 100". after setting this limit i tried to execute fork bombing program
> > with guest account. after executing it
> >
> > expected result:- guest uesr should not able to fork another single
> > process when it reaches to 100 processes count.
> >
> > actual result :- kernel allow me to create another processes without
> > giving error. due to this i tried to execute same fork bombing program
> > on another terminal with guest account and this fork bombing attack
> > killed the box completely and machine needed reboot.
> >
>
> I think if you want resource limiting per _UID_ (and not per _process_
> as you did), you should use PAM module pam_limits.so. You can edit
> those limits using the file /etc/security/limits.conf
>
> Regards,
> --
> Ahmed S. Darwish
> http://darwish-07.blogspot.com
>

2007-05-18 17:49:37

by Valdis Klētnieks

[permalink] [raw]
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.....


Attachments:
(No filename) (226.00 B)

2007-05-18 21:21:57

by Krzysztof Halasa

[permalink] [raw]
Subject: Re: Fork Bombing Attack

"Anand Jahagirdar" <[email protected]> writes:

> ulimit are by default set to some value for all users.. root, guest.
> on my machine with FC4 distribution when i typed command "ulimit -u"
> it gave me output as 3055 and another machine having FC6 distribution
> 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. actually ulimit should help to prevent fork bombing attack
> but it wont and fork bombing attack still take down the machine having
> latest linux distributions.

how about:
$ ulimit -u 100
$ for f in `seq 1 500`; do (sleep 100&); done

(on another terminal)
$ ps xa|grep 'sleep 100' |wc -l

mine prints 93.
--
Krzysztof Halasa

2007-05-18 22:40:35

by Bernd Eckenfels

[permalink] [raw]
Subject: Re: Fork Bombing Attack

In article <[email protected]> you wrote:
> I found one more interesting thing related with fork
> bombing attack. i have set following in /etc/security/limits.conf file
>
> #@root hard nproc 3000
> #@anand hard nproc 500

The # is a comment character. So those lines are not used.

BTW: the @ means group, you really want that? BTW2: you need to log out/in
and the session leader must actually be PAM regulated (i.e. not for daemons)

So it is good to check "ulimit -n" in the shell where you want to try the
forbomb. If it is below 100 you should be safe.

Gruss
Bernd

2007-05-22 21:52:37

by Mark Lord

[permalink] [raw]
Subject: Re: Fork Bombing Attack

Anand Jahagirdar wrote:
> Hello All
> I tried to execute a program which creates 8152 process.(
> i=0; while( i<14) i++ fork(); ) with ulimit 8200. This program
> created 8152 processes and then stopped and came back to command
> prompt. this proves that my machine do have sufficient resources to
> create 8000 processes.

Perhaps, but it does not necessarily result in 8000+ processes
all in existence at the same time. Unless there's more to that
program than the one line you show above.