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.

Reacties (76)

[Hurm]

En als op de host machine nu het geheugen dusdanig verwarmd wordt zodat het fouten gaat maken, is zijn methode dan nog steeds toereikend?

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.

[totaalgeenhard]

De kans dat jij remote het geheugen dusdanig warm krijgt is net zo groot als dat door zonne- en kosmische straling ECC geheugen fouten maakt die niet gecorrigeerd kunnen worden.

Als je toch naar de datacenter gaat om je propaan straalkachel te gebruiken, kun je mogelijk gewoon fysiek de machine benaderen en doen en laten wat je wilt (single user mode/rescue disk etc..)

Ontopic: Er zijn al veel buffer overflow protectie waaronder randomizen, waardoor een exploit niet meteen tegen eenzelfde kernel gebruikt kunnen worden. Ik vraag me af of hij slechts een proof of concept heeft gemaakt of daadwerkelijk hiermee denkt een praktisch probleem te hebben opgelost, ten koste van een traag systeem.

Verder zijn de afgelopen jaren buffer overflow en heap overflow niet het grootste probleem van aan internet hangende servers. En is het "rooten" van servers allang niet meer het hoofddoel van kwaadwillende. Al met al had hij met zijn proefschrift een jaartje of twintig terug de ogen kunnen doen fronsen, maar maakt het vandaag de dag geen enkele indruk.

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.

Heeft iemand link naar proefschrift?

[Reactie gewijzigd door totaalgeenhard op 26 juli 2024 01:52]

[xtlauke]

"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.

[Zoijar]

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

[cire]

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.

[wica]

Kan je het geheugen niet warm laten worden door fan's uit te schakelen? Wat remote wel weer mogelijk is.

[Anoniem: 201824]

Raar dat dat zou kunnen. Wie wil er nu fans uit kunnen zetten?

[army]

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.

[humbug]

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.

[Dansion]

@ hierboven Goedemorgen Humbug je bent me net voor vroege vogel

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

[Yamotek]

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.

[varkenspester]

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)

[Thystan]

Een mogelijke oplossing tegen sql-injecties vind ik geen nutteloos project. Meer dan de helft van de bekende hacks wordt hiermee bewerkstelligd.

[Niosus]

natuurlijk moet je dan wel ook 3-4x meer servercapaciteit hebben, loont het dan niet meer de moeite om bijvoorbeeld een nieuwe taal te schrijven die deze zwakheid niet bevat? Ik ben absoluut geen expert, maar ik denk dat een combinatie van van gestructureerder programmeren en betere security audits dan kosteneffectiever gaat zijn. Als je vanaf het begin van je project rekening houdt met code injection attacks dan is het helemaal niet zo moeilijk. 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

[robvanwijk]

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....

[Gomez12]

??? waar lees jij iets over sql-injecties ???

[s.stok]

Laatste stuk van het artikel.

Enige aanpassingen zouden de tool geschikt kunnen maken om andere vormen van code-injectie, bijvoorbeeld sql-injecties, eveneens onschadelijk te maken.

Het is dan denk ik meer het idee van invoer 'zoals parameter' invoer niet vertrouwen voor uitvoer.

[GENETX]

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.

Ben ik niet met je eens. Ook in eerste instantie minder nuttige zaken kunnen uiteindelijk leuke bij-effecten hebben. Zeker in de techniek zijn bepaalde vindingen nuttig voor veel meer zaken dan vooraf gedacht. Sterker nog, ze kunnen juist extreem nuttig blijken voor andere zaken waar vooraf nooit aan gedacht werd.

[maniak]

Een onderzoek hoeft niet bij te dragen aan de maatschappij, het kan immers een onderzoek zijn voor een bedrijf met een specifiek probleem.

[CDL76]

Of fundamenteel onderzoek, om er achter te komen hoe iets werkt. Of om (in de chemie bijvoorbeeld) een nieuwe synthese route te vinden.

Allebei zijn het voor de maatschappij nutteloze onderzoeken, uiteindelijk kan dit echter wel leiden tot iets wat wel nuttig is voor de maatschappij, mensen zijn vaak zo kortzichtig, als het niet over 2 jaar in een product zit dan moet het onderzoek niet gedaan worden is een beetje het idee en dat is erg jammer, want zo kom je nergens.

