# Forkbombe

## hoschi

http://www.pro-linux.de/news/2005/7940.html

a) geht das wirklich so einfach, dass kanns doch nicht sein!?

b) hat man mit NTPL eine überlebenschance, aber wenn fedora daran drauf geht eigentlich nicht

c) ich weiß eigentlich davon gar nichts, und bin total überrascht - eine hohe systemlast kann ich ja verstehen, aber sowas

d) man soll das angeblich über die limits.conf beschränken können, aber sowas ist ja von konzept her reiner schwachsinn da müsste ja jeder limits eintragen bzw. jede distrubtion, sowas ist dann doch ein fehler im gesamtkonzept und gehört ausgemerzt (und das nicht über ein sperre in der shell oder config-dateien)

Die Kommentare auf der Seite sind auch noch ganz interessant, gerade was den Angriff auf den BSD-Server des CCC angeht.

Vielleicht kann sich jemand von den Sachverständigen mir das erklären.

Auf jeden Fall kann es keine Lösung sein solche banale Probleme mit einer Config-Sperre zu "verstecken".

----------

## ian!

 *pro-linux.de wrote:*   

> Demgegenüber zeigte das Script auch bei Red Hat und Gentoo Wirkung.

 

Yo. Alles klar.  :Rolling Eyes: 

Welcher Kernel mit welchen Optionen denn bitte? Wie steht es um die limits? -- Also diese Aussage ist schlichtweg lächerlich.  :Rolling Eyes: 

----------

## stream

testen kann man das mit 

```
:(){ :|:& };:
```

, wenn man keine limits gesetzt hat

ich schätze mal bei debian sind im default zustand schon limits gesetzt

dazu gibts auch eine bugreport https://bugs.gentoo.org/show_bug.cgi?id=85656

----------

## reyneke

 *ian! wrote:*   

> (...)
> 
> Welcher Kernel mit welchen Optionen denn bitte? Wie steht es um die limits?(...)

 

Welche Optionen und Limits sind denn sicher? Hab das vor einiger Zeit mal probiert und damals ebenfalls mein Laptop abgeschossen. 

Die von Gentoo-Security vorgeschlagenen Limits halte ich jedoch manchmal für sehr restriktiv. Nur 15 Prozesse pro User und nur zwei Logins gleichzeitig - reicht das wirklich?

Welche Optionen würdest Du denn im Kernel aktivieren/setzen?

----------

## pablo_supertux

Ich komme mit dieser Aussage allerdings nicht klar:

 *Quote:*   

> 
> 
> In seiner Analyse kommt Miller zu dem Schluß, dass der demonstrierte Exploit kein kernelspezifisches Problem sei. Es sei vielmehr ein Linux-Problem.
> 
> 

 

Linux-Problem? mit er etwa ein Problem des Betriebsystems (in diesem Fall GNU) oder von Linux.

----------

## hoschi

Nachdem mir in einem anderen Forum mehr als nur ein wenig an den Kopf geworfen wurde, weiß ich jetzt wenigstens, dass Linux dabei nicht abstürtzt, sondern einfach gleich jede freies Stücken vom System sofort angelegt. Das wird scheinbar deswegen nicht beschränkt weil Linux eben "frei" ist, und dass gegen das Prinzip wäre (also liegt gar keine Fehler vor).

Ich frage mich jetzt nur, ob es von Distro-Seite her nicht klug wäre, zumindest ein extrem großzügiges Limit zu setzen (ich denke mal so macht man das bei Debian, MacOS, und BSD).

Ich lese mir mal den Bugreport durch, vielleicht steht da mehr. Falls jemand auf die Idee kommt mich anzuscheissen, jaja, ich habe keine Ahnung wie das intern abläuft, aber deswegen frage ich ja.

Danke

----------

## cruxnor

Das Problem mit der limits.conf ist folgende: gillt nur bei User-Logins, die auch PAM benutzen

Sprich alle Logins, die nicht PAM benutzen oder Prozesse die beim Systemstart gestartet wurden usw. werden nicht restriktiert.

```

diff -Nru a/kernel/fork.c b/kernel/fork.c

--- a/kernel/fork.c     2005-03-20 17:21:32.000000000 +0100

+++ b/kernel/fork.c     2005-03-22 21:54:11.000000000 +0100

@@ -120,7 +120,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

```

