forkbombing Linux distributions

[aq]

int main() { while(1) { fork(); fork(); exit(); } }
...
the above forkbomb will stop quickly

Yep.
int main() { while(1) { if (!fork()) continue; if (!fork()) continue; exit(); } }

yep, that is better. but system can still be recovered by killall.

a little "sleep" will render the system completely useless, like this:

int main() { while(1) { if (!fork()) continue; if (!fork()) continue;
sleep(5); exit(0); } }

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Paul Jackson]

int main() { while(1) { fork(); fork(); exit(); } }
...
the above forkbomb will stop quickly

Yep.

Try this forkbomb:

int main() { while(1) { if (!fork()) continue; if (!fork()) continue; exit(); } }
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <***@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Kyle Moffett]

brings down almost all linux distro's while other *nixes survives.

Let's see if this can be confirmed.

Here at my school we have the workstations running Debian testing. We
have edited /etc/security/limits.conf to have a much more restrictive
startup environment for user processes, limiting to 100 processes per
user and clamping maximum CPU time to 4 hours per process. It's not
failsafe, but we also have all of the kernel threads set at realtime
levels, with the IRQ threads specifically set at SCHED_RR 99, and we
have a sulogin-type process on tty12 at SCHED_RR 99.

Even in the event of the worst kind of forkbomb, the terminal is as
responsive as if nothing else were running and allows us to kill the
offending processes easily, because when the scheduler refuses to
interrupt the killall process to run anything else, no other forkbomb
processes get started.

I suppose a similar situation could be set up with a user-accessible
server and a rate-limited SSH daemon if necessary, although a ttyS0
console via a console server might work better. In any case, I think
that while there could perhaps be a better interface for user-limits
in the kernel, the existing one works fine for most purposes, when
combined with appropriate administrative tools.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Natanael Copa]

Post by Kyle Moffett

brings down almost all linux distro's while other *nixes survives.

Let's see if this can be confirmed.

Here at my school we have the workstations running Debian testing. We
have edited /etc/security/limits.conf to have a much more restrictive
startup environment for user processes, limiting to 100 processes per
user and clamping maximum CPU time to 4 hours per process.

Thats great. I was was thinking of the default settings. (its even
possible to lock down a windows machine to be "secure")

Also the daemons started from bootscripts that is not aware of PAM is
not affected by those settings. So an exploited security flaw in a
service would allow an attacker to bring the system down even if the
service is running as non-root.

Try running this from a boot script and you'll see that even if this
process is setuid, it will be able to fork more than 100 processes per
user:

/* this program should be started as root but it changes uid */

#define TTL 300
#define MAX 65536
#define UID 65534

int pids[MAX];
int main(int argc, char *argv[]) {
int count = 0; pid_t pid;
if (setuid(UID) < 0) {
perror("setuid");
exit(1);
}
while ((pid = fork()) >= 0 && count < MAX) {
if (pid == 0) sleep(TTL);
pids[count++] = pid;
}
printf("Forked %i new processes\n", count);
while (count--) kill(pids[count], SIGTERM);
return 0;
}

Post by Kyle Moffett
In any case, I think
that while there could perhaps be a better interface for user-limits
in the kernel, the existing one works fine for most purposes, when
combined with appropriate administrative tools.

My point is, the default max allowed processes per user is too high. It
better to open up a restrictive default than locking down an generous
default.

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Natanael Copa]

I agree that make kernel more restrictive by default is a good approach.

Thank you! For a moment I thought I was the only human on this planet
who thought that.

Next question is where and how and what is an appropiate limit? I have
not heard any better suggestions than this:

--- kernel/fork.c.orig 2005-03-02 08:37:48.000000000 +0100
+++ kernel/fork.c 2005-03-21 15:22:50.000000000 +0100
@@ -119,7 +119,7 @@
* value: the thread structures can take up at most half
* of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);

