Hoofdcategorieën
Device Settings

Fout in Linux-kernel maakte Debian-hack mogelijk

Door Martin Sturm, dinsdag 2 december 2003 10:12
Bron: Slashdot, views: 1.569

Op Slashdot is te lezen dat de methode waarop onlangs root-toegang werd verkregen op de servers van het Debian-project, is vastgesteld. De oorzaak bleek te liggen in een tot dusver onbekende bug in de Linux-kernel waardoor een gebruiker zonder root-rechten volledige toegang kon verkrijgen tot het kernel-geheugen, waardoor de gebruiker alle toegangsrestricties kan omzeilen. De exploit die werd gebruikt voor het hacken van de Debian-servers was in versleutelde binaire vorm achtergelaten op de getroffen servers. Nadat het versleutelde programma was bestudeerd door onder andere beveiliginsexperts van SUSE en Red Hat kwam de bug in de kernel snel aan het licht.

Inmiddels is er de 2.4.23-kernel voorzien van een fix die de bug verwijdert. Ook in de 2.6-kernel serie is de bug inmiddels geëlimineerd. De meeste distributies, waaronder uiteraard Debian, voorzien inmiddels in een nieuwe kernel die het probleem verhelpt:

Bug stampen (klein)Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Volgende 10:24 Toekomstige PlayStations gaan emoties gebruiker lezen
Vorige 10:05 Shuttle SB75G2 en Soldam Altium RS4 review
Advertentie

Reacties

«  1  2  3  »


Euh :? Ik weet niet waar jij normaal zit maar meestal zijn die updates er binnen 1 of 2 dagen bij een ernstig probleem, of het moet gewoon een moeilijke oplossing oid zijn.

En euh.. mja binnen een week... zo kan ik het ook:
This problem was found in September
Inmiddels is er de 2.4.23-kernel voorzien van een fix die de bug verwijderd
Volgens mij is dat langer dan een week?

Een vergelijkbare bug als deze zit sinds jaar en dag ook in windows en wordt daar gewoon helemaal niet gefixed. Microsoft heeft het een feature genoemd omdat ze die bug niet willen oplossen! ;)

edit: waarom wordt een relativerende post als troll gezien?

Een aantal MS fans doen wel heel moeilijk over deze bug, maar dezelfde bug heeft dus ALTIJD al in windows gezeten, en blijft er ook in vanwege compatilibiteits-redenen.

Hoe kan een feit nu een troll zijn :?

* 786562 Gotty

het zou misschien helpen als je je "kritische feiten" met een beetje onderbouwing zou brengen. Windows en linux zijn weinig compatible mt elkaar, dus het komt op 99% van de gebruikers vreemd over dat een linux bug ook al lang in windows zit. Als je nou een linkje zou posten, met uitleg over dit probleem, of een fatsoenlijke uitleg erbij zet, dan kijg je in no-time een "+4 interessant". Als je in je post gaat lopen huilen over je moderatie dan zit er niet meer in dan een "0-gemodereerd"

Deze link is al eerder in deze draad genoemd.
http://security.tombom.co.uk/shatter.html
Het is best makkelijk om een windowsmachine op die manier te cracken. Een vriend van me heb ik het zien doen. Echt zo gepiept :) Kind kan de was doen.


Dat je die link niet hebt gezien is misschien omdat deze onder het maaiveld is gemod door een MS-fan. :( Mooie boel weer hier op T.net.

* 786562 Gotty
Veel Linux-fans kennen die beveiligingsgaten in windows namelijk wel. Oh, w8..... DAAROM gebruiken ze ook liever geen windows :P

Lees het eens goed, het komt erop neer dat je via een applicatie met administrator rechten (in zijn voorbeeld een virusscanner), de security omzeilt. Het probleem is dus niet zozeer een windows probleem alswel dat bepaalde windows applicaties niet secure zijn. Auteur geeft te kennen dat dit puur een windows probleem is, maar dat is bullshit.

Vergelijkbare problemen zouden ook onder *nix kunnen voordoen, als een applicatie onder Root Rechten draait, en kan communiceren met een "user", zou als het programma niet goed in elkaar zit, ook misbruik kunnen worden gemaakt.

Ik moet wel zeggen dat het windows messaging systeem alles behalve solide in elkaar zit, als ik de auteur mag geloven, maar om nou te gaan roepen dat windows dan niet secure is, is overdreven.

Daarnaast is het zo, dat het op windows machines niet erg gebruikelijk is om andere mensen zomaar visueel toegang te geven (zeker niet op servers).

Ja, Uiteraard probeert microsoft de onoplosbare beveiligingsgaten in windows te verdoezelen. Desondanks leveren ze zelf overtuigend bewijs om Linux te gebruiken.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/col umns/security/essays/10imlaws.asp

Lees het eens goed, het komt erop neer dat je via een applicatie met administrator rechten (in zijn voorbeeld een virusscanner), de security omzeilt. Het probleem is dus niet zozeer een windows probleem alswel dat bepaalde windows applicaties niet secure zijn.
Nee, lees jij het eens eens goed ;)

Het probleem van het Windows message systeem is dat ieder window een message kan sturen naar ieder ander window, en dat het ontvangende window niet kan controleren waar de message vandaan kwam (!). Daar komt nog bij dat sommige messages bijzonder lompe dingen kunnen doen zonder medeweten of tussenkomst van het doel-window.

