Lokaler DOS in FreeBSD 6.0 möglich?

  • Ersteller Ersteller tib
  • Erstellt am Erstellt am
Bestätigt. Auf -PRERELEASE-6.1 (von dieser Woche).

Bitte einen PR machen und am besten gleich auch auf der Mailingliste darauf verweisen. Vielleicht wird das bis zum Release beseitigt.

Gut gemacht. Ein sauberer Absturz :)
 
geht eigentlich dieser dos hier noch?

Code: 
% echo "bash forkme.sh&" >forkme.sh
% echo "bash forkme.sh&" >>forkme.sh
% bash forme.sh
?
 
Ich kannte nur while : do $0&; done

Da ich ein neugieriges Kerlchen bin, habe ich Dettus Forkbombe, sowie die aus Moonlooks Signatur mal bei mir ausprobiert.

Also die von Dettus hat das System halbwegs einfrieren lassen, aber nach 10 Minuten hatte ich keine Lust mehr zu warten. Tippen, LEDs etc. ging noch.

Die
Code: 
:() { :& :& } ;:
hat voll reingehauen. Nach kurzer Zeit ging die Hochstell-LED nicht mehr. Das deute ich normalerweise als klinischen Tod. Auch nach einiger Zeit warten hat er sich nicht mehr davon erholt.

@dettus: nein, wann soll der denn zum letzten mal gegangen sein? Ist das hier etwa L****?
Zum Vergrößern anklicken....
Heißt das, dass ich irgendwas falsch konfiguriert habe, oder habe ich bloß nicht lange genug gewartet? Oder sind wir doch Linux in dieser Hinsicht nicht allzu überlegen?

Interessiert mich wirklich!

======================

Also war ich wie immer etwas schneller im Tippen als im Denken.
Aber ein Bisschen wundert es mich schon, dass

#ulimit
unlimited

die Voreinstellung ist.

Hätte mir ja auch jemand sagen können ;)
 
Zuletzt bearbeitet:
Wie kann man solche Attacken auf einem Mehrbenutzersystem eigentlich generell unterbinden? Nehmen wir an, ich habe eine OpenBSD-Kiste, auf die sich etwa 100 User per ssh einloggen können. Nun kann ich zwar über die login.conf.db für diese User stringente Werte für datasize, maxproc, memorylocked, cputime und priority festlegen - wenn jedoch alle eingeloggten User gleichzeitig ihre Forkbombe starten, kann das System zum Erliegen gebracht werden. Wie kann man dem vorbeugen?

Unter SELinux beispielsweise ist es per MAC relativ einfach, solche Angriffe im Ansatz zu unterbinden. Wie geht das unter Free- und OpenBSD?
 
FreeBSD unterstützt auch MAC. Und ich vermute einfach mal das es das schon tat als es SELinux noch nicht gab.
 
@ [LoN]Kamikaze:

Was muss man denn unter FreeBSD konkret per MAC tun, um den von tib repräsentierten local DOS zu verhindern? Und wie verhindert man unter OpenBSD eine Forkbombe, wenn diese von sehr vielen, eingeloggten Usern gleichzeitig gestartet wird?

@ Maledictus:

Das kriege ich jetzt nicht mehr auf die Reihe, da ich seit einem Jahr kein Linux mehr benutze und auch gerade keines zur Verfügung habe. Ich hatte damals eine Gentoo-SELinux-Installation und habe als lokal eingeloggter User mit verschiedenen Varianten von Forkbombs herumgespielt, und unter keiner einzigen Variante war es mir möglich, das System unbenutzbar zu machen.
 
Ich habe mein System mal mit einem Skript

Code: 
#!/bin/sh
$0 &
$0 &
$0 &
$0 &

getötet. Das das funktioniert hat mich allerdings überracht, da ich immer dachte das die Zahl der Prozesse pro Nutzer begrenzt ist. Bei ner Freesbie hat es nicht funktioniert.
 
[LoN]Kamikaze schrieb:
FreeBSD unterstützt auch MAC. Und ich vermute einfach mal das es das schon tat als es SELinux noch nicht gab.
Zum Vergrößern anklicken....
Du vermutest falsch.


