Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Student ontwikkelt virtuele machine tegen geheugen-exploits

Een student aan de Vrije Universiteit in Amsterdam heeft een virtual machine gebouwd die geheugen-exploits tegengaat. Buffer overflows en return oriented programming worden onschadelijk gemaakt, maar software draait wel langzamer.

Erik Bosman, die de tool ontwikkelde voor zijn masterscriptie, presenteerde de werking van de virtual machine op hackers-event eth0. De software, die door Bosman Minemu is gedoopt, is onder een opensource-Apache-licentie vrijgegeven.

De virtual machine is bedoeld voor taint checking, waarmee moet worden voorkomen dat gebruikers code kunnen injecteren in het geheugen. De voor Linux ontwikkelde tool doet dat door software in een virtuele machine te draaien en van elke byte in het geheugen de oorsprong bij te houden. "Is een bepaald deel van het geheugen bijvoorbeeld user-input, dan mag het nooit als code worden uitgevoerd", zegt Bosman.

Ontdekt Minemu dat wordt geprobeerd om niet-vertrouwde code uit te voeren, dan wordt de uitvoering van de software gestaakt. Buffer overflows en return oriented programming, twee manieren om via het geheugen malafide code uit te voeren, worden daarmee feitelijk onschadelijk gemaakt. De meta-informatie over de afkomst van de code wordt bewaard in de snelle sse-registers van Intel-cpu's, dat eigenlijk voor het verwerken van multimedia is bedoeld.

Veel malware maakt gebruik van geheugen-exploits om code uit te voeren. Bij een buffer overflow kan de maximale grootte van een buffer worden overschreden en kan daardoor eigen code worden uitgevoerd. In reactie daarop voerden besturingssystemen ondersteuning voor address space layout randomization toe, waardoor de locatie van buffers in het geheugen werd gerandomiseerd, en data execution prevention, waarbij uitvoerbaar geheugen en gewone variabelen worden gescheiden.

Om aslr en dep te omzeilen, wendden aanvallers zich tot return oriented programming. Daarbij worden de bestaande machine-instructies van een bepaald programma in een specifieke, door de aanvaller gekozen volgorde uitgevoerd, waardoor hij zijn eigen code kan samenstellen. "Bij middelgrote software is dat vaak mogelijk", vertelt Bosman. "Dit project is eigenlijk de reactie op return oriented programming."

Op dit moment werkt Minemu enkel op 32bit-x86-cpu's. "Ondersteuning voor 64bit is een stuk moeilijker om in te bouwen", zegt hij tegen Tweakers.net, "bijvoorbeeld omdat de geheugenregisters veel groter zijn." Hij heeft wel onlangs ondersteuning voor software met meerdere threads ingebouwd, waardoor veel programma's goed werken met de tool. Alleen software met jit-compilers die content van internet als code uitvoeren, zoals de javascript-engine van Firefox, leveren nog problemen op. Die engines willen van buitenaf aangevoerde code juist uitvoeren.

Binnen de virtual machine draait code significant langzamer. Over het algemeen kan het drie tot vier keer langer duren voordat code is uitgevoerd. Dat komt doordat de code niet rechtstreeks wordt uitgevoerd, maar eerst de taint analysis van Minemu passeert. Volgens Bosman werkt de tool echter sneller dan vergelijkbare software, zoals Argos en TEMU.

Dat komt doordat de software anders werkt: waar Argos en TEMU de uit te voeren code van complete besturingssystemen checken, doet Minemu dat met een specifiek proces. Minemu reserveert voor elke byte in het geheugen een byte voor de analyse. Daardoor is twee keer zoveel geheugen nodig, nog los van de ruimte die Minemu zelf inneemt.

De werking van de virtuele machine kan nog wel worden omzeild, geeft Bosman toe, door een aantal specifieke bewerkingen op het geheugen los te laten. Dat is echter moeilijk uit te voeren, claimt hij.

Een Windows-versie van de software lijkt niet waarschijnlijk: "Daarvoor zou je Windows op systeemniveau moeten aanpassen, dus Microsoft zou moeten meewerken om dat mogelijk te maken." Op Linux is root-toegang voldoende om een systeem geschikt te maken voor de software. Daarvoor moeten wat waarden worden aangepast, bijvoorbeeld om het reserveren van een grote hoeveelheid virtueel geheugen mogelijk te maken. Enige aanpassingen zouden de tool geschikt kunnen maken om andere vormen van code-injectie, bijvoorbeeld sql-injecties, eveneens onschadelijk te maken.

Door Joost Schellevis

Redacteur

15-01-2012 • 11:11

76 Linkedin Google+

Reacties (76)

Wijzig sortering
"Algemeen is het wel opvallend dat universiteiten geen criteria stellen, het is gewoon zonde dat er voor veel verschillende opleidingen mensen kunnen afstuderen op niet zulke belangrijke zaken. Men moet eens de nut en noodzaak voor maatschappij voor ogen hebben en mensen alleen laten afstuderen op praktische oplossingen voor maatschappelijke problemen."