Uit de tekst:
Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. Silly, silly, silly...
Dus je kunt een window van een andere applicatie een WM_TIMER message sturen, en dan gaat die ontvangende applicatie code uitvoeren op het adres dat jij aanwijst! En dat - voorzover de schrijver weet - zonder dat het doel-window dat kan weigeren.

Dat is gewoon lomp. En misschien zijn er wel manieren om daaromheen te komen (mogelijk ten koste van bepaalde functionaliteit), maar als het standaard zo makkelijk is om een andere applicatie te beinvloeden, dan is dat een probleem van Windows, niet van de applicaties.

Dat wil ik overigens wel even veralgemeniseren, want dat geldt voor andere situaties net zo goed: Als een platform zo in elkaar zit dat applicaties voor fatsoenlijke security om het platform heen moeten werken, dan is dat een probleem van het platform, en niet van de applicaties die er niet omheen werken.
Vergelijkbare problemen zouden ook onder *nix kunnen voordoen, als een applicatie onder Root Rechten draait, en kan communiceren met een "user", zou als het programma niet goed in elkaar zit, ook misbruik kunnen worden gemaakt.
Ja, maar dan gaat het specifiek om fouten in de applicatie.

Een goed voorbeeld is XFree86, de meest gebruikte X server op Free OSsen. XFree86 draait als root. Alle X applicaties (die doorgaans als een gewone user draaien) moeten met de X server comminuceren. Als er in de X server een fout zit waardoor een X client meer kan dan hij zou moeten kunnen, dan is dat een security probleem. Van XFree86 wel te verstaan.

Maar de standaard API die door de Linux kernel wordt aangeboden (voornamelijk POSIX plus wat misc. UNIX98 en BSD spul) maakt het niet mogelijk voor user processes om enige invloed op XFree86 uit te oefenen als XFree86 daar niet mee accoord gaat.

En daar zit het grote probleem met MS Windows' messages: windows kunnen een (te) grote invloed uitoefenen op andere windows zonder dat het doelwindow daar om vraagt of mee accoord gaat.
Daarnaast is het zo, dat het op windows machines niet erg gebruikelijk is om andere mensen zomaar visueel toegang te geven (zeker niet op servers).
Nou... Op desktops en workstations dus juist wel he :)

Wat betreft servers heb je gelijk, daar zal dit gebrek niet zo snel problemen opleveren, maar het is en blijft een fundamenteel win32 probleem.

Ik vraag me toch af of dit probleem vergelijkbaar is. Immers, men is eerst een tijd bezig geweest om te achterhalen wat de bug daadwerkelijk was.

MS en linux vind ik over het algemeen best snel met het patchen, maar het grootste probleem blijft hem toch wanneer de gebruikers zelf patchen....
(kijk maar naar blaster, was al maanden een patch voor)
Wat ik me nu afvraag:
Nu moeten de gebruikers zelf dit patchen (nieuwe kernel compilen?)
Maar ondertussen is wel openbaar gemaakt hóé deze bug precies werkt... dus totdat iedereen gepatched is, zijn alle linux server kwetsbaar, omdat de handleiding op straat ligt.
Had men dan niet beter kunnen patchen en even wachten met de uitleg hóé het gebeurt is, zodat iedereen de tijd heeft om te updaten?

Nu moeten de gebruikers zelf dit patchen
2.4.23 (die al enkele dagen uit is) is gepatcht.
2.6.0-test6 en hoger is gepatcht.
2.2 en 2.0 zijn niet vulnerable.

Alle trees die er (nog minstens een beetje) toe doen zijn dus al gepatcht.


Je vergeet te vermelden dat een pinguin meer roeleert dan een raam. :P

Doe niet zo kinderachtig man. Bovendien is Windows remote zo lek als een zeef en betreft dit een local kernel bug. Ook slecht, maar als we 't zo gaan vergelijken... ;).

Even patchen. Huidige kernels waren ook alweer erg lang safe dus na een jaar een keer rebooten is zeer acceptabel.

local kernel bug
Hoezo local? De aanvaller kwam er toch van buitenaf in :? dat vind ik niet echt local...

P.s. je hoeft niet als Troll te modden voor iets dat jij altijd over Windows zegt hoor...

Local omdat je eerst een account moet hebben op het systeem, voordat je de bug kan misbruiken

Hij is inderdaad local. De kernel is niet remote ge-exploit. Bovendien kan ik je niet als Troll modden daar ik zelf ook reageer.

Tevens probeer ik altijd enige onderbouwing te geven. Je hoeft niet 'zomaar' te reageren hoor. Meld anders ook even iets. :)

ehm niet om het een en t ander, maar dit is een probleem dat een gebruiker , *die al toegang heeft tot je systeem* beheerder kan worden op dat zelfde systeem. 90% van de windows installaties laat elke gebruiker de rol vol beheerder vervullen, dat is wel een verschil

Het probleem was dus al gevonden in september?
dan vraag ik me toch af waarom dit niet gelijk gefixed is in de kernel aangezien het toch een gevaarlijk lek is

Het is wel gefixed... Quote uit link:
http://lists.debian.org/debian-security-announce/debian-security-annou nce-2003/msg00212.html
This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and
2.6.0-test6 kernel tree. For Debian it has been fixed in version
2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386
kernel images and version 2.4.18-11 of the alpha kernel images.