/*
* we need to allow at least 20 threads to boot a system

(FYI: A few lines below the default RLIMIT_NPROC is calculated from
max_threads/2)

This would give default maximum number of processes from the amount of
low memory:

RAM RLIMIT_NPROC
64MiB 256
128MiB 512
256MiB 1024
512MiB 2048
1GiB 4096

That would be sufficent for the users to play their games, compile ther
stuff etc while it would protect everyone from that classic shell fork
bomb by default.

Actually, Alan Cox tried this in the 2.4.7-ac1 kernel
http://marc.theaimsgroup.com/?l=linux-kernel&m=99617009115570&w=2

but I have no idea why it was raised to the double afterwards.

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Natanael Copa]

Post by aq

int main() { while(1) { fork(); fork(); exit(); } }
...
the above forkbomb will stop quickly

Yep.
int main() { while(1) { if (!fork()) continue; if (!fork()) continue; exit(); } }

yep, that is better. but system can still be recovered by killall.
int main() { while(1) { if (!fork()) continue; if (!fork()) continue;
sleep(5); exit(0); } }

Interesting.

With the patch I suggested earlier, reducing default max_threads to the
half in kernel/fork.c, my system survived. (without
touching /etc/security/limits.conf) Mail notification died because it
couldn't start any new threads but that was the only thing that
happened.

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Jan Engelhardt]

brings down almost all linux distro's while other *nixes survives.

Let's see if this can be confirmed.

open/free/netbsd survives. I guess OSX does too.

Confirmed. My OpenBSD install copes very well with forkbombs.
However, I _was able_ to spawn a lot of shells by default.
The essence is that the number of processes/threads within
a _session group_ (correct word?) is limited. That way, you can
start a ton of "/bin/sh"s from one another, i.e.:

\__ login jengelh
\__ /bin/sh
\__ /bin/sh
\__ /bin/sh
...

So I think that if you add a setsid() to your forkbomb,
you could once again be able to bring a system - BSD this time - down.
Just a guess at this time, I would need to write a prog first :p

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Natanael Copa]

Post by Jan Engelhardt

brings down almost all linux distro's while other *nixes survives.

Let's see if this can be confirmed.

open/free/netbsd survives. I guess OSX does too.

Confirmed. My OpenBSD install copes very well with forkbombs.
However, I _was able_ to spawn a lot of shells by default.
The essence is that the number of processes/threads within
a _session group_ (correct word?) is limited. That way, you can
\__ login jengelh
\__ /bin/sh
\__ /bin/sh
\__ /bin/sh
...
So I think that if you add a setsid() to your forkbomb,
you could once again be able to bring a system - BSD this time - down.

I seriously doubt that. Try raising your maxproc setting (sysctl
kern.maxproc?) to something insane and try bombing again.

I tried to bring the box down by raising the limit to something similar
linux default and run the classic ":() { :|:& };:" However, the bomb was
stopped by maximum number of pipes and BSD survived.

If you don't hit the maximum number of processes you will hit another
limit.

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Tux]

I'm confused, are hard limits to RLIMIT_NPROC imposed on services
spawned by init before a user logs in?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Natanael Copa]

Post by Tux
I'm confused, are hard limits to RLIMIT_NPROC imposed on services
spawned by init before a user logs in?

There are no "hard" limits to RLIMIT_NPROC. However, on fork, childern
inherits the parents limits. Non-root users can not raise the limit,
just lower it. So unless limits are set in the bootscripts, the defaults
set in kernel/fork.c will be used on services.

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[f***@vanheusden.com]

The memory limits aren't good enough either: if you set them low
enough that memory-forkbombs are unperilous for
RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
applications.

yes, if you want to run application like openoffice.org you need at
least 200Mo. If you want that your system is usable, you need at least 40 process per user. So 40*200 = 8Go, and it don't think you have all this memory...
I think per user limit could be a solution.
attached a small fork-memory bombing.
Matthieu
int main()
{
while(1){
while(fork()){
malloc(1);
}
}
}

Imporved version:

int main()
{
while(1) {
while(fork()) {
char *dummy = (char *)malloc(1);
*dummy = 1;
}
}
}

Folkert van Heusden

Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See |
|http://vanheusden.com/multitail/features.html for a feature list. |
+------------------------------------------= www.unixsoftware.nl =-+
Phone: [phone], PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Jan Engelhardt]

I think per user limit could be a solution.
attached a small fork-memory bombing.

I already posted one, posts ago.

[snip]

[snip]
char *dummy = (char *)malloc(1);

That cast is not supposed to be there, is it? (To pretake it: it's bad.)

Jan Engelhardt
--
No TOFU for me, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[f***@vanheusden.com]

Post by Jan Engelhardt
I already posted one, posts ago.

[snip]

[snip]
char *dummy = (char *)malloc(1);

That cast is not supposed to be there, is it? (To pretake it: it's bad.)

What is so bad about it?

Folkert van Heusden

Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See |
|http://vanheusden.com/multitail/features.html for a feature list. |
+------------------------------------------= www.unixsoftware.nl =-+
Phone: [phone], PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Renate Meijer]

Post by f***@vanheusden.com

Post by Jan Engelhardt
I already posted one, posts ago.

[snip]

[snip]
char *dummy = (char *)malloc(1);

That cast is not supposed to be there, is it? (To pretake it: it's bad.)

What is so bad about it?

Read the FAQ at http://www.eskimo.com/~scs/C-faq/q7.7.html

Malloc() returns a void*, so casts are superfluous if stdlib.h is
included (as it should be). Hence if one typecasts the result of malloc
in order to suit any particular type, the real bug is probably a
lacking "#iinclude <stdlib.h>", which the cast (effectively) is hiding.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Willy Tarreau]

Please,

would you be so kind to stop debugging your fork-bombing tools with all
the list in CC ? I think that most of us are not interested in knowning
whether the cast is necessary or not before the malloc(). This is LKML,
not FBTML. There are lots of ways to locally DoS linux, you don't need
to fine tune your tools here in public.

Thanks in advance,
Willy

Post by Renate Meijer

Post by f***@vanheusden.com

Post by Jan Engelhardt
I already posted one, posts ago.

[snip]

[snip]
char *dummy = (char *)malloc(1);

That cast is not supposed to be there, is it? (To pretake it: it's bad.)

What is so bad about it?

Read the FAQ at http://www.eskimo.com/~scs/C-faq/q7.7.html
Malloc() returns a void*, so casts are superfluous if stdlib.h is
included (as it should be). Hence if one typecasts the result of malloc
in order to suit any particular type, the real bug is probably a
lacking "#iinclude <stdlib.h>", which the cast (effectively) is hiding.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Matthieu Castet]

The memory limits aren't good enough either: if you set them low
enough that memory-forkbombs are unperilous for
RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
applications.

yes, if you want to run application like openoffice.org you need at
least 200Mo. If you want that your system is usable, you need at least 40 process per user. So 40*200 = 8Go, and it don't think you have all this memory...

I think per user limit could be a solution.

attached a small fork-memory bombing.

Matthieu

[Natanael Copa]

The memory limits aren't good enough either: if you set them low
enough that memory-forkbombs are unperilous for
RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
applications.

yes, if you want to run application like openoffice.org you need at
least 200Mo. If you want that your system is usable, you need at least 40 process per user. So 40*200 = 8Go, and it don't think you have all this memory...
I think per user limit could be a solution.

You have /etc/limits and /etc/security/limits.conf.

I think it would solve many problems by simply lowering the default
max_treads in kernel/fork.c. RLIMIT_NPROC is calculated from this value.

--- kernel/fork.c.orig 2005-03-02 08:37:48.000000000 +0100
+++ kernel/fork.c 2005-03-21 15:22:50.000000000 +0100
@@ -119,7 +119,7 @@
* value: the thread structures can take up at most half
* of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);

/*
* we need to allow at least 20 threads to boot a system

I don't think this will cause much problems for most users. (compare the
default maximum process limit in the BSD's and OSX)

This will also limit deamons/services started from boot scripts by
default. The /etc/limits and /etc/security/limits.conf does not.

If it does cause problems for extrem users, they can easily raise the
limits in either initrd and/or using /proc/sys/kernel/threads-max (or
systctl).

BTW... does anyone know *why* the default max number of processes is so
high in Linux?

--
Natanael Copa

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------