Aber ich denke dieser Ansatz ist doch ganz interessant?!

-cruxnor

----------

## Mindphaser

 *stream wrote:*   

> testen kann man das mit 
> 
> ```
> :(){ :|:& };:
> ```
> ...

 

Ähm.....

was immer er da macht, es funzt  :Embarassed: 

Als erstes hört die Musik auf zu spielen, dann stockt die Mausbewegung, und ein paar Sekunden später geht garnichts mehr....

Immer wieder Intressant wie einfach man sein System in die Knie zwingen kann.

----------

## NightDragon

Wow... *lach*

So schnell war mein System noch nie ausgelastet.

Kanns nur bezeugen.

Nach einem Enter, wars weg *lach*... 

Ich finde sowas schon tragisch.

Aber ist das ganze nicht ein Bash-Problem in dem Fall?

----------

## Sonic Lux

Ui auch bei mir hat sich das System aufgehangen, was zum Geier macht dieser "Befehl" ?

 :Rolling Eyes: 

----------

## NightDragon

Wenn ich das ganze richtig Verstehe startet fortlaufend Prozesse und macht das immer und immer wieder...

Oder?

----------

## Sonic Lux

Debian Woody überlebt das ganze....

Was muss man an der limits.conf verändern, gibts da vllt. ein nettes Doc für ?

/Edit: welcher Prozess wird eigentlich geforked ?

----------

## NightDragon

Siehe eintrag von cruxnor

D. h. es würde dich zwar davor schützen, wenn Du es ausführen würdest, aber nicht wenns außerhalb von einem PAM ausgeführt würde.

Dann greift die limits.conf nicht.

A ja... versuch mal

```
man limits.conf
```

----------

## cruxnor

 *NightDragon wrote:*   

> Aber ist das ganze nicht ein Bash-Problem in dem Fall?
> 
> 

 

Nein, dies ist ein nettes Feature von Linux. Selbst unpreviligierte User können soviel Prozesse starten wie sie wollen.

 *Sonic Lux wrote:*   

> gibts da vllt. ein nettes Doc für ?

 

1) klar, siehe Suche -> forkbomb

2) http://www.gentoo.org/doc/en/gentoo-security.xml

..hth...

----------

## marc

 *reyneke wrote:*   

> Welche Optionen und Limits sind denn sicher? Hab das vor einiger Zeit mal probiert und damals ebenfalls mein Laptop abgeschossen.
> 
> Die von Gentoo-Security vorgeschlagenen Limits halte ich jedoch manchmal für sehr restriktiv. Nur 15 Prozesse pro User und nur zwei Logins gleichzeitig - reicht das wirklich?
> 
> Welche Optionen würdest Du denn im Kernel aktivieren/setzen?

 

200 Prozesse sollten in der Regel ausreichen, pauschalisieren kann man das aber nicht. Schau mal wieviel du hast und dann weisst du es ja.

Ausserdem ist es auch nicht schlecht noch Quota zu benutzen.

Ich habe das bei meinem System nicht eingerichtet, kein Server. Und wenn es doch passiert reboote ich halt  :Rolling Eyes: 

Zu dem Bericht: Auf Gentoo hat es funktioniert. Es sollten sich diese sogenannten Experten vielleicht auch mal die Distributionen anschauen.

Gentoo ist eine Distri die dem User uberlässt wie er sein System einrichtet. Security-Guides usw. sind ja alle vorhanden, wer sich nicht daran hält oder es damit nicht parat kommt der muss nun halt mal lernen wie man damit umgeht.

Wenn mich jemand mit einem Fork in die Knie zwingt dann bin ich es selber schuld. Das gilt für die anderen Distris auch.

Wenn ein Suse 'hart' konfiguriert ist dann ist es nicht mehr Userfreundlich, wenn zu 'soft' dann ist es nicht mehr sicher? *schmunzel*

Sehr amüsant.

----------

## NightDragon

Wow... @ cruxnor. Aber ich hab das schon richtig verstanden, das es nur PAM-Logins sind, die durch limits.conf geregelt werden oder?

*g* und als kleine Ergänzung auf deutsch: http://www.gentoo.org/doc/de/gentoo-security.xml

----------

## cruxnor

 *NightDragon wrote:*   