...niet gelijk gefixed...

Debian heeft niet altijd de laatste versies, omdat ze deze eerst uitvoerig testen. Is dit de reden geweest waarom ze Debian gepakt hebben..?

..hebben andere distro's deze bug als wel gepatched in hun kernel-sources? (of gewoon 2.4.23 geinstalleerd)

in unstable zit toch zeker de laatste zooi?

en dan nog, ze hebben wel security updates voor stable en testing

en daar zat voor zover ik weet deze fix ook niet tussen

de echt meest nieuwe zooi zit in testing. :)
De laatste 2.4 kernel zit in unstable en de laatste 2.6 zit in testing (omdat die niet nog final is).

Als die smiley sarcasme uitdrukt, dan hoor je me niks zeggen, maar anders...

Unstable is uiteraard het allernieuwste. Testing (sarge) is bijna klaar voor release (plan was om te releasen op 1 dec, maar dat wordt voor onbepaalde tijd uitgesteld ;)), en dus een stuk stabieler dan unstable (sid). Kernel 2.6 zit in sid, en 2.4 ook natuurlijk.
Of 2.6 al in testing zit vraag ik me af. Kan het nu even niet controleren, maar het klinkt me zeer onwaarschijnlijk in de oren dat in een bijna-release een test-kernel komt te zitten. De laatste 2.4 kernel zal wel in sarge zitten.

En wat deze patches betreft... die zijn nu dus doorgevoerd voor stable, en ook testing en unstable krijgen die binnenkort.

QuarkuS:
Dat is gewoon onzin. Testing is altijd de allernieuwste en geeft de minste garantie dat alles werkt. Unstable bevat alles dat door testing heen komt. Stable is de release waarin alles bijna zeker goed werkt.

Van: http://linuxtoday.com/security/2003120201026SCKNMD
A vulnerability was discovered in the Linux kernel versions 2.4.22 and previous. A flaw in bounds checking in the do_brk() function can allow a local attacker to gain root privileges. This vulnerability is known to be exploitable; an exploit is in the wild at this time.

The Mandrake Linux 9.2 kernels are not vulnerable to this problem as the fix for it is already present in those kernels.
Mandrake 9.2 heeft dus al de juiste kernelpatches. Ik kan me voorstellen dat dat bij andere Distro's ook zo is. Het is natuurlijk wel aan te raden dat even te checken, vooral voor alle serversystemen en pc die direct aan het net hangen.

Het probleem was dus al gevonden in september?
dan vraag ik me toch af waarom dit niet gelijk gefixed is in de kernel aangezien het toch een gevaarlijk lek is
Het is in september gefixt in 2.6.0-test6, maar toen werd niet gedacht dat het bugje exploitbaar zou zijn. Er zijn zo vaak kleine bugs die niet exploitbaar zijn.

Omdat het een bug was, wordt het ook opgelost in de 2.4 serie, namelijk in de 2.4.23-to-be kernel. Als toen bekend was geweest dat de bug exploitbaar was, dan was er meer haast achter gezet, en was misschien 2.4.23 gereleased met die bugfix als enige verandering t.o.v. 2.4.22.

Dat deze bug niet exploitbaar werd geacht is ook de reden dat de gecrackte Debian machines niet gepatcht waren (ze draaiden 2.4.22). Nadat deze machines gecrackt waren is men er dus achter gekomen dat de brk() bug wel exploitable was, en daardoor lees je nu dit nieuwsbericht.

Dit is overigens niet Debian-specifiek; niemand (behalve dus een of enkele crackers) wist dat de bug exploitable was, dus het is waarschijnlijk dat andere distributies ook nog vulnerable kernels draaien en/of aanbieden (ik heb de afgelopen paar uur ineens wat kernel security updates van een aantal distro's langs zien komen ;) ).

Van debian-announce:
Even though this kernel bug was discovered in September by Andrew Morton and already fixed in recent pre-release kernels since October, its security implication wasn't considered that severe. Hence, no security advisories were issued by any vendor. However, after it was discovered to be used as a local root exploit the Common Vulnerabilities and Exposures project has assigned CAN-2003-0961 to this problem. It is fixed in Linux 2.4.23 which was released last weekend and in the Debian advisory DSA 403.

Whoei :)

Een hacker maakt gebruik van een bug in de kernel om nog een "bug" te programmeren. (En het voor hem makkelijker te maken om te hacken)

En nu krijgt hij op zijn brood dat de exploit die hij gebruikte en gemaakt heeft worden ontdekt en hij ze dus niet meer kan gebruiken. :)
Eigenlijk zouden we die hacker moeten bedanken ;)

We hadden de hacker pas kunnen bedanken als hij hier netjes en uitgebreid melding van had gedaan. Niet zoals het nu is gegaan.

Rest mij wel te zeggen dat het hier iemand met enige clue betrof. ;)

Eigenlijk zouden we die hacker moeten bedanken
In zekere zin wel.
Debian was altijd al een der beste keuzes voor een veilig systeem. Dankzij deze hacker zal dat zeker zo blijven. Eigenlijk geldt voor debian hetzelfde als voor OpenBSD:

Zowel Debian als OpenBSD zijn populair EN hebben de naam veilig te zijn. Hackers/crackers zien het als een uitdaging juist die besturingssystemen aan te pakken.

Een vergelijkbare hack is overigens enige tijd geleden bij microsoft geweest. Hackers uit rusland hebben 12 (!) dagen volledige toegang gekregen tot de windows-source. Korte tijd daarna zijn de dns-servers van MS eveneens aangevallen. Saillaint detail is dat door ms ingehuurde beveiligings-experts toen Gnu/Linux-servers hebben ingezet om microsoft beter te kunnen beveiligen. :)

Die hebben niet perse Linux servers ingezet. Maar aangezien de locatie hardcoded in de worm was hebben ze windowsupdate.microsoft.com tijdelijk uitbesteed aan een extern bedrijf met andere ip's. En die draait "toevallig" linux. Met hun hadden ze gewoon goede ervaringen ;)
offtopic:
ik vond het ook wel lache hoor, maar zo zat het nou eenmaal niet :(

Dat zeg ik toch ook :) Het is overigens een hele heisa geweest. Microosft heeft de FBI ingeschakeld maar daders hebben ze nooit kunnen pakken.

Dat de dns servers zo makkelijk down konden van MS was trouwens pure nalatigheid van het bedrijf. Een ontwerpfout.

Debian was altijd al een der beste keuzes voor een veilig systeem.
Zoals nu blijkt, is deze aanname onwaar gebleken.
Dankzij deze hacker zal dat zeker zo blijven.
Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond. Dit is ook gelijk de reden waarom de aanname dat debian de beste keuze was ivm. security DUS niet waar is. Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch

Het enige waar we deze hacker voor kunnen bedanken, is het aantonen dat het debian systeem van kernelbeheer niet secure is.
Eigenlijk geldt voor debian hetzelfde als voor OpenBSD:

Zowel Debian als OpenBSD zijn populair EN hebben de naam veilig te zijn. Hackers/crackers zien het als een uitdaging juist die besturingssystemen aan te pakken.
Wederom imo een verkeerde interpretatie. Debian en OpenBSD zijn helemaal niet populair, het zijn niche producten. Het gros der OSsen is altijd nog windows, *nix, redhat (linux), en dan pas komt de rest. Debian en OpenBSD hebben een actievere community met veel zealots, dat is het verschil.

Juist doordat die zealots altijd om het hardst roepen dat hun systeem secure is, is het voor een hacker leuk om hiermee aan de slag te gaan.

Dit is echt de wereld op z'n kop zetten wat jij doet. Als MS een patch wel heeft, maar niet uitbrengt, en het heeft als gevolg dat de boel gehacked wordt, staat elke linux-zealot op z'n achterste benen moord en brand te schreeuwen, nu maakt Debian zo'n fout en is dat omdat 'ze zo secure zijn'.

Nee, je leest mijn post niet goed. :)

Dergelijk breed uitgemeten zaken werken stimulerend. Een door MS gesponsord onderzoek heeft bijvoorbeeld hetzelfde gedaan voor SAMBA. De opensource-community draait hier juist op.

Debian en OpenBSD zijn wel degelijk populair. Het wordt juist gekozen wanneer zaken echt goed beveiligd moeten worden.

Windows wordt veel gebruikt, maar is erg inpopolair. Je haalt die twee dingen door elkaar denk ik.

Ik lees je post prima hoor. Populair is bij producten synoniem aan marktaandeel, niets meer en niets minder.

Debian en OpenBSD hebben nauwelijks marktaandeel, dus zijn niet populair. Simpel as that.

Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond. Dit is ook gelijk de reden waarom de aanname dat debian de beste keuze was ivm. security DUS niet waar is. Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch
op a: Debian maakt als policy gebruik van de kernels van kernel.org. De zgn. "Stock" kernels. Geen patch/fix in de stock, geen patch/fix in Debian. Of dat een goede of slechte zaak is mag je voor jezelf uitmaken.
op b: Hoe moet je een gebruiker informeren over iets waar je zelf niet van op de hoogte bent? Het feit dat de kernel developers zelf niet aan de alarmbel hebben getrokken heeft m.i. meer te maken met het niet onderkennen van het gevaar van de bug (onderschatting van de impact) dan met onwil/incompetentie van de debian packagers. Kan iemand mij uitleggen hoe je als administrators je servers moet beveiligen tegen gevaren DIE NIET BEKEND ZIJN? Nou kun je wel roepen de bug en fix al in september bekend waren, maar als dat niet gecommuniceerd wordt via de normale kanalen voor beveiligingsfouten, hoe moet men dan als beheerder weten dat er gevaar dreigt? Ik heb het (nog) niet kunnen vinden, maar het zou me niet verbazen dat de fix voor dit 'lek' meer een toevalligheid was dan dat er bewust is onderkent dat het gevaar oplevert. Iemand die mij de LKML post kan laten zien waar iets anders in staat (bijvoorkeur met de betreffende patch erbij) zou ik zeer erkentelijk zijn. Ik heb als beheerder namelijk geen tijd om alle patches die op LKML voorbij vliegen te controleren of er toevallig ook eentje bij zit die een misschien wel of niet gevaarlijk beveiligingslek oplost.

Debian was altijd al een der beste keuzes voor een veilig systeem.