Es gibt SEBSD, also FreeBSD mit der FLASK/TE Policy von SELinux draufportiert. Da ich aber nicht weiß, wie SELinux fork-bombs handhabt, kann ich nicht sagen, ob es dagegen hilft.
Die FreeBSD Standard Policymodule helfen jedenfalls nichts. Man bräuchte imho eine Art SysCall Firewall mit Rate-Limit.
 
[LoN]Kamikaze schrieb:
Ich habe mein System mal mit einem Skript

Code: 
#!/bin/sh
$0 &
$0 &
$0 &
$0 &

getötet. Das das funktioniert hat mich allerdings überracht, da ich immer dachte das die Zahl der Prozesse pro Nutzer begrenzt ist. Bei ner Freesbie hat es nicht funktioniert.
Zum Vergrößern anklicken....

Den ersten zwei $0 hast Du wohl nicht uebern Weg getraut? ;-) (SCNR)
 
Ich weiß das 2 reichen, aber 4 sollten doch eigentlich doppelt so schnell gehen. :)

Elessar schrieb:
Du vermutest falsch.


Es gibt SEBSD, also FreeBSD mit der FLASK/TE Policy von SELinux draufportiert. Da ich aber nicht weiß, wie SELinux fork-bombs handhabt, kann ich nicht sagen, ob es dagegen hilft.
Die FreeBSD Standard Policymodule helfen jedenfalls nichts. Man bräuchte imho eine Art SysCall Firewall mit Rate-Limit.
Zum Vergrößern anklicken....
Ich rede nur von Mandatory Access Control. Das kann man mit

options MAC

im Kernel aktivieren. Natürlich weiß ich nicht wie lang es das schon gibt.
 
Exakt das sagte ich doch. Deine Vermutung FreeBSD hätte länger MAC ist falsch.
Dann neuer Absatz, anderer Claim.

SELinux wurde Dezember 2000 released, das TrustedBSD Project hat 2000 überhaupt erst angefangen. Und Flask/TE ist eine Art von Mandatory Access Control Policy.
 
Habt Ihr alle etwas am FreeBSD umgestellt? Insbesondere die sysctls kern.maxproc und kern.maxprocperuid?

Ich krieg hier keinen DOS hin mit den Skripten. Irgendwann labert FreeBSD was von "Cannot fork, resource temporarily unavailable" und dann noch was, dass ich tuning(7) lesen soll. Dann war es das aber, die Prozesse sind alle gestorben und der Rechner war wieder 100% idle.

In der login.conf sind auch die Standardeinstellungen.
 
Abstürzen tut er bei mir auch nicht mehr. Aber das system legt zumindest mein Beispielskript faktisch doch lahm. Die Auslastung ist nämlich so hoch, das der Rechner auf eingaben nicht mehr vorhersagbar reagiert. Z.B. von X auf eine Konsole wechseln... 10 Minuten. root eintippen, nochmal 10 Minuten... bis man auf diese Weise das Skript gestoppt hat ist eine Ewigkeit vergangen.
 
Ich lasse meine Rechner mit kernel.debug laufen. Vielleicht bremst der ganze Krempel das System irgendwie ab (was ich eigentlich nicht glaube).

Ich habe jedenfalls als letztes per ssh versucht. War immer noch ganz ok und konnte gut tippen. Muss man halt abwarten, sich die UID des Users aus dem syslog aufschreiben und später den Betreffenden erschießen. ;)
 
tib schrieb:
Es gibt doch hier Nutzer von DragonFlyBSD, NetBSD, OpenBSD, usw.
Haben die auch mal getestet wie sich Ihr System bei Aufruf der angegeben Befehle erhält?
Zum Vergrößern anklicken....

Also OpenBSD-3.9-BETA-i386 juckt dein local DOS nicht im geringsten. Habe auch diverse Perl- und Shell-Forkbombs ausprobiert, OpenBSD macht das nichts aus.

Allerdings mit folgendem kompilierten C-Program konnte ich OpenBSD in die Knie zwingen:

Code: 
#include <unistd.h>

int main(void)
{
  while(1) { 
    fork(); 
  } 
  return 0; 
}

Die Maschine musste per hard reset neu gebootet werden. Abhilfe verschaffte lediglich ein Eingriff in die login.conf (stringentere Werte, wie bereits weiter oben angedeutet).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben