image

Ontwerpfout veroorzaakt nieuw Windows-lek

donderdag 25 november 2010, 07:37 door Redactie, 12 reacties

Op een Chinees forum is een nieuw beveiligingslek in alle Windows-versies ontdekt, waardoor een aanvaller zijn rechten op het systeem kan verhogen. Daardoor is het zelfs met een account met verminderde rechten mogelijk om willekeurige code in kernelmode uit te voeren. Het probleem bevindt zich in het Win32k.sys bestand en is in Windows XP, Vista en Windows 7 aanwezig, bij zowel de 32- als 64-bit versies. "Aangezien het een privilege escalation exploit is, omzeilt het ook de bescherming die User Account Control en Limited User Account geven," zegt Marco Giuliani van Prevx.

Microsoft laat in een reactie weten dat het een publieke proof-of-concept voor een lokaal 'escalation of privilege' lek onderzoekt. Volgens de softwaregigant moet een aanvaller wel over een account op het aan te vallen systeem beschikken om de exploit uit te kunnen voeren. De exploit in kwestie is inmiddels ook op Exploit-DB verschenen. De auteur laat daarin weten dat een ontwerpfout in de Windowskernel API het probleem veroorzaakt.

Stuxnet
Het is de tweede Windows zero-day kwetsbaarheid die in een week openbaar wordt. Maandag verscheen er aanvalscode voor het laatste overgebleven Stuxnet-lek. Dit was één van de vijf exploits die de worm gebruikte om systemen te infiltreren. De kwetsbaarheid, waar Microsoft al sinds september van weet, was al genomineerd om gepatcht te worden, alleen is het nog altijd onbekend wanneer dit is.

Reacties (12)
25-11-2010, 07:43 door sjonniev
McAfee schakelt hem wel uit, die win32k.sys (grapje).
25-11-2010, 08:19 door spatieman
oei !!
snel dat win32k.sys blacklisten !!
25-11-2010, 09:22 door Anoniem
Weer een dag begonnen met lachen om Windows, bedankt Microsoft!
25-11-2010, 10:22 door Anoniem
je kan je afvragen of MS niet al veel langer op de hoogte was van dit soort gapende gaten...
en erger nog, waarschijnlijk zijn er 1000den van dit soort gaten in de windows code waarvan MS al lang weet heeft.

maar aangezien hun code closed source is, zijn deze gaten enkel te vinden door trial and error... en dat is waarom windows/MS nog niet omgevallen is.

windows zal altijd brak blijven ook al beloven ze met iedere nieuwe versie dat het nu wel eindelijk allemaal secure is.

hier zijn twee redenen voor:
1) closed source model
microsoft heeft, pak em beet 'maar' 5000 programmeurs die dagelijks betrokken zijn met de ontwikkeling van de closed code base.
bij bv linux zijn er potentieel miljoenen programmeurs die op ieder willekeurig moment open source code bases kunnen controleren op fouten.

aangezien de windows codebase enorm is kan je je wel voorstellen dat al snel allerlei programmeer fouten over het hoofd worden gezien.

maar er is nog een probleem en dat is:
2) commerciële doelstellingen en deadlines

iedereen die wel eens aan een project heeft mee gewerkt waar harde deadlines zijn gesteld weet dat om die deadlines te halen er compromissen moeten worden gesloten.

MS moet om de zoveel tijd met een nieuwe windows versie uitkomen om de winsten op te krikken en de aandeelhouders tevreden te houden.
het kan gewoon niet anders zijn dan dat men hierdoor een boel onvolkomenheden in de code laat zitten omdat het teveel tijd kost om alles glad te strijken. en dit kan in principe om dat de source toch closed is.

immers, niemand kan van buiten af in de code kijken en constateren dat hele delen van de code snel in elkaar gezette spaghetti is die uiteindelijk pas wordt verbeterd met de grote service pack upgrades.
tot die tijd zullen mensen na veel uitproberen of zelfs per toeval uiteindelijk op deze lekken stuiten.

als microsoft dan zo'n lek direct zou patchen is het probleem nog te overzien maar in de praktijk blijkt dat patches erg lang op zich laten wachten en men denkt dan al snel dat MS laks is of nonchalant.

maar het is geen onwil van MS.. het is te danken hun business model.
meestal is het oplossen van die lekken niet even 3 regels code aanpassen omdat dat weer gevolgen heeft voor andere delen van de code zou hebben.
de oplossing is het herschrijven van hele stukken slecht/snel design van de code, en dat kost tijd en gaat ten kosten van ander ontwikkel werk dus zal er meestal een soort van tussen oplossingen worden bedacht die de algehele kwaliteit van de rest van de code ook niet ten goede komt.