Zoals nu blijkt, is deze aanname onwaar gebleken.
Hoezo? Debian is door deze exploit niet onveiliger dan andere GNU/Linux distributies. Het Debian archive is namelijk niet aangepast, dus Debian gebruikers hebben geen kwaadaardige packages gekregen, en de gebruikte exploit is niet Debian-specifiek.
Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond.
Volgensmij begrijp jij niet goed wat hier aan de hand is. Toen de bug gevonden was, werd aangenomen dat hij niet exploitable is. Debian heeft hiervoor dus geen security updates gedaan, en de andere distributies ook niet.
Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch
Geen enkele distributie heeft A of B gedaan tot enkele uren geleden. In plaats van Debian af te zeiken kun je je misschien wat beter informeren.

OpenBSD is niet echt populair. FreeBSD is véél populairder dan OpenBSD. Het enige voordeel dat OpenBSD heeft ten opzichte van FreeBSD is dat OpenBSD op meer hardware werkt dan FreeBSD. Dit heeft natuurlijk weinig met veiligheid te maken.

Het voordeel van Free/OpenBSD ten opzichte van Linux is dat er een veel betere controlle is op de ontwikkeling van de software. (En dat SCO hier geen claim op heeft) Debian is van de Linux distributies de meest conservatieve. Hierdoor komen er minder vaak bugs voor maar ontbreken er ook vaak mogelijkheden ten opzichte van andere distributies. Mandrake daarentegen neemt bijna altijd de meest recente versie van packages. Hierdoor gaat er wel eens wat fout (opgeblazen CDRoms :( ) maar het voorkomt wel dat oude en al opgeloste problemen zich blijven voordoen.

Wat je nu moet draaien? Geen flauw idee. FreeBSD is vaak iets efficienter als server dan linux. Debian is vrij stabiel. Mandrake heeft de meest recente patches, Red Hat en Suse hebben de beste ondersteuning door commerciele bedrijven. Dus....

<quote>Hoe moet je een gebruiker informeren over iets waar je zelf niet van op de hoogte bent?</quote>
Dat noemen ze nu Intrusion detection en prevention. Het laatste bussword bij security experts. Laat alleen dingen toe die "normaal" zijn en blokeer alles wat abnormaal is.

Deze bug zou hiermee niet tegengehouden worden aangezien het een local exploit was, maar andere onbekende problemen kun je wel voorkomen.

Mandrake daarentegen neemt bijna altijd de meest recente versie van packages. Hierdoor gaat er wel eens wat fout (opgeblazen CDRoms ) maar het voorkomt wel dat oude en al opgeloste problemen zich blijven voordoen.
Voor wie het nu nog niet weet:
1) die opgeblazen cdroms zijn weet tot leven te wekken
2) de oorzaak daarvan lag bij de foute implementatie van LG
3) het probleem kwam door UDF patches die bij SuSE vandaan kwamen
4) o.a. Gentoo gebruikers waren ook getroffen door het probleem, maar er waren er te weinig om statistisch te achterhalen wat nou precies fout was.
5) de patches dateren van juli, pas als een grote distro (in dit geval Mandrake) dergelijke problematische patches toepast komen dat soort problemen aan het licht; het had net zo goed b.v. SuSE kunnen overkomen.

OpenBSD heeft als streven veilig te zijn. Debian heeft een hele andere agenda, hoewel veiligheid ook een punt daarvan is.

Ik vind OpenBSD en Debian verre van vergelijkbaar en ik begrijp eerlijk gezegd niet hoe je op zo'n ridicule uitspraak kan komen.

OpenBSD bevat ProPolice, W^X beveiliging etc. Debian heeft niets van dit alles (hoewel Adamantix, voorheen Trusted Debian, maar hernoemd op verzoek van Debian, hier wel oplossing voor biedt).

De rest van de verschillen is al door anderen aangevoerd.

Al met al denk ik niet dat ik de komende jaren gebruik zal maken van Debian..
Deze keer was het ontdekt.. hoevaak is er iemand 'binnen' geweets die echt wist wat hij/zij deed zonder sporen achter te laten.. Open Source is cool, iedereen kan code toevoegen...

Open Source is cool, iedereen kan code toevoegen...
yup. :Y) maar niet zomaar. Je moet er wel wat voor doen om jouw code in een project te krijgen hoor. Over closed-source worden er ook nuttige opmerkingen gemaakt:
closed-source is cool, je weet maar nooit wat voor een geniepige zaken een commercieel bedrijf in hun programma hebben gestopt

