Re: forkbombing Linux distributions

Re: forkbombing Linux distributions

[Matthieu Castet]

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

> 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

[-- Attachment #2: kha.c --]
[-- Type: text/x-csrc, Size: 64 bytes --]

int main()
{
	while(1){
		while(fork()){
			malloc(1);
		}
	}
}

Re: forkbombing Linux distributions

[folkert]

> > 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: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!

Re: forkbombing Linux distributions

[Jan Engelhardt]

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

I already posted one, posts ago.

>>[snip]

>Imporved version:
>[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.

Re: forkbombing Linux distributions

[folkert]

> I already posted one, posts ago.
> >>[snip]
> >Imporved version:
> >[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: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!

Re: forkbombing Linux distributions

[Renate Meijer]

On Mar 28, 2005, at 9:39 PM, folkert@vanheusden.com wrote:

On Mar 28, 2005, at 9:39 PM, folkert@vanheusden.com wrote:

>> I already posted one, posts ago.
>>>> [snip]
>>> Imporved version:
>>> [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.

[BORED] Re: forkbombing Linux distributions

[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

On Mon, Mar 28, 2005 at 10:35:00PM +0200, Renate Meijer wrote:
> 
> On Mar 28, 2005, at 9:39 PM, folkert@vanheusden.com wrote:
> 
> On Mar 28, 2005, at 9:39 PM, folkert@vanheusden.com wrote:
> 
> >>I already posted one, posts ago.
> >>>>[snip]
> >>>Imporved version:
> >>>[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 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/

Re: forkbombing Linux distributions

[Natanael Copa]

On Mon, 2005-03-28 at 19:28 +0200, Matthieu Castet wrote:
> > 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

Re: forkbombing Linux distributions

[Felipe Alfaro Solana]

On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
<mat@ensilinx1.imag.fr> wrote:
> > 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.

Doesn't do anything on my machine:

# ulimits -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
pending signals                 (-i) 4095
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 100
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

it tops at 100 processes and eats a little CPU... although the system
is under load, it's completely responsive.

Re: forkbombing Linux distributions

[Natanael Copa]

On Thu, 2005-03-31 at 01:46 +0200, Felipe Alfaro Solana wrote:
> On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
> <mat@ensilinx1.imag.fr> wrote:
> > > 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.
> 
> Doesn't do anything on my machine:
> 
> # ulimits -a
...

> it tops at 100 processes and eats a little CPU... although the system
> is under load, it's completely responsive.

100 processes is low. I often have over 150.

I use the patch mentioned here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111209980932023&w=2
(it set the default max_threads and RLIMIT_NPROC to half of the current
default)

and my system survived.

ncopa@nc ~ $ ulimit -u
4093

(I have 1 GiB RAM)

--
Natanael Copa

Re: forkbombing Linux distributions

[Jacek Łuczak]

Natanael Copa napisał(a):
> On Thu, 2005-03-31 at 01:46 +0200, Felipe Alfaro Solana wrote:
> 
>>On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
>><mat@ensilinx1.imag.fr> wrote:
>>
>>>>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.
>>
>>Doesn't do anything on my machine:
>>
>># ulimits -a
> 
> ...
> 
> 
>>it tops at 100 processes and eats a little CPU... although the system
>>is under load, it's completely responsive.
> 
> 
> 100 processes is low. I often have over 150.

On desktop system 150 processes is low too. 250 is safe and sufficient 
value.

> I use the patch mentioned here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111209980932023&w=2
> (it set the default max_threads and RLIMIT_NPROC to half of the current
> default)
> 
> and my system survived.

Hmmm....my didn't when nearly all users start forkbombing!

I think that changing the default max_threads is not a good idea. It 
might solve many problems but forkbombing require something more universal.

	Jacek