> Wow... @ cruxnor. Aber ich hab das schon richtig verstanden, das es nur PAM-Logins sind, die durch 
> 
> limits.conf geregelt werden oder?
> 
> 

 

Jup, hier ein kleiner Auszug aus der Anleitung:

```

Note: /etc/security/limits.conf is part of the PAM package and will only apply to packages that use PAM.

```

 *NightDragon wrote:*   

> 
> 
> *g* und als kleine Ergänzung auf deutsch: http://www.gentoo.org/doc/de/gentoo-security.xml

 

 :Very Happy:   :Very Happy: 

----------

## Earthwings

 *Sonic Lux wrote:*   

> Ui auch bei mir hat sich das System aufgehangen, was zum Geier macht dieser "Befehl" ?
> 
> 

 

Wenn man es etwas ausführlicher schreibt, wird es deutlicher: 

```
fork()

{

  fork | fork &

}

fork

```

Das heißt, es werden rekursiv neue Prozesse gestartet, nach n Durchläufen gibt es bereits 2^n Prozesse.

----------

## Sonic Lux

Und welcher Prozess wird nun geforked, es bringt ja nix einen Prozess zu forken der schneller wieder beendet ist als ein neuer gestartet wird, dann würde es ja nicht zu so einem Überlauf kommen und das System stocken....

----------

## cruxnor

 *marc wrote:*   

> 
> 
> 200 Prozesse sollten in der Regel ausreichen

 

Soviel ich weiß hat ein OpenBSD System bei 512MB Speicher so um die 500 Prozesse frei. Da OpenBSD sehr auf Security abgestimmt ist, denke ich, dass diese "Pie mal Daumen"-Regel auch auf die restlichen Systeme anwendbar ist.

-cruxnor

----------

## Earthwings

Das & weist die bash an, den Befehl als Hintergrundprozess zu starten. Da der Hintergrundprozess selber wieder zwei Hintergrundprozesse startet und die zwei Hintergrundprozeses wieder jeweils zwei Hintergrundprozesse starten, die wiederun... kommt es nie zu einer Beendigung.

----------

## moe

Es wird rekursiv getan, sprich der erste Prozess ruft 2 weitere als Kind auf, diese wiederum 2 weitere usw.. Keins der Kinder stirbt, da sie immer wieder neue Kinder und Kindeskinder erzeugen.

----------

## Sonic Lux

 *moe wrote:*   

> Es wird rekursiv getan, sprich der erste Prozess ruft 2 weitere als Kind auf, diese wiederum 2 weitere usw.. Keins der Kinder stirbt, da sie immer wieder neue Kinder und Kindeskinder erzeugen.

 

ahhhh oki dann ist alles klar

mit ulimit sollte man das Problem auch lösen können, hab aber mein ulimit wegen irgendwas auf unlimited gestellt, weiß aber nicht mehr wieso  :Confused: 

----------

## c07

Bei mir (Duron 700) macht ein " :Sad: ){  :Neutral: :& };:" das System nur für gut 1 Minute ziemlich unbrauchbar, dann sind alle seine Prozesse gestorben. Der Kernel limitiert die Zahl der Prozesse durchaus selber, aber das standardmäßige Limit könnte für manche Konfigurationen zu hoch sein (insbesondere bei 4KB-Stacks und wenig Swap). Kann man in /proc/sys/kernel/threads-max ändern (ulimit -u ist maximal die Hälfte davon).

Viel effektiver ist normalerweise ein derartiges Programm:

```
#include <stdlib.h>

#define SIZE (512*1024*1024)

int main() {

  int x= 0; char * p, * a= calloc( SIZE, 1 );

  while ( 1 ) for ( p= a; p < a + SIZE; p += 4096 ) x += *p;

}
```

Wobei SIZE dem physikalischen Speicher entspricht. Da kann man nur noch hoffen, dass der OOM-Killer bald kommt und möglichst wenig Kollateralschäden anrichtet. Eine kleine Schleife, die das Programm immer wieder neu aufruft, wenn es gekillt worden ist, wird es aber meistens überleben. Das kann man auch nur mit ziemlich restriktiven Limits verhindern (Speicherlimit mal Loginlimit muss deutlich unterhalb vom physikalischen Speicher liegen).

----------