...of nog niet gefixt heeft |:(

Sorry dat laatste is wel een beetje trollig, maar ik kon het niet laten.. :P Met andere woorden, zoals open-source als closed-source ook niet alles, je moet voor jezelf uitmaken waar jij het meeste baad bij hebt in je business.

De bug was niet alleen in Debian aanwezig maar in de linux kernell an sich.. Als je hier zo paranoïa van wordt kun je dus beter alle linux distro's mijden...

De bug was niet alleen in Debian aanwezig maar in de linux kernell an sich.. Als je hier zo paranoïa van wordt kun je dus beter alle linux distro's mijden...
En microsoft windows moet je dan al helemaal mijden! Deze bug zit namelijk ook in windows en is daar zelfs niet oplosbaar vanwege compatibiliteits-eisen. Microsoft heeft die bug dus maar een feature genoemd :P

Debian is en blijft nog steeds het veiligste besturingssysteem imho. Alleen OpenBSD is daarvoor een alternatief.

Sorry Jazzman, maar deze opmerking is niet juist.
De fout lag niet in Debian, maar in de Linux kernel. Elke distributie, SUSE, Red Hat enzovoorts heeft er last van.
En in elke besturingssysteem worden dit soort fouten gevonden, of het nu M$ is of Open Source dat maakt niet uit.
In dit geval duurde het idd uitzonderlijk lang (9 weken) voordat de fout gepatcht was. Lang voor Open Source tenminste, bij M$ weet je vaak niet hoe lang de fout al bekend was.

Volgens mij was de fout heel snel gepatched voor de nieuwe kernels, maar is die 9 weken alleen voor het backporten naar een oude kernel.

Zijn wel wat beveiligingen om te merken of iemand ongeauthoriseerd code probeert aan te passen.

Anyway. In dit geval had je username / password nodig om toegang te krijgen tot een server, en daarna is root verkregen, zoals slashdot meldt, via een programmeerfout in de kernel, die er al uitgehaald was, maar nog niet 'backported' in woody. Als je stap 1 kan vermijden is je desktopje thuis wel veilig.

apt-get update werkt nog steeds niet geheel, alhoewel security.debian.org wel weer apt-gets uitdeelt. :) Binnen een paar dagen is alles weer in orde.

Anyway, thuis draait SID (debian testing). Altijd de laatste bugfixes (en nieuwe bugs :P).

Even voor de duidelijkheid: sid = unstable. testing = sarge

Tja, hoe vaak komt het wel niet voor dat er passwords gesnifft worden, tis toevallig dat ze debian te pakken gehad hebben, voor hetzelfde geld hadden ze de up2date servers van Redhat of windows update te pakken gehad.

Overigens hadden ze dit kunnen voorkomen door een grsecurity kernel te draaien met de nodige opties. Hoe vaak ik smerige programma's wel niet afgeknald zie worden op onze servers vanwege overflows en geheugen waar ze niet aan horen te komen....

Inderdaad.
Gelukkig maakt Debian gebruik van cryptografisch getekende packages. Dat jij er verder niet naar kijkt, en blind installeert wat je voor je kiezen krijgt is niet echt de fout van de distributie.
Als je het nieuws had gevolgd dan had je ook geweten dat de hele repository is gecontroleerd, en is goedbevonden.

Anyway, deze fout kun je niet op de distributie schuiven waarin hij toevallig in is ontdekt. Het is een kernel bug. Dat deze niet met een security advisory negen weken geleden al is gedicht kan verschillende oorzaken hebben. Dat de bug 9 weken geleden al is gevonden en opgelost hoeft niet te betekenen dat negen weken geleden ook al bekend was dat het een probleem betreft dat exploiteerbaar is. Iemand heeft blijkbaar LKML gevolgt, en een andere (juiste) conclusie getrokken. Vervolgens is 'ie ermee aan de haal gegaan, en heeft een paar mensen wakker geschud. Wees blij dat het probleem nu bekend is, en dat het is opgelost.

Om nu gelijk het toevallige slachtoffer links te laten liggen is m.i. ietwat kortzichtig. Als je zo redeneerd dan raadt ik je aan om je PC nu uit te zetten, en er nooit meer aan te komen.

This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Mnou dat schrijft linux dus af voor mij :+

Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.

Dit was dus al bekend en de update is na de eerste keer dat dit misbruikt werd pas uitgebracht. en Dat duurde zelfs nog een week!

toch vraag ik mij af waarom er aan het begin van dit artikel staat dat het een tot dusver onbekende bug was terwijl er in de quote van het oorspronkelijke artikel staat dat 't al bekend was?
edit:
Ja nu is het flamebait, ik had niets anders verwacht, ga eens serieus op dit soort berichten in in plaats van blind zijn voor de overige informatie in dit geval. Dom kuddevolk

Mnou dat schrijft linux dus af voor mij :+

Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.
een gevoel voor ironie heb je wel zo te zien. :)

gelukkig dat ieder OS op z'n tijd ergens last van heeft...
soms ook het hele Internet flood...
laten we met z'n alleen nu maar ICT afschrijven..
...daar is het volgens mij hoog nodig tijd voor ;)

Damn. we kunnen nu zowel op Windows als Linux meer bashen. sorry jongens..!

Het is een grote bug, maar geen kritieke bug. Het is een local root exploit. Een aanvaller moet zich dus langs andere weg eerst toegang tot het systeem verschaffen.

6 september is deze bug ontdekt en gerepareerd in de kernel. De exploit is waarschijnlijk daarna pas gemaakt. Dit is dus een nadeel van open source: niet alleen ontwikkelaars, maar ook potentiele hackers krijgen alle informatie over veranderingen, en de redenen daarvoor.

Echter, de patch was al wel beschikbaar. Mensen die doorhadden wat de implicaties waren van deze bug waren er alleen niet. Zowel bij RH (bv Alan Cox en David Miller) als "bij" Debian werken veel mensen die intensief bij de kernel ontwikkeling betrokken zijn. Als de implicaties van deze bug bekend waren geweest hadden deze mensen deze patch al wel in de productie kernel gestopt. Deze distributies gebruiken al geen standaard kernels, maar kernels met allerlei patches. 1 meer of minder maakt dus niets uit.

