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)
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.
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.
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?
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 zondag 15 januari 2012 11:27]
Master's scriptie, groot verschilHeeft iemand link naar proefschrift?
Dit is hem zo te zien: http://www.google.com/url...juQ_okxkCN6Jw&cad=rja
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.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.
Een onderzoek hoeft niet bij te dragen aan de maatschappij, het kan immers een onderzoek zijn voor een bedrijf met een specifiek probleem.
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.
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.
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?)
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.
Het gaat hier om een afstudeerscriptie niet om een promotie.
... sprak de gene van wie zijn eigen profiel een reactiescore van -8 (-0,1 gemiddeld) vermeldt.Anyway, heb nu al spijt dat ik gereageerd heb omdat het niveau hier dramatisch laag ligt.
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
Een mogelijke oplossing tegen sql-injecties vind ik geen nutteloos project. Meer dan de helft van de bekende hacks wordt hiermee bewerkstelligd.
??? waar lees jij iets over sql-injecties ???
Laatste stuk van het artikel.
Het is dan denk ik meer het idee van invoer 'zoals parameter' invoer niet vertrouwen voor uitvoer.Enige aanpassingen zouden de tool geschikt kunnen maken om andere vormen van code-injectie, bijvoorbeeld sql-injecties, eveneens onschadelijk te maken.
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
Met andere woorden: nagenoeg alle code die in productie draait...?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
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...Als je vanaf het begin van je project rekening houdt met code injection attacks dan is het helemaal niet zo moeilijk.
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....
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.
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.
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.
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.
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.
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.
"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.
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.
Kan je het geheugen niet warm laten worden door fan's uit te schakelen? Wat remote wel weer mogelijk is.
Raar dat dat zou kunnen. Wie wil er nu fans uit kunnen zetten?
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.
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)
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)
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.
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.
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.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
@ 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
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
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.
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.
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..
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..
Ik vermoed dat de code zicht voornamelijk toespitst op servers en in servers wordt meestal wel ECC RAM gebruikt.
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...
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.En als op de host machine nu het geheugen dusdanig verwarmd wordt zodat het fouten gaat maken, is zijn methode dan nog steeds toereikend?
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.
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!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.
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!).
Daar heb je een punt anders hadden ze de ps3 ook kunnen hacken door hem te verwarmen
Totdat de VM weer een geheugenlek bevat, moet deze dan ook weer in een VM draaien 
VMception?
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 zondag 15 januari 2012 11:18]
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.
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.
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.Inmiddels is CPU en I/O virtualisatie grotendeels in de hardware ingebakken waardoor virtualisatie bijna de snelheid van bare metal haalt.
Zodra je 1 op 1 gaat virtualiseren is het voordeel van Virtual Machines achterhaald.
maar goed off topic gelul
Dus dit werkt niet op AMD cpu's?
Dat lijkt mij wel jammer.
Dat lijkt mij wel jammer.
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:
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
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.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."
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 zondag 15 januari 2012 11:29]
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).
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 zondag 15 januari 2012 18:46]
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.
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.
AMD CPU's hebben ook al tijden SSE, dus dat moet gewoon werken. SSE is echter oorspronkelijk een Intel uitvinding.
Leuke tool, maar volgens mij bestonden dit soort dingen toch wel al? Denk aan valgrind bijvoorbeeld.
Valgrind is voor debugging en profilling
Deze tool kan beter worden gezien als een sandbox.
Deze tool kan beter worden gezien als een sandbox.
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.
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.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.Valgrind is voor debugging en profilling
(niet dat het uitmaakt overigens; nog steeds een leuk/knap project)
[Reactie gewijzigd door Zoijar op zondag 15 januari 2012 13:30]
Knap gedaan!
Ik vind het een mooi initiatief van de master student en daarnaast ook een goed en overzichtelijk artikel.
Ik draai helaas geen Linux anders wilde ik het zeker hebben. Hopelijk horen we meer van deze persoon met programma's maken. Heel veel succes in ieder geval.
Ik vind het een mooi initiatief van de master student en daarnaast ook een goed en overzichtelijk artikel.
Ik draai helaas geen Linux anders wilde ik het zeker hebben. Hopelijk horen we meer van deze persoon met programma's maken. Heel veel succes in ieder geval.
...en nu is het wachten op een exploit van deze anti-exploit tool...
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
- 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
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.
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.
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 te omzeilen, al is dat moeilijk
Ehm, als het idee al bestaat, maar hij maakt er nu werkende code van, is het dan niet juist een proof-of-concept!?het is geen proof of concept, zoals eerder al aangegeven, het idee bestaat al
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.Hiermee wil ik zeggen dat de doelgroep zo klein is dat het helaas nooit gebruikt gaat worden
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.
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.
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.
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
