Nieuws
image

Forkbomb nog steeds bruikbaar tegen Linux

donderdag 17 maart 2005, 11:39 door Redactie, 24 reacties

Een forkbomb is een programmaatje dat kopieen van zichzelf maakt, net zolang tot alle resources van de computer gebruikt zijn en de machine crashed. Forkbombs zijn redelijk makkelijk te herkennen en uit te schakelen. Hoewel de forkbomb een oude aanvalstechniek is, werkt die nog steeds in veel bekende Linux distributies, dit tot grote verrassing van columnist Jason Miller. Miller kan niet begrijpen dat bruikbaarheid boven security kan gaan als de gevolgen zo ernstig zijn. Om een forkbomb te laten werken moet de shell met "onredelijke beperkingen" zijn ingesteld. Dit heeft op zichzelf niets met de kernel te maken. Wat wel met de kernel te maken heeft, is dat die veel meer processen moet toestaan dan eigenlijk nodig zijn. Aangezien shells vaak standaard het maximaal aantal beschikbare processen mogen draaien, hebben we een probleem, aldus Miller, die in deze column dieper ingaat op de security van de kernel.

Reacties (24)
17-03-2005, 13:22 door Anoniem
Strikte quota managment zou dit soort ongein makkelijk
moeten kunnen voorkomen....
17-03-2005, 13:23 door SirDice
Hmm. In eerste instantie dacht ik "Natuurlijk werkt dat nog". Maar na het
artikel gelezen te hebben ben ik daar niet meer zo zeker van. Ik vraag me
meer af wat er bij de BSD's dan wel goed geregeld is waardoor het daarop
niet werkt. Daar wordt eigenlijk niet zoveel over gezegt. Hij heeft het wel
over limits maar niet welke.

Verder vraag ik me eigenlijk ook af hoe windows zich met een forkbomb
gedraagt. Moet redelijk simpel te maken zijn...toch maar even een keertje
mee spelen :)
17-03-2005, 13:29 door raboof
Even nuanceren: een `forkbomb' is dus een programma dat door
een lokale gebruiker wordt gerund. De lokale gebruiker kan
daarmee zoveel resources vreten dat het systeem onbruikbaar
wordt.

Het zou natuurlijk mooi zijn als daar betere bescherming
voor geboden werd, maar ik betwijfel of de grote concurrent,
Windows, het beter doet.

Daarnaast kun je misschien dit specifieke geval wel
oplossen, maar dan zijn er waarschijnlijk legio
mogelijkheden om hetzelfde te bereiken (een programma wat
belachelijk veel disk-io doet bijvoorbeeld).
17-03-2005, 14:03 door Anoniem
Kan me niet voorstellen dat je het proces niet met -9 kunt
killen. Duurt wellicht alleen even voor de processor tijd
voor je heeft ;)
In het Nederlands schrijft men de tegewoordige tijd van
crashen als crasht. overigens.
17-03-2005, 14:05 door Anoniem
De design van Linux laat dit natuurlijk toe. Eigenlijk moet het van grond af
aan opnieuw geschreven worden om dit soort onzin tegen te kunnen gaan.
Maar dat heb je met oude code, oude besturingssystemen noem maar op.
17-03-2005, 14:07 door Anoniem
tsja je kan natuurlijk makkelijk instellen dat een proces
maar zoveel children mag hebben of een proces en al zijn
children maar zoveel geheugen/processortijd mogen hebben,
maar dan zit je meteen al beperkingen op te leggen:
misschien wil je juist wel 1 proces dat alle resources mag
hebben en voorrang krijgt boven anderen.

De OOMkiller daar valt wel weer genoeg negatiefs over te
zeggen, alhoewel tegen de tijd dat je die tegen je krijgt je
applicaties anders ook geen geheugen meer kunnen toewijzen
(en helaas checken de meeste programma's dat niet goed en
die zullen dan toch crashen).
17-03-2005, 14:16 door Anoniem
Door raboof
Even nuanceren: een `forkbomb' is dus een programma dat door
een lokale gebruiker wordt gerund. De lokale gebruiker kan
daarmee zoveel resources vreten dat het systeem onbruikbaar
wordt.

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