Wat deze "hacker" (of in ieder geval de programmeur van de exploit) dus beter heeft gedaan dan de lk-developers is inschatten wat de implicaties van de betreffende bug waren.

Dit betekent niet dat mijn vertrouwen in open source in het algemeen en linux in het bijzonder hierdoor geschaad is. Integendeel, er is weer meer bekend over de gevaren van het ontwikkelproces, en de problemen zijn op een goede manier opgelost. Ook is een gevaar geduid wat betreft de manier waarop blackhats te werk gaan.

Als een soortgelijke crack bij windows servers uitgevoerd zou worden, zou er geen community zijn om dit te detecteren. MS zou daar alleen voorstaan. Ze zouden lang niet de informatie en medewerking krijgen die ze nodig hadden om de crack op te sporen, met als gevolg dat deze heel lang kan blijven sluimeren. Ik zou er geen geld op zetten dat dit soort expoits er niet zijn voor windows servers.

edit: typo

Het is een grote bug, maar geen kritieke bug. Het is een local root exploit. Een aanvaller moet zich dus langs andere weg eerst toegang tot het systeem verschaffen.

Waarom krijg ik dan net een mailtje van WideXS dat ze NU alle servers direct gaan upgraden. Normaal hebben ze nooit zo'n haast.
Als een soortgelijke crack bij windows servers uitgevoerd zou worden, zou er geen community zijn om dit te detecteren. MS zou daar alleen voorstaan. Ze zouden lang niet de informatie en medewerking krijgen die ze nodig hadden om de crack op te sporen, met als gevolg dat deze heel lang kan blijven sluimeren. Ik zou er geen geld op zetten dat dit soort expoits er niet zijn voor windows servers.
Ik had uit de berichtgeving nou niet echt de indruk dat er miljoenen 'open source' communicty programmeurs liepen te rennen om het probleem op te lossen. Het waren gewoon de maintainers die het mochten doen om een probleem op te lossen wat al maanden bleek te bestaan.

Waarom krijg ik dan net een mailtje van WideXS dat ze NU alle servers direct gaan upgraden. Normaal hebben ze nooit zo'n haast.

1 mailtje, ik krijg er 4. (iets te veel handles aangemaakt, denk ik)

Maar even on topic:

De meeste Linux servers hebben een heel beperkt aantal gebruikers, meestal alleen de beheerders. Dat geldt echter niet voor de Linux servers bij hosting providers. DIe worden dus ineens heel erg zenuwachtig, want een local root exploit betekent voor hen dat al hun klanten m.b.v. een simpel programmaatje root rechten kunnen krijgen.

Dat soort 'echte' multi-user machines maakt maar een heel klein deel uit van alle in gebruik zijnde Linux bakken. Ter illustratie, ik beheer een dozijn Linux machines, maar ik wordt niet erg zenuwachtig van deze hack. Maar als je WideXS bent wordt je dat *wel*.

Goeie les...

Ja goed, maar had ze die fix dan gewoon 9 weken eerder laten toepassen ipv op het laatste moment...

Ja goed, maar had ze die fix dan gewoon 9 weken eerder laten toepassen ipv op het laatste moment...
als widexs het 9 weken eerder hadden geweten had het dat vast wel gedaan

Ze gaan de boel NU updaten, omdat het een LOCAL root exploit is waarmee IEDEREEN root kan krijgen.

Ik kan me best wel voorstellen dat ze GEEN zin hebben in een HELE lijst van gecompromitteerde SHELL bakken.

Want dat is WideXS toch nog steeds? Vette shell provider :P

DAAROM gaan ze nu zo snel updaten. Wat denk jij dan?
een multi user omgeving met een local root exploit IN de kernel?! Was het nou een suid binary, dan disable je ff die binary tot er een upgrade is.

Nu het bekend is geworden en wat de gevolgen kunnen zijn, is het van "onbeduidende bug patch" verworden tot "critical systems security patch"...

Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.
Het was destijds niet bekend dat de bug exploitable was. Het was dus gewoon een bugje, net als heel veel anderen, en werd dus op dezelfde manier opgelost als heel veel anderen. Als ze toen hadden geweten dat hij exploitable was, dan was er veel sneller wat aan gedaan.
Ja nu is het flamebait, ik had niets anders verwacht, ga eens serieus op dit soort berichten in in plaats van blind zijn voor de overige informatie in dit geval. Dom kuddevolk
Ik gok dat dat komt door je "Mnou dat schrijft linux dus af voor mij" opmerking. Ook "dom kuddevolk" helpt niet echt als je serieus genomen wilt worden of hoog gemodereerd wil worden.

De oorzaak bleek te liggen in een tot dusver onbekende bug
De bug was al 9 weken geleden gevonden, maar helaas net te laat om nog in 2.4.22 te worden meegenomen.

En SPee, de hacker heeft dus geen bug aangebracht, hij heeft hem alleen uitgebuit om root-rechten te krijgen.

Aha, dat was een andere hack :7

Mja, 9 weken vind ik vrij lang moet ik zeggen... Als MS 9 weken wacht met een patch 'want het kon niet meer mee met de maandelijkse patches' krijgen ze ook de wind van voren, en terecht. Men had direct de 23 kernel moeten uitbrengen.