De masterscriptie hoort oorspronkelijk (en nog steeds) juist een onderzoek te zijn waarbij de student op basis van zijn opgedane recente kennis van enkele jaren, onder een set aan academische restricties waardoor je niet gelijk in een keer wereldvrede kan realiseren, met een grote hoeveelheid tijd zonder specifieke contractuele druk (zoals bijv. normaal in het bedrijfsleven) ten alle om een mooi academisch stuk op te zetten. Vaak is dit erg theoretisch, conceptueel, exploratief en verre van direct praktisch relevant. Men doet het om een hiaat in te vullen, vaak explorerend/ontdekkend wat mogelijk is. Dat de student hier zoals in dit geval dan ook nog in slaagt (iets behoorlijk duidelijks en concreet op tafel legt), is erg mooi.

Dat je met je master thesis (uiteindelijk ook gewoon maar een onderwijs vak) op tweakers.net komt en daarbij eigenlijk nog een enorm goede basis legt voor de praktijk, en dus eigenlijk een enorme praktische relevant stuk hebt is daarbij een bijzondere prestatie.

En dat er dan comments worden geplaatst waarin mensen klagen over de praktische relevantie (terwijl die dus zeer aanwezig is), of dat ze nu nog ‘niks kant en klaars’ hebben wat ze direct kunnen installeren en kunnen gebruiken om hun probleem mee op te lossen, en daarbij deze prestatie af te doen als ‘zonde van de tijd’, en daarbij klagen over het onderwijs (wat hebben jullie dan als eindvak opgeleverd? als je niet Larry Page, Sergey Brin of dergelijke heet, moet je misschien niet antwoorden), is echt ON-GE-LOFELIJK.
Heeft iemand link naar proefschrift?
Master's scriptie, groot verschil :)

Dit is hem zo te zien: http://www.google.com/url...5YbtjuQ_okxkCN6Jw&cad=rja
Volgens mij is een afstudeerscriptie toch vooral een "proeve van bekwaamheid". Natuurlijk is het leuk als er direct een maatschappelijk nut voor is, maar dat is niet het belangrijkste.

Bij je rijexamen eindig je meestal ook op het punt waar je begonnen bent. Niet heel erg nuttig voor de maatschappij, afgezien dan dat je hebt aangetoond (hopelijk) dat je het zelfstandig kunt.
Ik kan wel wat verzinnen hoor en onderhoud is er eentje bijvoorbeeld. Veel high-end systemen kunnen dat gewoon door bijvoorbeeld een fanblade/tray uit te schakelen voor onderhoud. Maar dit is eigenlijk iets wat met je ECC moet oplossen en servers zonder ECC zouden eigenlijk verboden moeten worden.

Ik durf eigenlijk te zeggen dat ECC ook verplicht moet worden voor alles. Data corruptie door foutief geheugen is best groot en het is een stille sloper van data. Wat ik bij verschillende serverparken heb gezien is het ongeveer een DIMM per duizend servers per jaar. Maar deze wordt alleen gedetecteerd door machines met ECC geheugen. En dat wordt gezegd dat Windows het detecteer is niet altijd waar, want het OS heeft gewoon geen kaas gegeten van wat er op de heap of stack staat qua data.

Door technieken zoals ZFS en BtrFS komt nu ook langzaam naar boven wat gevolgen zijn van data corruptie bij data opslag en de cijfers zijn vanuit de ZFS kant niet prettig. Helaas is blogs.sun.com overhoop gehaald, maar er stonden best interessante cijfers. Dit alles doet me denken aan bijvoorbeeld Borland Pascal met range checking van variabelen en helaas ontbreken zulke dingen nog steeds net zoals de optie om een applicatie te controleren of het dezelfde output blijft geven na een aanpassing van de broncode. GCC en Postgresql zijn een de weinige op dit vlak.

Ik kan dit soort onderzoek alleen maar aanmoedigen, want het toont weer aan hoeveel aannames er in de wereld worden genomen zonder bewijs of methoden het daadwerkelijk te meten. Hopelijk zal dit over de jaren leiden tot een nieuwe standaard van code ontwikkeling waarbij verificatie een belangrijke rol speelt.
helaas ontbreken zulke dingen nog steeds net zoals de optie om een applicatie te controleren of het dezelfde output blijft geven na een aanpassing van de broncode
Watte. Blijkbaar nog nooit van Unit tests gehoord? Dit zijn zaken die gewoon daar thuis horen. Er zijn "zelfs" systemen die na een update van de source gelijk maar het hele project gaan checken.
En als op de host machine nu het geheugen dusdanig verwarmd wordt zodat het fouten gaat maken, is zijn methode dan nog steeds toereikend?
Nee, maar waar haal je het idee vandaan dat ie dat probleem probeerde op te lossen? Als dit een commercieel product was dat in neon-koeienletters "100% beveiliging" garandeerde, dan zou je nog enigszins een punt hebben door het op zo'n feitelijk-ongerelateerd argument lek te willen schieten.
Maar dit is een master-thesis. Daar zit slechts een half manjaar werk in, dus dan moet je het probleem dat je op wilt lossen wel strak afbakenen, anders kom je helemaal nergens.
Je kunt immers wel zeggen dat je buffer overflows onschadelijk maakt, maar je kunt wel 'uit het geheugen springen' als het geheugen fouten gaat produceren. Dus softwarematig is het misschien veiliger, maar hardwarematig nog steeds één grote ramp.
Waar zou jij de grens willen trekken? Als je er niet vanuit wilt gaan dat je geheugen correct werkt, wil je er dan wel op vertrouwen dat je CPU correct functioneert? Want daar kunnen ook fouten (van FDIV tot TLB) inzitten. En harde schijven (virtueel geheugen, locatie van executables voordat ze worden geladen) zijn ook niet perfect. Trouwens, hoe weet je zeker dat je password niet gekraakt gaat worden? Zelfs als je de meest vreemde tekens erin zet ze hem heel lang maakt, het blijft een string bits; het is theoretisch mogelijk dat een aanvaller de eerste keer het password (hoe lang ook) correct raadt!

