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
@ hierboven Goedemorgen Humbug je bent me net voor vroege vogel :O

hier een lijst van unit-testing frameworks voor zo'n beetje alle talen :

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

Het is in mijn ogen echt not-done om op belangrijke source-code geen unit-testing te doen.
Zelfs voor kleine projecten kan het enorm veel debug-kopzorgen schelen
Een kwaadwillende die het geheugen fouten wil laten maken?

Lijkt mij dat als je al op zulk niveau bent om de fans uit te schakelen dat het geheugen warm laten worden ook niet heel veel nut meer heeft.
Voordat het geheugen warm wordt ligt de CPU er toch vaak al uit? Die produceert immers veel meer warmte.
Je gaat de optie om fans uit te schakelen niet inbouwen in je systeem als dit enkel nuttig is voorkwaadwilligen.

Niemand, buiten kwaadwilligen, wil fans remote kunnen uitschakelen. Daarom wordt die extra mogelijkheid, die alleen maar geld kost, ook gewoon niet ingebouwd. M.a.w. je KAN de fans gewoon niet uitschakelen remote (geen koppeling met de software maar enkel rechtstreekse stroomaanvoer)
Het probleem is vooral legacy code of code die vlug-vlug "tijdelijk" erbij geplakt is zonder erbij stil te staan dat die waarschijnlijk niet meer vervangen wordt
Met andere woorden: nagenoeg alle code die in productie draait...?
Als je vanaf het begin van je project rekening houdt met code injection attacks dan is het helemaal niet zo moeilijk.
Jawel, dat is wel moeilijk. Code die verkeerde resultaten produceert is lastig genoeg te debuggen (door te kijken of de resultaten kloppen). Maar hoe ga je debuggen op "bevat geen injection vulnerabilities"? Daar moet je specialisten naar laten kijken en dat kost geld zonder dat het (op korte termijn!) iets oplevert, dus dat zal lang niet altijd goed (genoeg) gebeuren. Bovendien, zie ook de eerste quote...
Ja, het zou mooi zijn als programmeurs foutloze code zouden produceren, maar laten we eerlijk zijn, dat is geen realistische aanname zelfs aan de TU/e, waar correct programmeren ("De Eindhovense School", "Dijkstra") altijd belangrijk was is dat nu uit het curriculum verdwenen....
Ik vind die langzaamheid best meevallen, zeker gezien wat die allemaal moet doen tegenover een normale vm, die ook niet altijd even snel zijn

Maar gezien hij zo vriendelijk geweest is om het open source te maken denk ik dat als er nog belangrijke optimalisaties te maken zijn het niet zo heel lang op zich laat wachten, zeker niet als er veel interesse in is.

Maar bij zoiets als dit verwacht ik persoonlijk geen wonderen omdat dit niet het belangrijkste is hierbij, ik zou denken dat de genoemde zwakheid tegen bepaalde gehugenbewerkingen een hogere prioriteit heeft.

En ik onderstreep ook het geldende sentiment hier van dat je niet altijd rechtstreeks naar maatschappelijk nut moet zoeken, aangezien een hoop maatschappelijk nuttige dingen uitgevonden worden terwijl gezocht word naar iets heel anders (zoek maar eens naar "accidental inventions" voorbeelden zat, zou je die echt willen missen?)
Je studeert toch om iets te leren. Ook een scriptie is bedoeld om veel te leren, over het onderwerp waar je het over schrijft, maar vooral ook de manier waarop je dat doet. Hoe je onderzoek doet en dit soort problemen oplost, is vaak belangrijker dan het probleem zelf. Vaak is er ook niet voldoende geld om maatschappelijk relevante problemen verder uit te werken na het schrijven van de scriptie. Wat ik dus wil zeggen, het gaat hier niet perse om het eindresultaat, maar meer het proces.
Als we dan toch alle oude CPUs (van intel) opnoemen die x86 compatibel zijn dan vergeet je deze nog: 8085, 8088, 80186 en 80188

en dan zijn er daarnaast ook nog de losse FPU's die later geintegreerd werden in de CPU, zoals de 8087, 80187, 80287 en 80387, deze gebruiken de x87 instructieset, maar is tegenwoordig zo standaard in de CPU dat het als onderdeel van de x86 set te zien is.

Daarnaast was er dan ook nog de 487SX, dit is een 486DX CPU die bij een 486SX cpu op het bord gestoken werd, maar alle taken van de CPU overnam, hij is dus genoemd naar een coporcessor, maar bevat zowel x86 als de uitbreiding (x87) instructies.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 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