on topic: leuk dat dit werkt en best goed gedaan voor een master scriptie, nu hopen dat het ook allemaal nog wat sneller word in de toekomst, vier keer zo langzaam als normaal is wel erg langzaam.

[Warbug]

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?)

[brammeer]

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.

[mvdejong]

Ahh, weer zo iemand die Nederland tot een terug-naar-de-grotten landje wil omvormen. Er wordt als sinds de 70er jaren door bepaalde partijen, afwisselend links en rechts, geprobeerd om het onderzoek in Nederland resultaat-gericht te maken. Het resultaat is dus dat we mogelijk technologisch kleine stapjes maken, maar grote doorbraken komen heel vaak juist uit onderzoek dat niet direct een bepaald probleem op te lossen.

[CDL76]

Helemaal mee eens. Grote resultaten komen ook juist voort uit die kleine stapjes, je hebt als wetenschapper iets nieuws gedaan en publiceerd dit, iemand gaat ermee verder enz. enz. totdat er soms een grote doorbraak is.

Lijkt wel alsof iedereeen denkt dat je na 2 jaar onderzoek doen een nieuw product neer kan zetten. stel ik begin vandaag met een onderzoek naar een auto die rijd op een fusiereactor, dan wil de maatschappij eigenlijk dat ze hem over 2 jaar kunnen kopen, anders is mijn onderzoek nutteloos en weg gegooid geld, die houding zorgt er echt voor dat we ergens komen met zn allen

Daarnaast creeert deze manier van denken ook een klimaat waarin veel onderzoekers (ook veel jonge) hier niet willen zijn, evenals de grote technologische ondernemingen. Wat de politici dus doen is zorgen voor goede opleidingen (alhoewel dat in dit tempo ook niet lang meer duurt), maar vervolgens de wetenschappers wegpesten, waardoor die achter de bedrijven aan gaan waar ze voor werken of actief een baan in het buitenland zoeken. Met als resultaat dat die zeikende belastingbetaler die niet wil dat zijn geld naar goed onderwijs en onderzoek gaat uiteindelijk heeft betaald voor de opleiding van goede wetenschappers die veel (belasting en kennis) terug hadden kunnen geven, maar uiteindelijk vertrekken uit het land, waardoor die belastingbetaler niks meer heeft.

[carnelain]

Het gaat hier om een afstudeerscriptie niet om een promotie.

[Punkie]

Jij hebt duidelijk niet veel kaas gegeten van het academische leven of bent gehersenspoeld door je eigen interpretatie de "spin-off school". Het overboord smijten van fundamenteel onderzoek wordt door quasi niemand ondersteund en zelfs de universiteiten welke hun onderzoeksonderwerpen laten bepalen door politiek en geldelijke belangen zullen dit als absurd verklaren. Dat jij niet in kan zien dat fundamenteel onderzoek veel nut heeft wil niet zeggen dat mensen met kennis ter zake dat WEL doen en al honderden jaren een mening tegengesteld aan die van jou uitvoeren.

[T-men]

Anyway, heb nu al spijt dat ik gereageerd heb omdat het niveau hier dramatisch laag ligt.

... sprak de gene van wie zijn eigen profiel een reactiescore van -8 (-0,1 gemiddeld) vermeldt.

Dat niet alleen, de post waar jij zo fel op reageert van totaalgeenhard is nog eens terecht ook ! Het typische doel van malware is om op afstand een computer/server over te nemen. B.v. om data te stelen, of om de machine op te nemen in een bot-net.

Maar on-topic:
Erik Bosman, die de tool uit het artikel ontwikkelde, heeft 3 mooie prestaties geleverd:

• Hij heeft een mooie prestatie geleverd voor zijn masterscriptie
• Die prestatie is direkt van maatschappelijk nut
• En hij heeft het ook nog eens aan de open-source community ter beschikking gesteld

Well done. Proficiat !

[robvanwijk]

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!).

[churchill9]