Oh, en als jij iemand op een zinloos puntje afschiet, mag ik jouw redenatie dan op een ontzettend practisch puntje afschieten? Geheugen dat te warm wordt maakt fouten op een compleet onvoorspelbare manier. Je zou het met een beetje fantasie nog een DoS-aanval kunnen noemen (als je echt remote memory errors kunt veroorzaken kun je een machine laten crashen), maar met random fouten een exploit voor elkaar krijgen... Vertel me alsjeblieft dat je dat zelf ook niet gelooft (de kans dat iemand je password van 100 tekens in één keer goed gokt is waarschijnlijk groter dan dat dat lukt!).
Waarom zo negatief? Het is een afstudeer scriptie! Ik zou eerder willen concluderen dat hij heeft bewezen een constructieve bijdrage te kunnen leveren aan de techniek/wetenschap en dat hij dus een mooi cijfer verdient en een goede baan of een promotie plek.
het is te omzeilen, al is dat moeilijk
Als je het niet doet dan hoeft een aanvaller niets te omzeilen. Zelfs als het niet waterdicht is, dan nog blijft het een extra barrière ("defence in depth" als je graag een hip naampje wilt).
het is geen proof of concept, zoals eerder al aangegeven, het idee bestaat al
Ehm, als het idee al bestaat, maar hij maakt er nu werkende code van, is het dan niet juist een proof-of-concept!?
Hiermee wil ik zeggen dat de doelgroep zo klein is dat het helaas nooit gebruikt gaat worden
In tegenstelling tot alle andere master-scripties die allemaal wel in de praktijk gebruikt gaan worden?? Het is juist bedoelt als onderzoek; als iemand (academisch) heeft laten zien dat een idee ook echt werkt, dan kan je altijd nog een bedrijf zoeken (of zelf opzetten, of hopen dat de open source community het doet) die er mee verder gaat en het uitontwikkelt.
Nog een ander alternatief is dat je ziet dat er nog veel verbeterpuntjes zijn voordat het practisch toepasbaar is (bijvoorbeeld als je die 3x - 4x overhead onwerkbaar vindt, het verdubbelde geheugengebruik te fors of de beperking tot 32bits te problematisch). In dat geval kan een andere afstudeerder (of misschien een promovendus) dit gebruiken als het begin van vervolgonderzoek.
Het is denk ik eerder de PaX patch waar de tool uit het artikel raakvlak mee heeft; PaX zorgt voor exploit mitigation met o.a. No-eXecutable pages (geheugen is nooit én beschrijfbaar én uitvoerbaar), ASLR, mprotect() restricties (JIT compilers hebben mprotect() nodig om naar geheugen te schrijven en dan uitvoerbaar te maken), randomization van bepaalde stacks en mmap(), en sanitization van freed memory, en bepaalde restricties op data die tussen kernel en userland worden uitgewisseld.

grsecurity zorgt meer voor algemene restricties op het systeem, o.a. auditing, chroot restricties, TPE, RSBAC (dat is wat zvbhvb hierboven bedoelt denk ik) en restricties op welke processen je als gewone user kan zien en wat je in /proc kan zien.

[Reactie gewijzigd door onox op 15 januari 2012 16:24]

De eerste hypervisors waren ook softwarematig waardoor virtualisatie beduidend langzamer was dan bare metal draaien. Inmiddels is CPU en I/O virtualisatie grotendeels in de hardware ingebakken waardoor virtualisatie bijna de snelheid van bare metal haalt.

Ik verwacht dat met een technologie als deze hetzelfde gaat gebeuren. Als het aanslaat dan gaan hardware fabrikanten de tijdrovende delen ervan op de chips implementeren zodat virtualisatie bouwers een snelle implementatie ervan kunnen maken. Als je data en code hardwarematig kunt controleren voordat het gebruikt/uitgevoerd wordt dan is de uitdaging voor crackers wel aanzienlijk groter.
De VM vertraagt de code-execution van het gevirtualiseerde process, niet de memory-delays, I/O-tijden, system-calls, etc. Een vertraging met factor 3 à 4 voor de code kan dus best overeenkomen met een vertraging met factor 1,5 à 3 voor de applicatie in z'n geheel.

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True