pas 4 service packs later is de code eindelijk een beetje op orde maar tegen die tijd roept de commerciële kant alweer om een geheel nieuwe versie.

en dan krijg je het rare scenario zoals met winXP dat men de support staakt en mensen wil dwingen om van het eindelijk goed werkende XP af te stappen op het brakke nieuwe windows 7...

en dan te bedenken dat er banken, ziekenhuizen en overheids instanties daadwerkelijk een OS als dit in huis durven te halen...
25-11-2010, 11:41 door fluffyb53
Sophos heeft een video met demo en registry-oplossing.

http://www.youtube.com/watch?v=LKCKKYjm1Nw

Als je paranoide bent kan met je met Process Explorer wel te weten komen welke SID je moet aanpassen.
25-11-2010, 11:55 door [Account Verwijderd]
[Verwijderd]
25-11-2010, 13:11 door Bitwiper
Door Peter V: Over deze 0-day maak ik mij wat minder zorgen. Gevaarlijker vind ik de STUXNET-0-day. Die moet zo snel mogelijk een patch krijgen.
Er waren meerdere Stuxnet -days, ik neem aan dat je de laatste bedoelt (https://secure.security.nl/artikel/35196/1/Hacker_onthult_Stuxnet-lek_in_Windows_7.html). Ook daarbij gaat het om een privilege escalation vulnerability, en ook de gepubliceerde exploit daarvoor werkt niet onder XP (privilege escalation exploits zijn natuurlijk flauwekul als gebruikers reeds admin rechten hebben, d.w.z. lid zijn van de groep Administrators).

Reken je echter niet rijk, want de onderliggende kwetsbaarheden zijn zeer waarschijnlijk ook in XP aanwezig.

Overigens kun je, in elk geval onder XP, een eventuele Task Scheduler privilege escalation vulnerability voorkomen door de task scheduler service niet te draaien, maar sommige legitieme applicaties werken dan wellicht niet goed meer (bijv. McAfee maakt er gebruik van).

Een alternatief dat bedrijven zouden kunnen toepassen is het zodanig wijzigen van de permissies op C:\Windows\Tasks\ dat "authenticated users" (geverifieerde gebruikers) geen rechten meer hebben om bestanden aan te maken in die map, en alle bestaande .job files van non-admin gebruikers te verwijderen. Die permissies zijn het beste te zien met explorer (verkenner) maar standaard gaat dat niet bij C:\Windows\Tasks omdat een onzichtbaar bestand "desktop.ini" in die map dat verhindert.

Dus, start een command prompt, ga naar de map C:\Windows\Tasks en voer uit:
attrib -r -h desktop.ini
ren desktop.ini desktop.inx
Nu kun je met verkenner in de eigenschappen van die map, onder beveiliging -> geavanceerd, de gegevens van geavanceerde gebruikers openen, en het vinkje voor "Bestanden maken/Gegevens schrijven" verwijderen. Daarna voer je uit je:
ren desktop.inx desktop.ini
attrib +r +h desktop.ini
Vergeet niet bestaande .job files waarin gewone gebruikers schrijfrechten hebben te verwijderen (evt. kun je verwijderde jobs onder een admin account her-schedulen).

Of genoemde aanpak voor de Task Scheduler privilege escalation vulnerability ook geschikt is voor W7 en W2k8 weet ik niet (heb ik niet onderzocht).
25-11-2010, 13:34 door eMilt
Door Anoniem: maar aangezien hun code closed source is, zijn deze gaten enkel te vinden door trial and error...
Klopt. En omdat er zo veel geprobeerd wordt, wordt er ook geregeld wat gevonden. Dat er in andere OS'en niks of weinig gevonden wordt komt meer omdat er weinig wordt geprobeerd dan dat die bugs er niet zouden zijn.

bij bv linux zijn er potentieel miljoenen programmeurs die op ieder willekeurig moment open source code bases kunnen controleren op fouten.
De praktijk heeft al geleerd dat dit dus niet gebeurd.

aangezien de windows codebase enorm is kan je je wel voorstellen dat al snel allerlei programmeer fouten over het hoofd worden gezien.
Ja, zoals bij iedere grote codebase.

iedereen die wel eens aan een project heeft mee gewerkt waar harde deadlines zijn gesteld weet dat om die deadlines te halen er compromissen moeten worden gesloten.
Klopt. Als Microsoft een nieuwe versie van WIndows of Office of wat dan ook uitbrengt dan zijn niet all gerapporteerde bugs in de bugtracker gefixed. Is ook onmogelijk want anders zou je namelijk nooit aan een release toe komen. Dit geldt niet alleen voor Microsoft maar voor nagenoeg ieder softwareproject van enige omvang. Zodra een softwarepakket in de release candidates fase komt dan worden alleen nog de grote show-stopper bugs gefixed. Dus bugs die zo'n impact hebben dat het product zonder een fix niet normaal kan werken. Zelfs security fixes worden soms niet meer doorgevoerd en worden uitgesteld tot na de release. Zo gaat het nou eenmaal met alle grote softwareprojecten.

MS moet om de zoveel tijd met een nieuwe windows versie uitkomen om de winsten op te krikken en de aandeelhouders tevreden te houden.
Microsoft heeft wel het tegendeel bewezen met hoe lang er tussen de releases van XP en Vista zat. Alhoewel de release van een nieuw OS best wel voor een piekje in de verkopen zal zorgen haalt Microsoft denk ik de meeste verkoop en winst uit de OEM verkopen. En die zijn nauwelijks afhankelijk van de release van een nieuw OS. Per jaar worden er grofweg 360 miljoen PC's verkocht met Windows OEM licenties erop. Of er nou net een nieuwe versie uit is of niet verandert daar niet zo veel aan.

immers, niemand kan van buiten af in de code kijken en constateren dat hele delen van de code snel in elkaar gezette spaghetti is die uiteindelijk pas wordt verbeterd met de grote service pack upgrades.
Service packs zijn een rollup van alle bugfixes en security fixes sinds de release met soms enkele nieuwe features. De grootte van die service packs valt best wel mee. Zeker als je het vergelijkt met wat Apple zo'n 5/6 keer per jaar aan bugfixes uitbrengt (de laatste naar 10.6.5 was 680 MB en dan zat daar nog niet eens de nieuwe iTunes en Safari in).

als microsoft dan zo'n lek direct zou patchen is het probleem nog te overzien maar in de praktijk blijkt dat patches erg lang op zich laten wachten en men denkt dan al snel dat MS laks is of nonchalant.
De fix is er meestal al wel heel erg snel maar Microsoft laat die uitgebreid testen op een grote verscheidenheid aan hardware en software. Als het niet strict noodzakelijk is om de patch snel uit te brengen dan wacht men ook nog bewust tot patch-tuesday om zo alle patches te kunnen bundelen tot een update actie.
25-11-2010, 13:55 door SirDice
Door eMilt:
Door Anoniem:bij bv linux zijn er potentieel miljoenen programmeurs die op ieder willekeurig moment open source code bases kunnen controleren op fouten.
De praktijk heeft al geleerd dat dit dus niet gebeurd.
Vergeet ook niet dat potentiele programmeurs geen programmeurs zijn. Ik ben namelijk ook een potentiele winnaar van de lotto jackpot.

Door Anoniem:immers, niemand kan van buiten af in de code kijken en constateren dat hele delen van de code snel in elkaar gezette spaghetti is die uiteindelijk pas wordt verbeterd met de grote service pack upgrades.
tot die tijd zullen mensen na veel uitproberen of zelfs per toeval uiteindelijk op deze lekken stuiten.
Dat kan dus wel. Als je een grote zak geld op tafel zet en je even een NDA tekent kun je zo toegang krijgen tot de sourcecode. Geweldig ook dat je er vanuit gaat dat de code een rommeltje zou zijn zonder dat je zelf ooit die code gezien hebt.
25-11-2010, 14:06 door Mysterio
Heel scherp SirDice. Ik heb 'de code' wel eens mogen aanschouwen, maar omdat ik geen programmeur ben (of daar enige ambities toe heb) was het als Chinees voor mij. Maar ik begreep van de collega die er mee bezig was dat het er prima uit zag.

Het nare van het Open Source verhaal is dat we uitgaan van het goede van de mens. De miljoenen ogen zijn vast niet allen goedwillende engeltjes die ons het allerbeste op computergebied wensen. Ontwerpfouten blijf je houden en deze vind ik niet heel spannend aangezien je er een account voor nodig hebt.
25-11-2010, 16:50 door Anoniem
Ik ben een gelukkige Linux user :-)

Wat een gedoe met dat Windows, dat jullie voor zoiets geld betalen.
25-11-2010, 17:07 door Skizmo
Door Mysterio: Het nare van het Open Source verhaal is dat we uitgaan van het goede van de mens. De miljoenen ogen zijn vast niet allen goedwillende engeltjes die ons het allerbeste op computergebied wensen. Ontwerpfouten blijf je houden en deze vind ik niet heel spannend aangezien je er een account voor nodig hebt.
Dat is nou juist niet het nare. De clue van het feit dat alles open is, is dat er juist rekening gehouden wordt met niet zulke goede mensen. Des te harder de programmeurs hun best moeten doen, en doen ze dat niet, vallen ze meteen door de mand. Dit garandeert uiteindelijk dus een hogere standaard van kwaliteit omdat je je als progammeur nergens achter kunt verschuilen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.