That's all..
Maar indien je mensen shell access geeft, vertrouw jij je in principe, dus
men zal niet bewust het systeem onderuit willen trekken.

En indien iemand illegaal shell access heeft verkregen zal hij proberen
voor root te gaan en dan kan hij zowieso al alles op die machine.

Vroeger werden forkbomb (Denial of service) gebruikt om systemen te
laten crashen/vertragen zodat men kon spoofen of om authenticatie
mechanismen heen kon.
17-03-2005, 15:28 door [Account Verwijderd]
[Verwijderd]
17-03-2005, 15:45 door SirDice
Door Anoniem
De design van Linux laat dit natuurlijk toe. Eigenlijk moet het van grond af aan opnieuw geschreven worden om dit soort onzin tegen te kunnen gaan. Maar dat heb je met oude code, oude besturingssystemen noem maar op.
In dat geval zouden de BSD's er ook last van moeten hebben aangezien
die code vele malen ouder is dan die van Linux. Maar dat blijkt dus niet het geval te zijn.
17-03-2005, 15:53 door Anoniem
nog geen sneer van een Windows gebruiker gezien, da's nieuw :-)
17-03-2005, 15:54 door Anoniem
Door Hugo
Kwestie van PAM goed instellen.

Welk proces binnen je Plugable authentication module kan dit
voorkomen? (buiten het authenticeren van users)
17-03-2005, 15:58 door Daan.
Door SirDice
In dat geval zouden de BSD's er ook last van moeten hebben
aangezien
die code vele malen ouder is dan die van Linux. Maar dat blijkt
dus niet het geval te zijn.

Freebsd implementeert, behalve ulimit / pam, ook login userroles
(maw, je deelt elke gebruiker in een rol met bepaalde limieten)
genaamd login.conf ( http://www.freebsd-howto.com/HOWTO/
Login-Class-HOWTO ) en een aantal sysctl variablen, een aantal
van de belangrijkste in dit geval:
- kern.maxprocperuid
- kern.threads.max_threads_per_proc
- kern.threads.max_groups_per_proc

Wellicht geeft dit wat meer inzicht over hoe (iig) fbsd dit probleem
aanpakt. Natuurlijk blijft het de verantwoordelijkheid van de
beheerder en de gebruikers om dit soort aanvallen te
voorkomen.
17-03-2005, 16:43 door Anoniem
Door Anoniem
nog geen sneer van een Windows gebruiker gezien, da's nieuw :-)
We laten jullie eerst beseffen dat dit heel veel lijkt op de M$ problematiek
en dat Linux eigenlijk niets beter is. Daarna kunnen we tot de conclusie
komen dat veiligheid, patchen noem maar op, op beide systemen voor en
nadelen heeft maar eigenlijk gelijk is. Daarna kijken we naar het
gebruikersgemak en wil je alleen nog maar M$. (hehe)
17-03-2005, 17:03 door rob
Door Anoniem
De design van Linux laat dit natuurlijk toe. Eigenlijk moet
het van grond af
aan opnieuw geschreven worden om dit soort onzin tegen te
kunnen gaan.
Maar dat heb je met oude code, oude besturingssystemen noem
maar op.

Jij lult maar wat... van de grond af herschrijven. Je moet
niet zomaar wat roepen. Met 1 regel in
/etc/security/limits.conf fix ik het.
17-03-2005, 17:09 door SirDice
Door Daan
Freebsd implementeert, behalve ulimit / pam, ook login userroles (maw, je deelt elke gebruiker in een rol met bepaalde limieten) genaamd login.conf {...}[/quote]Klopt. Die ken ik. Maar voor zover ik kan zien heeft elke standaard user
geen limits.
- kern.maxprocperuid
- kern.threads.max_threads_per_proc
- kern.threads.max_groups_per_proc
Ah. Jaaaah!
kern.maxprocperuid: 1789
kern.threads.max_threads_per_proc: 1500
kern.threads.max_groups_per_proc: 1500