Als MS 9 weken wacht met een patch 'want het kon niet meer mee met de maandelijkse patches' krijgen ze ook de wind van voren, en terecht.
microsoft wacht meestal nog langer met een patch. Een vergelijkbare bug als deze wordt door MS gewoon als feature gezien en nooit opgelost. In IE (onderdeel helaas van windows) zitten ook nog vele gaten die MS dus gewoon niet dichttimmert.

Dat is ook een van de redenen dat microsoft zo'n slechte naam heeft op het gebied van beveiliging. Linux en zeker Debian hebben een zeer goede naam.

Dat is een poepverhaal en dat weet je zelf ook wel. De leaks in IE daargelaten, elke kernel exploit wordt a.s.a.p. gefixed, die blijft echt geen 9 weken op de plank liggen.

tssss, zoveel ongelovige Thomassen op t.net
see for yourself:

http://security.tombom.co.uk/shatter.html

echt wel leuk om te proberen, werkt hier op men Windows 2000 en moeilijk is het niet :)

Hey, leuke link -- ben doorgegaan naar het emailtje en kwam het verhaal van MS tegen:
http://www.microsoft.com/technet/columns/security/essays/10imlaws.asp
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.

That's why it's important to never run, or even download, a program from an untrusted source ? and by "source", I mean the person who wrote it, not the person who gave it to you.
Hmmm, als ik ooit duidelijker van MS te horen heb gekregen dat je het beste maar linux gebruikt, dan kan ik me dat niet herinneren...
:P

Mja, 9 weken vind ik vrij lang moet ik zeggen... Als MS 9 weken wacht met een patch 'want het kon niet meer mee met de maandelijkse patches' krijgen ze ook de wind van voren, en terecht. Men had direct de 23 kernel moeten uitbrengen.
Het probleem is dat ten tijde van het ontdekken van die bug hij niet exploitable werd geacht. Hij werd dus gefixt in de pre-release versies, zodat hij er bij de volgende versie bij zou zitten (bron). Als ze toen al geweten hadden dat de bug exploitable was, dan was er al veel sneller wat gereleased.

Wat ik wel gaaf vind om te zien, is dat er zo lekker wordt samengewerkt tussen verschillende Distro's. Debian, een niet-commerciele Distro, wordt geholpen als er een hack plaatstvindt door beveiligingsexperts van Redhat en Suse. Het is natuurlijk allemaal Linux, maar het is toch erg gaaf om te zien dat eigenlijke concurrenten van elkaar, elkaar wel helpen, in plaats van keihard met elkaar te concurreren. Dat is in andere segmenten van de OS-markt toch wel een beetje anders ;).

In dit geval zijn het dus -geen- concurrenten. Een fout in de kernel is gevaarlijk voor -alle- linux distributies. Dus ook voor de commercielen.

Overigens geld deze bug ook voor de 2.0 kerneltree? (ik heb nog een Freesco routertje draaien vandaar ;) )

Waarschijnlijk niet. Er is al bekend gemaakt dat 2.2 niet kwetsbaar is en lijkt me dat die code er dan nog niet inzat en daarmee ook niet in 2.0.

Oefje :)

Want ik denk niet dat ik mijn kerneltje nog een update voor zal krijgen. D8 dat 2.0.39 de laatste release in die tree was...

Overigens geld deze bug ook voor de 2.0 kerneltree? (ik heb nog een Freesco routertje draaien vandaar
LEZEN! Het is geen remote security hole.

Tenzij je Jan en alleman toegang verleent tot je servertje is er dus niets aan de hand.

LEZEN! Het is geen remote security hole.

Tenzij je Jan en alleman toegang verleent tot je servertje is er dus niets aan de hand.
Hoewel je gelijk hebt is dat natuurlijk wel een vrij gevaarlijke houding. Ja, het is een local exploit, maar als iemand nu toegang krijgt tot jouw systeem (exploit in bv. apache, of een gesnifft password, of een terminal die je open laat staan, of die persoon die je eigenlijk toch wel met een account vertrouwde, etc), dan kan hij ook root worden.

Een local root hole is lang niet zo ernstig als een remote root hole, maar dat betekent niet dat je er niks aan hoeft te doen.

wat ik wel gaaf vind, is te constateren dat Linux ook over features beschikt... ;)

jammer dat ze er niet bij melden hoe de "hacker" toegang moet krijgen om deze fout te omzeilen

En bovendien was de bug alleen te exploiten met een geldig account op de machine.

vraag me af wat ik op een windows machine kan exploiten als ik een geldig account heb.. en dan denk ik dat ik niet eens bugs nodig heb, maar dat er genoeg "features" zijn om je gang te kunnen gaan.

Moraal, laat geen passwords slingeren.

Als je een admin wachtwoord steelt dan ben je binnen. Als je een wachtwoord steelt met restricties dan zal je flink moeten werken om 'root-access' op je eigen machine te krijgen, laat staan op een server.

Waarom ben je binnen met een Admin wachtwoord? Op al mijn servers is bijvoorveeld een remote Admin login verboden.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 10:24 Toekomstige PlayStations gaan emoties gebruiker lezen
Vorige 10:05 Shuttle SB75G2 en Soldam Altium RS4 review
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011