Daar heb je een punt anders hadden ze de ps3 ook kunnen hacken door hem te verwarmen

[GENETX]

En hoe snel ga je die fouten in je geheugen krijgen dan denk je? Tegen de tijd dat de data in je geheugen corrupt wordt door het falen van de hardware loopt je hele systeem vast. Ooit Windows proberen te draaien op corrupt geheugen? Binnen no time heb je BSOD's

Systemen kunnen altijd falen door het falen van hardware. Een zwak punt zal er daarbij altijd blijven. Elk systeem dat als backup dient voor een mogelijk falen van een ander stuk hardware kan ook falen. Dat heeft dan op zijn beurt ook weer een backup nodig en zo gaan we door.... Enkel de kans dat het totale systeem faalt zal kleiner worden en richting 0 gaan, maar zal het nooit worden.

[Anoniem: 55347]

GENETX heeft gelijk. Niet te vergeten dat als je een servertje draait daar uiteraard ook heat-control op uitvoert. Je wilt toch weten of een systeem niet te warm gaat worden. Beetje goede server opstelling zorgt er dan voor dat een backup systeempje start en vervolgens weer zelf afsluit en afkoelt (alvorens de IT in te lichten er een nieuwe te plaatsen). Of de IT inlicht en plat gaat. Beetje service contract zorgt ervoor dat zo'n IT binnen 4 uur op plek is en het systeem vervangen moet worden.

Dus een systeempje plat gooien door de fans uit te schakelen voor niks is een beetje nutteloos :-)..

Niet te vergeten dat je dus eerst iets malwaredigs op het systeem moet zetten om het te kunnen doen.. op afstand..

[pm1]

Ik vermoed dat de code zicht voornamelijk toespitst op servers en in servers wordt meestal wel ECC RAM gebruikt.

[Cyberwizzard]

Deze vinding gaat over exploits en het tegenhouden er van in het geheugen. Dit heeft geen klap te maken met fouten die optreden bij het oververhitten van RAM chips en de gevolgen daar van... fipo...

[Pim.]

Ik vindt het jammer om negatief te moeten doen aangezien ik direct geloof dat de auteur er een hoop werk in heeft gestopt en dat het heel erg knap is dat hij op dat niveau aan het programmeren is MAAR:

- Het is gemaakt voor Linux machines (markaandeel 3% desktop 60% server)
- Het werkt alleen op x86 machines, zijn die er nog ??? Zeker de servers zijn gezien hun geheugenhonger al lang x64
- het is te omzeilen, al is dat moeilijk
- het is geen proof of concept, zoals eerder al aangegeven, het idee bestaat al

Hiermee wil ik zeggen dat de doelgroep zo klein is dat het helaas nooit gebruikt gaat worden, en daar komt het omzeil verhaal dan nog bij.

nb. Omzeilen zal denk ik geen enkele hacker gaan doen zolang dit geen mainstream securtyfeature is

[apt]

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.

[robvanwijk]

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.

[Anoniem: 434945]

Het is niet bedoeld voor de verkoop maar puur voor zijn scriptie.. Dan is het gewoon niet haalbaar om zulke dingen te doen en moet je voor een makkelijkere weg kiezen.

[UPPERKEES]

Erg interessant, maar kan de Linux Grsecurity patch (https://grsecurity.net/) dit ook niet allemaal al maar dan beter?

[onox]

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 26 juli 2024 01:52]

[zvbhvb]

Beter is nog moeilijk te zeggen. Dat zal in de praktijk nog bewezen moeten worden.
Veel mechanismen overlappen elkaar. Zo is het bijvoorbeeld eenvoudig om TPE (trusted path execution in te schakelen en een group id in te stellen waarvoor alle leden die beperking geld). Of later gebruikers toevoegen met gpasswd -a.

Dan kan een lid van de tpe groep niets meer uitvoeren buiten wat root heeft geinstalleerd in de officiele paden. Verder heeft GRsecurity een laten we gemakshalve zeggen een bestands firewall zoals SELinux en apparmour die ook hebben.

Verder gaat men er bij Grsec er terrecht vanuit dat het heel eenvoudig is om uit een chroot jail te ontsnappen en bied tijdens de kernel configuratie veel extra restrictie mogelijkheden.