Daar zal het in zitten. Linux zal dergelijke sysctls (of iets vergelijkbaars)
toch ook wel hebben?
17-03-2005, 18:46 door Anoniem
Door Anoniem
nog geen sneer van een Windows gebruiker gezien, da's nieuw
:-)

omdat die geen idee hebben waar het over gaat... :D

fork... threads.. zal wel iets als punniken met eetgerei zijn..
17-03-2005, 20:21 door Anoniem
Door Anoniem
Door raboof
Even nuanceren: een `forkbomb' is dus een programma dat door
een lokale gebruiker wordt gerund. De lokale gebruiker kan
daarmee zoveel resources vreten dat het systeem onbruikbaar
wordt.

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

That's all..

Die is veel te lastig, maak een shell-script met _een_ regel
waarin hij zichzelf weer aanroept.
17-03-2005, 20:23 door Anoniem
Door rob
Jij lult maar wat... van de grond af herschrijven. Je moet
niet zomaar wat roepen. Met 1 regel in
/etc/security/limits.conf fix ik het.

In mijn limits.conf heb ik het volgende staan maar ik ben
nog steeds in staat om de doos (SuSE 9.2) vast te laten lopen:

* soft nproc 64
* hard nproc 128
17-03-2005, 21:45 door Anoniem
Zo is dat: /etc/security en PAM. Wat je ook kunt doen is een
ACL systeem draaien. Overigens werkt dit 'net zo goed' op
Windows en *NIX... en een systeem met shell gebruikers heeft
dergelijke restricties doorgaans, of een oplettende admin.
Kortom, gezeur over niets. Op z'n best een verkeerde default
configuratie...
18-03-2005, 05:26 door spatieman
onder windows kun je het zelfde doen met batch files :)
ik ken iemand die heeft een open linux shell, denk dat ik
die eens ga plat leggen.. :)
18-03-2005, 13:50 door Anoniem
Door Anoniem
Door Anoniem
Door raboof
Even nuanceren: een `forkbomb' is dus een programma dat door
een lokale gebruiker wordt gerund. De lokale gebruiker kan
daarmee zoveel resources vreten dat het systeem onbruikbaar
wordt.

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

That's all..

Die is veel te lastig, maak een shell-script met _een_ regel
waarin hij zichzelf weer aanroept.


Maar C is toch veel leuker!!
18-03-2005, 14:32 door Anoniem
Door spatieman
onder windows kun je het zelfde doen met batch files :)
ik ken iemand die heeft een open linux shell, denk dat ik
die eens ga plat leggen.. :)

fijne vent !!
18-03-2005, 17:56 door Walter
Goed even een test gedaan:
echo -n .
./l

.............................................................../l:
fork: Systeembron tijdelijk niet beschikbaar

Is dus niets aan de hand met de volgende twee regels in:
/etc/security/limits.conf

* soft nproc 64
* hard nproc 128

Ofwel: de settings zijn standaard niet helemaal lekker, maar
ik gok dat de verschillende distributies wakker zijn
geschud, en dat dit dus bij de eerstvolgende releases is
opgelost.
19-03-2005, 02:09 door Anoniem
Door Walter
Goed even een test gedaan:
echo -n .
./l

.............................................................../l:
fork: Systeembron tijdelijk niet beschikbaar

Is dus niets aan de hand met de volgende twee regels in:
/etc/security/limits.conf

* soft nproc 64
* hard nproc 128

Ofwel: de settings zijn standaard niet helemaal lekker, maar
ik gok dat de verschillende distributies wakker zijn
geschud, en dat dit dus bij de eerstvolgende releases is
opgelost.
In Fedora Core 3 staat standaard niets aan.
Maar in het bestand staan nog veel meer dingen die je
hiermee kunt beperken. Vraag is natuurlijk: wat zijn goede
standaardwaarden?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search