forkbomb attack
 

Zhukov Pavel wrote:

why modern fedora affected by simple forkbomb attack?



Because it's hard to set static defaults that are reasonable for both a low-end
laptop and a 16-core server with 128 GB of RAM. Theoretically we could
configure the defaults in limits.conf dynamically at installation time, but no
one has ever cared enough to write the code and test it on the wide range of
hardware and software configurations required to get it right.


Personally, I find the current settings work just fine. The only way I can
forkbomb my old 384 MB, 1-core powerbook is with a synthetic forkbomb, and the
fix for it is "don't do that". It survives an accidental forkbomb, such as
those caused by foolish application handler settings. If you're running
arbitrary code from untrusted users, a forkbomb is the least of your problems.
On my 2-core, 2 GB systems, which is a reasonable minimum target for interactive
servers allowing logins by semi-trusted users, I can't even synthetically
forkbomb the box without root privileges. The most I can do is lock up my X
server, which is cured by a remote ssh and a kill. This might be what's
happening to you.


If you think there's something really wrong, please open a bug with specifics.

-- Chris

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

forkbomb attack
 

On Nov 30, 2007 5:52 PM, Chris Snook <csnook@redhat.com> wrote:
> Zhukov Pavel wrote:
> > why modern fedora affected by simple forkbomb attack?
> >
>
> Because it's hard to set static defaults that are reasonable for both a low-end
> laptop and a 16-core server with 128 GB of RAM. Theoretically we could
> configure the defaults in limits.conf dynamically at installation time, but no
> one has ever cared enough to write the code and test it on the wide range of
> hardware and software configurations required to get it right.
>
> Personally, I find the current settings work just fine. The only way I can
> forkbomb my old 384 MB, 1-core powerbook is with a synthetic forkbomb, and the
> fix for it is "don't do that". It survives an accidental forkbomb, such as
> those caused by foolish application handler settings. If you're running
> arbitrary code from untrusted users, a forkbomb is the least of your problems.
> On my 2-core, 2 GB systems, which is a reasonable minimum target for interactive
> servers allowing logins by semi-trusted users, I can't even synthetically
> forkbomb the box without root privileges. The most I can do is lock up my X
> server, which is cured by a remote ssh and a kill. This might be what's
> happening to you.
>
> If you think there's something really wrong, please open a bug with specifics.
>
> -- Chris
>
> --
> fedora-list mailing list
> fedora-list@redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

hm. for example, can i keep in reserve for example 5% of system
resources for root user?

i just successfully DoS C2D5600/2GB laptop with simple :(){ :|:& };:

:(

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

forkbomb attack
 

On Fri, 30 Nov 2007 17:37:48 +0300
"Zhukov Pavel" <gelios@gmail.com> wrote:

> why modern fedora affected by simple forkbomb attack?

As its shipped with defaults that are in keeping with a desktop system,
normally single user which is generally how Fedora is used. If you
configure the various control features it'll behave rather differently.

See /etc/security/limits.conf

Also /etc/sysctl.conf

vm.overcommit_memory = 2

Alan

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

forkbomb attack
 

Zhukov Pavel wrote:

On Nov 30, 2007 5:52 PM, Chris Snook <csnook@redhat.com> wrote:

Zhukov Pavel wrote:

why modern fedora affected by simple forkbomb attack?


Because it's hard to set static defaults that are reasonable for both a low-end
laptop and a 16-core server with 128 GB of RAM. Theoretically we could
configure the defaults in limits.conf dynamically at installation time, but no
one has ever cared enough to write the code and test it on the wide range of
hardware and software configurations required to get it right.

Personally, I find the current settings work just fine. The only way I can
forkbomb my old 384 MB, 1-core powerbook is with a synthetic forkbomb, and the
fix for it is "don't do that". It survives an accidental forkbomb, such as
those caused by foolish application handler settings. If you're running
arbitrary code from untrusted users, a forkbomb is the least of your problems.
On my 2-core, 2 GB systems, which is a reasonable minimum target for interactive
servers allowing logins by semi-trusted users, I can't even synthetically
forkbomb the box without root privileges. The most I can do is lock up my X
server, which is cured by a remote ssh and a kill. This might be what's
happening to you.

If you think there's something really wrong, please open a bug with specifics.

-- Chris

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list



hm. for example, can i keep in reserve for example 5% of system
resources for root user?


If you mean CPU time, this is precisely what the upstream group scheduler work
will do. It's a work in progress.



i just successfully DoS C2D5600/2GB laptop with simple :(){ :|:& };:


Did you try switching virtual terminals with ctrl-alt-f*, killing X with
ctrl-alt-backspace (assuming it's running in an xterm), or sshing in remotely?
The most I can do on a similar machine is hang X.


-- Chris

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list