Maar het een hoeft het ander niet uit te sluiten. Zo is het mogelijk om zowel GRsecurity als SELinux te hebben. Zo zou het de moeite lonen om deze virtuele techniek die hier besproken wordt te laten bestaan in een chroot jail met extra GRsecurity restricties.

In de ideale situatie houdt je alleen de configuratie fouten over bij alle software die mogelijkheden bieden om te infiltreren maar niet perseen een heap/stack buffer overflow.

[SOCO_cola]

Interessant, jammer maar met dit model logisch dat het ten koste van de performance gaat, maar kan me voorstellen dat dit zeer waardevol kan zijn voor systemen die 100% reliable moeten zijn (voor zover dat kan) en weinig load te verwerken krijgen.

[Reactie gewijzigd door SOCO_cola op 26 juli 2024 01:52]

[brompot758]

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.

[SOCO_cola]

Inmiddels is CPU en I/O virtualisatie grotendeels in de hardware ingebakken waardoor virtualisatie bijna de snelheid van bare metal haalt.

Ti's maar net hoe je het bekijkt, helaas is door het gehele sales apparaat het hoger management ingepraat dat virtualisatie niet ten koste van de performance gaat. Helaas werkt dit in 9 van de 10 gevallen niet. je stelling klopt dat 1 op 1 misschien de snelheden zowat gelijk liggen, maar het voordeel zou juist gehaald moeten worden in het efficient verdelen van de virtuele resources onder alle virtual machines.

Zodra je 1 op 1 gaat virtualiseren is het voordeel van Virtual Machines achterhaald.

maar goed off topic gelul

[densoN]

Binnen de virtual machine draait code significant langzamer. Over het algemeen kan het drie tot vier keer langer duren voordat code is uitgevoerd.

We developed Minemu, a
fast taint-tracking x86 emulator and showed that the slow-down caused by the combination of taint analysis and emulation ranges between 1.5x and 3x for real applications.

Zit dit verschil hem in het toevoegen van de virtuele machine bovenop de emulator? 1,5x of 4x lijkt me nogal een verschil nl.

[Reactie gewijzigd door densoN op 26 juli 2024 01:52]

[M0N0]

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.

[DCG909]

Dus dit werkt niet op AMD cpu's?
Dat lijkt mij wel jammer.

[GENETX]

Nee, AMD heeft ook wel 32-bit processors gemaakt. Daarbij zijn alle huidige Intel's ook 64-bit. Ik neem aan dat je doelt op dit deel:

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."

Ik vermoed echter dat het gaat om het in 32-bit mode draaien van je CPU door een 32-bit OS te nemen. Omdat x86 processors backwards compatible zijn kan deze schakelen tussen 64-bit en 32-bit. Sterker nog, je kan ook terug naar een 16-bit mode. Dus ik verwacht dat dit net zo goed werkt op alle nieuwe AMD en Intel processoren.

Sowieso is de veelgebruikte term x64 eigenlijk fout en erg verwarrend. x86 komt van de 286, 386, 486 etc af. Allemaal <iets>86, oftewel x86. x86 is dan ook een instructieset. Alle x86 processors kunnen de x86 "taal" begrijpen en uitvoeren volgens de x86-specificaties (zie het spelling). Wel evolueert de taal, dus krijg je bijvoorbeeld ook SSE en MMX er bij die oudere processoren niet kunnen uitvoeren. x86-64 (wat beter is om te gebruiken) is net als SSE een uitbreiding. In dit geval dus om 64-bits registers en geheugenadressen te kunnen gebruiken. Dat wil echter niet zeggen dat alle oude 32-bit zaken niet meer worden begrepen. Gelukkig niet zeg, anders zou de originele Windows XP (32-bit) mooit op de AMD Athlon 64 hebben kunnen draaien

[Reactie gewijzigd door GENETX op 26 juli 2024 01:52]

[.oisyn]

