Forkbomb nog steeds bruikbaar tegen Linux
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)
Strikte quota managment zou dit soort ongein makkelijk
moeten kunnen voorkomen....
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 :)
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).
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).
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.
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.
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.
aan opnieuw geschreven worden om dit soort onzin tegen te kunnen gaan.
Maar dat heb je met oude code, oude besturingssystemen noem maar op.
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).
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).
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.
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 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.
die code vele malen ouder is dan die van Linux. Maar dat blijkt dus niet het geval te zijn.
Door Hugo
Kwestie van PAM goed instellen.
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.
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.
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 nog geen sneer van een Windows gebruiker gezien, da's nieuw :-)
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.
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: 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?
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.threads.max_threads_per_proc
- kern.threads.max_groups_per_proc
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?
Door Anoniem
nog geen sneer van een Windows gebruiker gezien, da's nieuw
:-)
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..
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.
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.
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.
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
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...
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.. :)
ik ken iemand die heeft een open linux shell, denk dat ik
die eens ga plat leggen.. :)
Door Anoniem
Door Anoniem
Maar C is toch veel leuker!!
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.
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!!
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.. :)
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:
.............................................................../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.
echo -n .
./l
./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.
Door Walter
Goed even een test gedaan:
.............................................................../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.Goed even een test gedaan:
echo -n .
./l
./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.
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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
