Gepubliceerd: Maandag 20 juli 2009
Een ontwikkelaar heeft een exploit voor een bug in de Linux-kernel gepubliceerd die uitgebuit kan worden zelfs als de beveiliging staat ingesteld op het hoogste niveau.
Toon volledig artikel
De exploit is misschien op zichzelf niet remote exploiteerbaar maar er zijn al andere mogelijkheden om bijvoorbeeld gelimiteerde toegang te krijgen tot bijvoorbeeld webservers via fouten in configuratie webservers, fouten in websites of exploits in websites software (CMS'sen en forums bijvoorbeeld).
Deze kunnen vaak slechts tot defacing van de website leiden omdat daarmee slechts beperkte toegang tot de server wordt verkregen maar kunnen nu met deze exploit erbij mogelijk gebruikt worden om controle tot de server te krijgen.
zijn al andere mogelijkheden om bijvoorbeeld gelimiteerde toegang te krijgen tot bijvoorbeeld webservers...
Inderdaad. Maar wat dit met deze fout te maken heeft weet ik niet.
Als dit hiermee mogelijk was zou deze ontwikkelaar dat ongetwijfeld wel als mogelijkheid hebben genoemd. Maar het is natuurlijk wel leuk om over mogelijke exploits te fantaseren bij een OS als Linux dat een zeer goede naam heeft op het gebied van veiligheid :-)
Dat een exploit niet op afstand te misbruiken is, betekent niet dat er geen misbruik van gemaakt kan worden.
Dat mijn auto binnen een garage staat en niet iedereen er zo maar bij kan, betekent niet dat die niet gestolen kan worden. Het is niet een super vergelijking, maar kijk maar hoe ver je er mee komt.
Als de discussie er toe leidt dat er een inzicht is dat elk OS zijn zwakheden heeft en dat iedereen ten alle tijde alert moet zijn dan is dat winst.
Als we hier blijven hangen in ontkenningen of bagatelliseer acties, dan komt de afrekening vanzelf ergens.
De genoemde opmerking is een opvallende
Bojan Zdrnja van het Internet Storm Center is gefascineerd door het lek, omdat een audit van de broncode het nooit had blootgelegd. "Het is mogelijk, maar ik verzeker je dat bijna iedereen het zou missen." De kwetsbaarheid zit in verschillende onderdelen van Linux, waaronder die de net/tun functies implementeert. De code controleert of de tun variabele niet naar NULL wijst, maar de compiler verwijdert deze regels tijdens de optimalisatie routine. Als de variabele naar nul wijst, probeert de kernel toegang tot afgeschermd geheugen te krijgen, waardoor een aanvaller het systeem kan overnemen.
Ook het open source karakter is dus niet per definitie een garantie tegen het voorkomen van lekken.
Snel patchen dus en gewoon erkennen voor wat het is: een potentieel gevaar!
Snel patchen dus ...
Bij deze dan. ;)
Tegen dat deze kernel in productiesystemen gebruikt wordt zal het wel dicht getimmerd zijn gok ik.
Ik ben het wel met Bojan Zdrnja eens, deze valt echt niet op.
Verder zijn het gelukkig alleen wat misleide fans (en misschien Google) die claimen dat een os 100% veilig kan zijn zonder patches. Sterker nog, in oa. Linux hebben ze gekozen voor een package manager die in principe voor alle geïnstalleerde software patches uitrolt, waardoor ook minder in het oog springende software bij blijft.
Tegen dat deze kernel in productiesystemen gebruikt wordt zal het wel dicht getimmerd zijn gok ik.
Mis poes ben ik bang, kijk maar:
De kwetsbare code zit in de nieuwe kernels 2.6.30 en 2.6.30.1, die al worden gebruikt in Red Hat Enterprise Linux 5.
Dit artikel geeft wat achtergrond over setuid.
De positie van Linus Torvalds vind ik opmerkelijk:
Setuid staat bekend als een chronisch beveiligingsgat. Wat dit betreft heeft Torvalds gelijk.
Linux heeft niet veel design flaws, maar dit is er kennelijk eentje.
Mis poes ben ik bang, kijk maar:
Voor zover ik gelezen heb wordt deze kernel eigenlijk alleen nog maar op test servers gebruikt, nog niet in productie systemen. Dus ik ga ervan uit dat de meeste bedrijven nog wel even wachten met het uitrollen naar productie totdat deze fout is verholpen.
De kwetsbare code zit in de nieuwe kernels 2.6.30 en 2.6.30.1, die al worden gebruikt in Red Hat Enterprise Linux 5.
Dat Linux niet perfect is, dat is verder geen verrassing. Zolang het mensenwerk blijft zullen er fouten worden gemaakt.
Het stukje onder doofpot maakt het één en ander duidelijk. Dit klinkt als een vrij zuur mannetje. :)
Maar goed, hij heeft iets gevonden. Nu afwachten hoe heet de soep is tegen de tijd dat het wordt opgediend.
Ik verwacht dat die man gewoon te lang droog staat en dat hij aan het vissen is naar "15 minuten".
Als het klopt wat hij gevonden heeft dan heb ik niks gezegd maar tot die tijd blijf ik bij de bovenste regel.
Ik geloof wel dat hij iets gevonden heeft. Alleen heeft hij het gevonden in een kernel die eigenlijk nog nergens in productie is genomen. En je hebt een vrij specifieke configuratie nodig als ik het goed lees, dus de impact van deze vondst zal vrij beperkt blijven denk ik.
Maar wel goed dat hij dit onder de aandacht brengt. Misschien dat hier scripts voor te verzinnen zijn, om dit soort situaties te detecteren in de source.
Alleen heeft hij het gevonden in een kernel die eigenlijk nog nergens in productie is genomen
Hij heeft het zelf over de 2.16.18 kernel van RHEL 5.
Lijkt me juist een heel populaire kernel versie voor veel organisaties.
Ik lees op diverse plaatsen dat het bevestigd is voor de nieuwere Kernel. De 2.6.18 kernel is voorlopig dus alleen nog maar een claim van één 'expert'.
Grappig dosprompt, maar volgens mij bedoelde hij jou met "één 'expert'". Daarom staat het ook tussen aanhalingstekens ... ;)
Weer probeer je hier off topic een persoonlijke aanval op mij. Heb je niet ergens door dat dit gedrag wel uitermate irritant envervelend aan het worden is !!!
In reactie op dosprompt op Maandag 20 Juli 2009 14:57 :
Mag ik u aaraden om vanaf nu dagelijks 20..40 mg. Fevarine (of een vergelijkbaar middel) te gaan gebruiken ?
Dit middel vertraagt/onderdrukt de re-absorbsie van de neuro-transmitter serotonine in uw hersenen (om precies te zijn: in de praefrontale neocortex), waardoor u zich gegarandeerd veel prettiger zult gaan voelen. (En ook veel prettiger zult zijn in de omgang met anderen in het algemeen en hier op Webwereld in het bijzonder).
Ik lees dat bericht keer op keer, maar erg duidelijk wil het maar niet worden. Ik blijf het gevoel houden dat het geen doorsnee kernel 2.6.18 is.
Want als het daar in zit, wat betekent dan het onderstaande?
The commit that introduced the vulnerability (Feb 6th): Though it was committed before the release of the 2.6.29 kernel, it did not (thankfully) make it into the 2.6.29 kernel. It first appeared in 2.6.30.
Het verscheen voor het eerst in 2.6.30, maar toch zit het in 2.6.18? Ik heb daar wat moeite mee.
Of dit moet hem zijn:
The buggy commit was backported to a RHEL5 test kernel on April 15th
Hetgeen zou bevestigen dat het niet in gewone kernels is uitgerold, maar alleen in backported test kernels. Daar lijkt het ook op als je de link volgt want die gaat over kernel 2.6.18-153.el5.
Ik blijf er bij dat de kwetsbaarheid van de 2.6.18 kernel *ZWAAR* wordt overdreven.
1 lek vinden die niet vanaf buiten benaderbaar is, is wat anders dan een compleet lek OS wat bijna een open deur is (ik doel op windows dus).
Sorry, maar zo'n opmerking schaar ik onder de opmerkingen die kinderen op school uiten, zoiets in de trend van "Ik heb lekker een grotere!".
Een lek is een lek, dus, zoals al eerder aangegeven, dichten die handel. Of het nu in een MS, Linux of Mac OS is en wel zo spoedig mogelijk.
Lijkt mij simpel.
Zo kan je wel alles een lek noemen, dat vind ik nog veel meer kinderachtig.
Zodra er een bug in Linux of OSX gevonden word staat hier gewoon half webwereld te juichen "van zie je wel" ... dat noem jij volwassen dan?
Ik zie hier niemand "juichen" in dit topic, zelfs niet met haakjes om het woord juichen.
Ik zie alleen maar opmerkingen die de zaak bespreken en een paar die de zaak bagatelliseren. Niemand is blij met dit probleem voor zover ik kan zien.
Het stukje onder doofpot maakt het één en ander duidelijk. Dit klinkt als een vrij zuur mannetje. :)
Dat is wel vaker het geval bij een beperkt deel van security 'researchers' die vaak vinden dat hun bevindingen zo belangrijk zijn dat ze als eerste moeten worden opgelost. Vaak is de erkenning dan wel publiciteit voor deze personen erg belangrijk en als een software producent in hun ogen niet actief genoeg reageert volgt hun reactie in de vorm van publicatie van een exploit.
Niet een al te beste praktijk.
Dat ze hierbij potentieel schade doen aan duizenden of zelfs miljoenen mensen (bijvoorbeeld bij een gegevensdiefstal mvbv van hun exploit) kan ze blijkbaar minder schelen dan het gebrek aan erkenning voor henzelf.
Nou, niet helemaal met je eens, we hadden/hebben nog zoiets met TC/PIP, te erg om open te gooien en/of gesloten te houden.
Het bewijst alleen dat er zaken in software sluipen waar het risico niet direct goed ingeschat is of kon worden. Het geld voor alle software in alle soorten en maten. Je kunt dan misschien de manier van openbaring bekritiseren of goed vinden, als het maar opgelost wordt, het liefst vóór de schade, schande is het niet, software is mensenwerk.
En dan nog, er is geen OS 100 % veilig, de kwestie is eerder, als er een exploit word ontdekt, hoe ernstig is die en hoe snel word deze gefixt. Het nadeel van Open Source is gelijk het voordeel, iedereen kan de broncode inzien en daarmee exploits vinden, en dus kan ook iedereen deze exploits fixen.
Dat lukt je over het algemeen minder bij closed source oplossingen.
voor wat het vinden van fouten in de source is dit stuk van belang.
The code looks like this:
struct sock *sk = tun->sk; // initialize sk with tun->sk
…
if (!tun)
return POLLERR; // if tun is NULL return error
This code looks perfectly ok, right? Well, it is, until the compiler takes this into its hands. While optimizing the code, the compiler will see that the variable has already been assigned and will actually remove the if block (the check if tun is NULL) completely from the resulting compiled code. In other words, the compiler will introduce the vulnerability to the binary code, which didn't exist in the source code. This will cause the kernel to try to read/write data from 0x00000000, which the attacker can map to userland – and this finally pwns the box.
Kortom, de source was clean maar na het compileren gaat het fout. Open source is dus geen GARANTIE en dat wordt nogal eens beweert hier.,
En closed source is dat wel?
Exploit gevonden, community gaat aan het werk, de exploit wordt opgelost.
Simpel lijkt me. Bovendien is het aantal ontwikkelaars dat zich bezig houd met linux een beetje groter dan het aantal ontwikkelaars dat zich met closed source OS'en bezig houdt. Ook dat is de kracht van Open Source.
aantallen zegt niets over kennis. het aantal gebruikers dat zich met closed source bezighoud is vele malen groter dna het aantal gebruikers vna open source. Dat wil alleen zeggen dat fouten sneller gevonden worden ;)
Hij maakt een vergelijking tussen het aantal open-source (OS) ontwikkelaars en het aantal closed-source (CS) gebruikers.
Omdat er meer OS ontwikkelaars zijn, wordt een fout sneller gefixt.
Omdat er meer CS gebruikers zijn, wordt een fout sneller gevonden.
Conclusie:
Er worden minder fouten gevonden in OS, die snel worden opgelost.
Er worden meer fouten gevonden in CS, die langzaam/langzamer worden opgelost.
Ik probeer alleen nog te begrijpen wat "aantallen zegt niets over kennis" betekent (een opmerking die het gezegde "2 weten meer dan 1" tegenspreekt)
de kwaliteit van de aantallen is niet bekend. Het feit dat er veel mensen werken aan OSS ( meer dan closed source volgens de schijver, maar zonder onderbouwing) zegt niets over hun kennisniveau. Ik kom hier veel zelfverklaarde Linux deskundigen tegen die bijv. basisprincipes van netwerken niet onder de knie hebben. Dus aantal zegt niets over niveau.
Nee ok, er zullen ongetwijfeld mensen zijn die er niets van bakken (ook het geval in de CS-wereld!), maar als je ervan uit gaat dat je niet eens met Linux aan de slag gaat, tenzij je in ieder geval meer weet van (het configureren van) computers dan de gemiddelde bobo, denk ik dat het redelijk is om aan te nemen dat als je je aan het programmeren waagt van de Kernel, dat je toch wel respectabele kennis in huis hebt. (sorry voor deze asociaal lange zin. hopelijk is het begrijpelijk :-) )
Bovendien is het aantal ontwikkelaars dat zich bezig houd met linux een beetje groter dan het aantal ontwikkelaars dat zich met closed source OS'en bezig houdt.
Dat zou me heel sterk verwonderen. Waar haal je die informatie vandaan ?
Mav.
Ja, maar is het begrip Linux niet een beetje vele malen groter dan alleen een CS-OS waar er op gedoeld wordt?
Kernel/OS linux is waarschijnlijk wel een klein deeltje ICT.
Het maakt, zoals hier, de kans groter dat het gevonden wordt doordat er (toevallig) meer en buitenstaande ogen kunnen kijken. Bij CS kijkt er waarschijnlijk niet veel meer naar, klaar is klaar en zal een toevallige ontdekking ook toeval zijn.
Je hoeft niet altijd begaafd te zijn om over een onvolkomenheid te struikelen, soms heeft een groentje nét even scherpere ogen.
Dit zou een enorm probleem kunnen zijn als de comiler inderdaad overal nul checks wegsloopt zou ik bijna zeggen.
Je kunt dus als programeur dan niet checken of je nul terug krijgt?
Voor zover ik het probleem en de fix snap (maar mijn C is erg roestig) bestaat de fix uit het verplaatsen van een aantal statements binnen dezelfde routine. Dat lost dus het hele probleem met de dereferenced NULL-pointer op. Er staat me ook idd nog iets van bij dat C naer is op die manier... dus eigenlijk wel iets wat had moeten opvallen voor een ervaren C-programmeur. Maar, hij is idd subtiel, en ook ervaren C-programmeurs kunnen en zullen natuurlijk wel eens fouten maken.
Het stukje onder doofpot maakt het één en ander duidelijk. Dit klinkt als een vrij zuur mannetje. :)
Dat vond ik ook al, in zijn 5 seconds of fame wordt hij min of meer tegengesproken.
Maar goed, hij heeft iets gevonden. Nu afwachten hoe heet de soep is tegen de tijd dat het wordt opgediend.
Zo te zien wordt die soep nogal lauw opgediend, want een oplossing wordt inmiddels in het artikel aangeboden.
Jammer voor de M$ shills, die er weer een drama van proberen te maken. Volgende keer beter :-D
Ik zie in dit topic vooral goede open bijdragen. Jij bent de eerste die weer mensen gaat beledigen. Heb je dat nu echt nodig voor je standpunt?
en nogmaals lees dit artikel van de ""uitvinders"' van het gat ( dus niet de door jou gewraakte brad)
bypassing-linux-null-pointer en dan graag serieus en inhoudelijke discussie.
Als je aantal topics in het verleden leest, begrijp je dat je geen haar beter bent dan degene waar je kritiek op uit...
ontopic.
Ik zie het probleem niet zo. Er is inmiddels een oplossing beschikbaar, en het probleem ontstaat slechts in 2 combinaties, waarbij et Pulseaudio verhaal wat mij betreft afvalt, zoiets zet je toch niet op een server?
Wat de rest betreft, Red Hat is een commerciee Linux leverancier die contracten heeft met partijen over patchen van security problemen, dus de geboden oplossing wordt binnenkort vast snel via de packagemanager uitgerold.
Een potentieel probleem lijkt me wel dat het een mede door de compiler optimizer geintroduceerd issue is en dat er dan dus nog veel meer van dergelijk issues mogelijk zouden kunnen zijn.
Een grondiger analyse incl de verklaring voor het pulseaudio verhaal is hier te vinden.
So what we need is a setuid binary that will give us control back without going through exec. We found such a setuid binary that is installed on many Desktop Linux machines by default: pulseaudio. pulseaudio will drop privileges and let you specify a library to load though its -L argument. Exactly what we needed!
Bron
De moeite van lezen waard!
en ja hoor, de eerste bagatelliseeractie is er al.. ruim binnen de voorspelde periode ;)
Bagatelliseer acties? ;)
EDIT2: As of July 13th 2009, the Linux kernel integrates our patch (2.6.31-rc3). Our patch also made it into -stable.
De oplossingen stromen binnen. Maar toch blijven bepaalde mensen proberen het probleem op te blazen.
Meneer Spenger heeft een lullig foutje gevonden dat niet erg opvalt in de source. Ik denk dat veel CSS bedrijven er goed aan doen om hun code daar ook eens op na te kijken. Dit lijkt me een leuk leermoment voor de hele industrie. :)
Dus eigenlijk zit er een bug in de compiler. Die optimaliseert iets weg wat niet mag verdwijnen. Wat vinden de makers van GCC hier eigenlijk van?
De compilermakers wijzen op de bug in de C code. Wanneer je via een illegale pointer refereert treed je buiten de C standaard en gaat je programma "ongedefinieerd gedrag" vertonen. Deze bug moet dus in de kernel gefikst worden. (Is al gebeurd.)
Bug in de compiler is een te zware term. Noem het een feature :-)
In een hosted environment is het waarschijnlijk wel juist om de test weg te optimaliseren (want dan was er toch al een SEGV opgetreden), maar in een freestanding installatie leidt die pointer dereference niet per se tot een SEGV. Of gcc te overijverig is is een kwestie van smaak.
Overigens kan je met "-fno-delete-null-pointer-checks" het verwijderen van de checks verhinderen.
En Linus heeft natuurlijk gelijk: setuid binaries zijn trojaanse paardenlokkers. Die pulseaudio zal waarschijnlijk ook niet op een productiemachine geinstalleerd zijn.
Interresant artikel webwereld, ga zo door!
Wel bef, want ik ben een veelvuldige pulseaudio gebruiker, SELinux gebruik ik niet ;-(
Is dus geen kernel probleem.(gelukkig)
...Pikant detail is dat de code alleen kwetsbaar is als extra beveiliging middels SELinux is ingeschakeld of als PulsAudio is geïnstalleerd.
Dan is het probleem toch SELinux danwel Pulseaudio gerelateerd of niet?
Slimmerik weet je wel dat windows ook in C is geschreven? weet je wel dat daar een null pointer misleiden kinderspel is?
Weet je wel hoe eenvoudig is Windows helemaal voor de gek te houden met een programmeertaal ? wel eens van windows messages gehoord? WM_DOUBLECLICK , WM_KEY noem maar op.
Weet je hoe kindvriendelijk eenvoudig het is om windows al zijn acties af te tappen?
Want al die messages worden zeker niet geencryped onder windows.
Ben je klaar? Wa theeft dat met het probleem onder Linux te maken?
Wil je de zaak weer afleiden van het originele onderwerp?
Voeg nu eens een keer iets toe aan de discussie ipv katten op Windows of andere zaken die je niet beheerst.
Tenzij je kernel 6.2.30 of hoger draait, of RedHat backported kernel 2.6.18-153.el5, heb je sowieso niet zo'n groot probleem voor wat betreft deze bevinding. Het is een fout in de kernel die met SELinux danwel Pulseaudio uitgebuit kan worden. Ze zijn dus niet gerelateerd volgens mij, maar in dit geval alleen de boodschappers.
gewoon een another brak OS :)
Is dat zo, hoeveel jaren heb jij ervaring met M$ Windows en GNU/Linux?
Ik heb ervaring met Microsoft Windows sinds versie 3.1 t/m Windows 7 RC1. Gebruik GNU/Linux sinds SuSE Linux 6.1 (oktober 1999). Ik wacht met smacht op je onderbouwing, waarin je het onweerlegbare bewijs levert dat Linux net zo brak als Microsoft Windows is ;-)
Heb op de lagere school (<- toen heette het nog geen basisschool) nog met de abacus leren rekenen (maar heb het ponskaarten-tijdperk gelukkig niet meer meegemaakt... behalve in 't ziekenhuis, maar daar kwam ik toen als...ehm... klant)
Die kan het niet onderbouwen.
Het blijft een wijsneus.
Al sinds Linux prompt was het beter dan msdos.
Zelfs tijdens mijn opleiding beweerde men dat, op mijn stages werkte men al trots linux van wegen zijn kracht en stabiliteit. Ik ben altijd blij geweest ze mij beide kampen hebben laten zien.
lijkt een beetje op een google translate ;)
Since Linux was better than prompt msdos. Even during my training claimed that, on my work placement at all proud linux weighing its strength and stability. I am always glad she had me both sides have shown.
die laatste doet wat vermoeden ;)
I am always glad she had me both sides have shown.
Dat zuig je vast uit je duim ... denk je nu echt ik voor dat soort onzin tijd heb om beetje copy/paste/translate te doen?
Jij ziet echt overal spoken volgens mij
Er stond een smiley bij, dus dan maakt SED een grapje en mag je er verder niet op ingaan. Heb ik me laten vertellen.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