x64 is net zo'n goede (of slechte) benaming als dat x86 dat is. Het is daarom wel grappig dat je beweert dat x86 wel een goede term zou zijn, maar x64 niet. Terwijl waar het uiteindelijk om gaat is dat iedereen je begrijpt als je x64 zegt. Het is namelijk zo dat, als iemand het over x86 heeft, er automatisch de 32 bits ISA wordt bedoeld, terwijl de 8086 en 80286 er ook gewoon onder vallen.

De échte naam van de 32 bits ISA is namelijk IA-32, en AMD64 voor de 64 bits ISA, al heeft Intel die laatste uiteindelijk omgedoopt naar Intel 64 (niet te verwarren met IA-64, dat is Itanium).

[Reactie gewijzigd door .oisyn op 26 juli 2024 01:52]

[CDL76]

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.

[Xudonax]

AMD CPU's hebben ook al tijden SSE, dus dat moet gewoon werken. SSE is echter oorspronkelijk een Intel uitvinding.

[HaseMike]

Dankzij meneer Moore kunnen we dus over 3-4 jaar de met deze beveiliging de snelheid van vandaag halen. Over niet al te lange tijd kunnen we dan alle malware vaarwel zeggen.

[T-men]

Meneer Moore (zijn wet bedoel je waarschijnlijk ) geeft aan dat de hardware inderdaad wel zal versnellen de komende jaren. Daarbij wordt vaak vergeten dat de software min of meer dezelfde trend volgt waardoor netto de versnelling veel minder is.

Deze tool zou een van de redenen kunnen zijn waardoor moderne software steeds zwaardere machines nodig heeft. (Niets ten nadele van de tool zelf. Die vind ik het een prima aanvulling, alleen jammer dat het nodig is) Maar kort door de bocht heb je wel gelijk.

Over niet al te lange tijd kunnen we dan alle malware vaarwel zeggen.

Helaas... de malware bakkers hebben wellicht een stuk gereedschap minder (mits e.e.a. correct geïmplementeerd is) maar zij hebben nog meer pijlen op hun boog.
Niet in de laatste plaats de gebruiker zelf aangezien massa's gebruikers nog steeds standaard op 'Ja' klikken bij elke vraag die het systeem hen stelt.

Het blijft een competitie. Malware bakkers vinden een exploit, anderen doen hun best om deze te dichten (en introduceren daarbij soms ongewild nieuwe zwakheden), waarna de malware bakkers op zoek gaan naar een andere exploit. De praktijk leert helaas dat ze die ook gaan vinden.

[SuperDre]

dat was ook mijn gedachte, want en dat is dus het probleem tegenwoordig, ofwel heb je supersnelle hardware, maar door dit soort 'onzin' zit je weer met een systeem dat net zo snel is als je oude hardware, zo sund.

[Zoijar]

Leuke tool, maar volgens mij bestonden dit soort dingen toch wel al? Denk aan valgrind bijvoorbeeld.

[s.stok]

Valgrind is voor debugging en profilling

Deze tool kan beter worden gezien als een sandbox.

[Rukapul]

Hij gebruikt wel dezelfde concepten als Valgrind Als ik het me goed herinner gebruikt Valgrind zelfs Qemu wat weer een link brengt naar virtualisatie, etc. De concepten liggen dus wel heel erg bij elkaar.

[Zoijar]

Valgrind is voor debugging en profilling

Maar functioneert ook dmv de code op een virtual machine te draaien en zo al je geheugen accesses te indexeren. Ik zie het fundamentele verschil niet met dit.

(niet dat het uitmaakt overigens; nog steeds een leuk/knap project)

[Reactie gewijzigd door Zoijar op 26 juli 2024 01:52]

[Gomez12]

Alhoewel ik het idee best grappig vind is de uitkomst imho simpel waardeloos :
- De vertraging kom je desgewenst met hardware wel omheen.
- Maar dat hij nu al een exploit weet dat is imho onwerkbaar. Bij exploits is moeilijk of niet moeilijk niet relevant, dat is enkel een kwestie van tijd. Nieuwe exploits zullen ook altijd gevonden worden, maar die nu al bekende exploit maakt het wmb totaal onbruikbaar

[densoN]

Alhoewel ik het idee best grappig vind is de uitkomst imho simpel waardeloos :
- De vertraging kom je desgewenst met hardware wel omheen.
- Maar dat hij nu al een exploit weet dat is imho onwerkbaar. Bij exploits is moeilijk of niet moeilijk niet relevant, dat is enkel een kwestie van tijd. Nieuwe exploits zullen ook altijd gevonden worden, maar die nu al bekende exploit maakt het wmb totaal onbruikbaar

Volgens jou beredenering is een 2048-bit encryptie dus ook onbruikbaar? De moeilijkheidsgraad is wel degelijk relevant imo.

Als je bijvoorbeeld nagaat dat een besturingssysteem als Windows 7 meer dan 50.000.000 regels code bevat kan je ook snel concluderen dat een exploit-vrij systeem van dergelijke omvang gewoon onhaalbaar is. Wil je dit wel zal dit de innovativiteit en bruikbaarheid zo enorm in de weg zitten dat het systeem onbruikbaar wordt. En zelfs dan is het de vraag of een oplossing kans maakt tegen de immens snelle ontwikkelingen op het gebied van software.

Zie deze techniek daarom als een drempel en niet als een wonder oplossing.

[Reactie gewijzigd door densoN op 26 juli 2024 01:52]

[Gomez12]

2048 bit-encyptie is van een totaal andere orde.

Dat is niet moeilijk te kraken, daar speelt enkel de tijd (en huidige hardware) een rol.
Als ik het verhaaltje zo lees dan is hier enkel de de moeilijksheidsgraad het obstakel, niet tijd (/processing power)

Een 2048-bit encyptie is qua moeilijkheidsgraad ook niet anders dan een standaard md5-encryptie. Toch is de ene af te raden en de ander kan nog wel een tijdje mee.

Hier gaat het over "enkel" de moeilijkheidsgraad en niet over andere factoren als tijd.

En ik zie het niet als wonder oplossing, enkel verwacht ik iets meer als iets waarvan nu al bekend is dat er een bug inzit. Nu is het enkel een systeem erboven wat een (gigantische) extra complexiteit introduceert en wat in de basis weinig oplost.

Vergeet niet de gigantische hoeveelheid extra complexiteit die er nu bij komt kijken. Een app crashed, is dat nu het probleem van de app, het OS of deze laag erboven?

[borft]

ik neem aan dat je weet dat md5 geen encryptie is? dat is een one-way hash algorithme

[zvbhvb]

Voor 64-bit linux zou je de kernel kunnen patchen met GRsecurity.

http://grsecurity.net/

[Anoniem: 70937]

De inleiding van zijn proefschrift komt op mij een beetje tendentieus over.

Zijn inleiding verwijst naar een pax met als jaartal 2001 met een algemene verwijzing naar een website. Recente ontwikkelingen voortbouwend op pax als uderef en mprotect lijken dezelfde problemen aan te pakken als minemu. Gezien het feit dat pax/uderef/mprotect vrij goed gedocumenteerd zijn, is een gebrek aan een betere verwijzing hier mijns insziens een tekortkoming. Mijn kennis schiet te kort om pax/grsecurity met minemu te vergelijken. De toon van het rapport lijkt te stellen dat minemu de problemen grondiger aanpakt ten koste van een fixe performance drop, maar een vergelijking mist.

Verder gebruikt hij een conclusie uit een rapport over Windows systemen om aan te tonen dat onder Linux DEP en ASLR implementaties niet goed zijn (met een verlopen link, dit document is te vinden onder http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf). Het lijkt me aanemelijk dat DEP en ASLR tekort schieten onder Linux, maar dat blijkt dus niet uit het rapport.

Ik hoop dat de inleiding een slordige kopie is uit een ouder verslag. Het project zou een voortzetting kunnen zijn van bestaand onderzoek naar een specifieke oplossing. Het doel van de opdracht is kennelijk niet het rechtvaardigen van het onderzoek, maar de implementatie en performence testen.

Het zou interessant en nuttig zijn een vergelijk te zien tussen bovenstaand systeem en een modern volledig geconfigureerd Hardened Gentoo systeem. Maar dat zou een compleet andere opdracht zijn.