Flip Feng Shui-aanval maakt lekken van ssh-sleutel uit vm mogelijk

Onderzoekers van de Vrije Universiteit en de KU Leuven hebben een aanval op virtual machines gepresenteerd. Deze draagt de naam 'Flip Feng Shui' en maakt het mogelijk om het geheugen van een andere virtual machine op dezelfde host te manipuleren en zo bijvoorbeeld ssh-sleutels te stelen.

De aanval werkt doordat virtual machines op dezelfde host gebruikmaken van een gedeeld fysiek geheugen, zo stellen de onderzoekers op hun pagina. Voor de uitvoering van Flip Feng Shui is het eerst nodig om met de vm van de aanvaller geheugencellen te identificeren die vatbaar zijn voor een zogenaamde Rowhammer-aanval. Deze werkt door snel achter elkaar bepaalde geheugenrijen te activeren, waardoor de staat van een cel veranderd wordt en een bit van 0 naar 1 geflipt kan worden. Vervolgens genereert een aanvaller een geheugenpagina, waarvan de inhoud overeenkomt met een pagina van de slachtoffer-vm.

Daarna dedupliceert het systeem de beide pagina's, omdat de inhoud gelijk is. Dedupliceren is een techniek waarmee geheugen kan worden bespaard. Deze aanvalsvorm kwam bijvoorbeeld ook voor in eerder onderzoek van het team van wetenschapper Herbert Bos, die ook aan dit onderzoek heeft meegewerkt. Zodra de inhoud van de pagina's op één fysieke geheugenpagina is samengevoegd, kan de aanvaller door middel van een Rowhammer-aanval het geheugen van het slachtoffer manipuleren. Daarbij worden de bits direct in het dram-geheugen geflipt.

Flip Feng Shui, oftewel FFS, maakt het bijvoorbeeld mogelijk om op die manier de bits van een in het geheugen opgeslagen OpenSSH-sleutel te flippen, waardoor deze sleutel achterhaald kan worden. Zo kan de aanvaller toegang krijgen tot de volledige server van het slachtoffer. Een ander voorbeeld dat de onderzoekers beschrijven, is het manipuleren van het 'apt get'-commando, waardoor kwaadaardige software op de vm van het slachtoffer geïnstalleerd kan worden.

Daardoor is de impact van de aanval groot en zijn alle systemen die geheugendeduplicatie ondersteunen, kwetsbaar. Ook blijkt uit eerder onderzoek dat 85 procent van alle ddr3-modules vatbaar is voor Rowhammer. Tot nu toe waren aanvallen op virtual machines vaak beperkt tot sidechannel-technieken, die zich richtten op het afluisteren van gegevens. In dit geval gaat het echter om een actieve aanval.

Het Nederlandse NCSC is voor de presentatie van de aanval door de onderzoekers ingelicht en heeft een factsheet met een vraag-en-antwoordgedeelte gepubliceerd. Ook zijn partijen als OpenSSH, GnuPG, Oracle, VMware, Xen en Ubuntu van de aanval op de hoogte gesteld. De onderzoekers maken deel uit van VUSec, de Systems and Networking Security-groep van de Vrije Universiteit in Amsterdam, en de KU Leuven. Het huidige onderzoek is te vinden op de website van de onderzoeksgroep.

Een demonstratie van Flip Feng Shui, waarbij een ssh-sleutel wordt achterhaald.

Reacties (38)

Maar dit vereist dus wel dat Rowhammer functioneert, wat op veel servers inderdaad het geval zal zijn, maar er is al gewerkt aan hardwarematige oplossing van dat probleem (zoals ook te lezen op de gelinkte pagina). Dat is maar goed ook, want met Rowhammer kun je cross-process geheugen manipuleren, wat al erg genoeg is. Cross-VM is natuurlijk nog een graadje erger. Iedereen die professionele servers draait zou ook een Rowhammer proof geheugencontroller moeten hebben. Dit is dus eerder een verergering van een bestaande exploit die zelf al ernstig was.

DDR3 ECC of nog beter: DDR4(-ECC), beiden zijn niet/veel minder vatbaar voor rowhammer. DDR4 is zelfs nog betrouwbaarder dan DDR3 ECC.

Zie onder andere deze reactie: mux in 'nieuws: Onderzoekers maken misbruik van fysieke tekortkomingen ddr3-g...

[Reactie gewijzigd door ByteArray op 10 augustus 2016 14:02]

DDR4 is zelfs nog betrouwbaarder dan DDR3 ECC.

Volgens mij is DDR4 helemaal niet altijd immuun.. http://arstechnica.com/se...-vulnerable-to-rowhammer/

Jammer genoeg heeft Ars belangrijke resultaten verkeerd overgenomen. DDR4 met chips van Hynix konden de onderzoekers niet succesvol aanvallen; van Samsung nauwelijks; van Micron wel. Geil gebruikt Hynix en G Skill gebruikt Samsung, maar Crucial gebruikt Micron.
http://security.stackexch...mputer-against-row-hammer

Mja, dan hoop ik dat de onderzoekers snel met details komen, want anders zou het geheel toch wel heel erg mee moeten vallen. De meeste systemen zouden dan niet vatbaar moeten zijn, want een VM host die geen ECC heeft of geen DDR3/4 is toch wel heel uitzonderlijk. Mogelijk hebben ze een nieuwe techniek bedacht om rowhammer alsnog uit te buiten. De vraag- en antwoordsheet geeft geen informatie, behalve dat ECC het "moeilijker" maakt en deduplicatie uitgezet zou moeten worden (terwijl het mij veel belangrijker lijkt dat rowhammer onmogelijk gemaakt wordt...)

[Reactie gewijzigd door MneoreJ op 10 augustus 2016 14:07]

Rowhammering wordt als het goed is op servers grotendeels afgevangen door ECC-geheugen, toch? Waardoor het systeem weet dat het geheugen fout is, en de berekening dus afbreekt.

Helaas niet. Rowhammer kan namelijk multi-bit flips doen die ECC niet detecteert. Vandaar ook dat controllers erop aangepast moeten worden; ECC hebben de servers al.

ECC kan 1-bitflip detecteren en corrigeren en 2-bit-flips detecteren (en dus niet corrigeren). Bij meer dan 2 bitflips is er inderdaad geen garantie dat het gedetecteerd wordt, maar de kans is wel aanwezig natuurlijk, afhankelijk van hoe en welke bits precies geflipt worden. Met een rowhammer-attack heb je daar niet echt invloed op aangezien het geen deterministisch proces is.

Maar goed, het zou kunnen, maar ECC-RAM maakt het wel een stuk lastiger om een dergelijke aanval uit te voeren.

Lastiger ja, maar de ervaring leert dat "lastig" niet meer iets is waar aanvallers zich echt door tegen laten houden. Als je kijkt hoe ver we gekomen zijn sinds de eerste (triviale) buffer overflows en hoe de technieken steeds verder aangeslijpt zijn om iedere kleine zwakheid uit te buiten... De vraag is nu of het lastiger is in de zin dat het werkt als de beheerders maar voldoende ECC fouten negeren, of lastiger in de zin dat het waterdicht te doen is maar veel meer tijd/onderzoek per systeem kost. Ik hoop dat daar meer duidelijkheid over zal komen van de onderzoekers.

[Reactie gewijzigd door MneoreJ op 10 augustus 2016 15:54]

Eigenlijk zou je als bedrijf een tool willen hebben die valideerd of jou Docker / VM / Cloud hosting partij niet gevoelig is voor Rowhammer.

Je (virtueel) data centrum kan anders zeer ernstige schade op lopen.
En dus zeker ook je klant data.

Liefst wil je die tools niet alleen voor je 3rd parties kunnen draaien als scan, maar ook voor diensten in je eigen server park.

Ik kreeg zojuist een mail van TransIP dat ze vandaag nog de nodige aanpassingen hebben gedaan aan hun VPS platform!

https://www.transip.nl/ni...r-de-flip-feng-shui-flaw/

Vmware heeft memory pagesharing (deduplicatie) al een tijd uitgefaseerd (ESX5.5 volgens mij). De impact daar lijkt me dus beperkt.

Niet helemaal uitgefaseerd, het staat per default uit (in ESXi 5.5, 5.1, 5.0 Updates en 6.0), maar kan handmatig weer aangezet worden. Zie ook "Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing". Nu moet ik zeggen dat ik het wel met de conclusie van VMware eens ben:

Currently, VMware believes that the risk of information disclosure described in the recent academic papers leveraging TPS between Virtual Machines is very small in real world conditions. The conditions under which the researchers were able to extract AES encryption keys are very specific and are unlikely to be present in a real world deployment.

[Reactie gewijzigd door the_shadow op 10 augustus 2016 15:16]

Dit was inderdaad ook het eerste wat ik dacht. Ben benieuwd of dat hier inderdaad voldoende voor is .

Dit werkt dus alleen voor virtualisatie-techieken waarbij er daadwerkelijk sprake is van gedeeld geheugen en deduplicatie. Ik gebruik Xen voor virtualisatie op een server. Hierbij wijs ik expliciet fysiek geheugen toe aan de VM's, en kan ook niet meer toewijzen aan de VM's gezamenlijk dan de host heeft. Het lijkt me sterk dat er dan deduplicatie toegepast zou worden, daar is niets mee te winnen aangezien elke VM sowieso zijn eigen geheugengebied heeft.

Is het mogelijk dat dit alleen werkt met meer client-georienteerde VM-systemen zoals VirtualBox, die gewoon normaal geheugen alloceren binnen het OS en daarmee vatbaarder zijn voor dergelijke optimalisaties?

XenServer heeft wel support sinds versie 5.6 geloof ik. Ik weet niet of het standaard aan staat.
https://wiki.xenserver.or...Memory_overhead_functions

Ook KVM en VMWare. En ondanks dat je expliciet geheugen toewijst aan een VM hoeft dat niet te betekenen dat de gegeven techniek niet gebruikt wordt. Dat je niet meer geheugen toe kan wijzen dan dat je hebt zou een teken kunnen zijn inderdaad, maar ik zou wel de configuratie nakijken. Echter; als je geen klanten op je VM's hebt of dat externe een eigen VM hebben, etc. hoef je je volgens mij ook niet druk te maken. Volgens mij heb je wel root-toegang nodig op in ieder geval 1 VM.

[Reactie gewijzigd door mrdemc op 10 augustus 2016 15:04]

Nou ja, als ik de VM's boot (paravirtualized overigens) dan is op de host per direct al het geheugen wat ik heb toegewezen in gebruik. Zelfs als in de VM het geheugen nog nagenoeg leeg is. Je kunt, mits het gast-OS dat ondersteunt natuurlijk, ook dynamisch RAM toewijzen waarbij je een maximum instelt in plaats van een totale hoeveelheid. Het zou best kunnen dat dat op een andere manier behandeld wordt.

Vraagje: geld dit ook voor Linux containers en chroot jails? En bijvoorbeeld de gepatched Xen kernel van qubes Os?

samengevat "defecte hardware geeft problemen". RMA die handel dus. Ik begrijp niet dat er niet massaal garantie geclaimd wordt. Ik heb het zelf niet aan de hand gehad, doen (geheugen) fabrikanten daar moeilijk over? Kan het me nauwelijks voorstellen. ongewenste bitflips = slecht geheugen. Zo simpel is het.

Zo simpel werkt het niet. Er zijn specificaties voor geheugen, en bitflips vallen daar ook onder. Het mag niet te vaak voorkomen. De eisen daarvoor zijn wel strenger geworden bij nieuwere iteraties, maar in principe is een bitflip bij een rowhammer attack geen reden tot RMA.

Interessant artikel ja. Tevens moet er ook nog memory deduplication op de host aanstaan als voorwaarde, naast Rowhammer.

Grote IT enterprises echter gebruiken voor hun virtuele workloads mostly vmware/hyperv etc (praat over ettelijk k's aan vm's)...bij de eerst genoemde staat het memory dedup mechanisme, Transparant Page Sharing sinds versie 5.5 (met recente patch) en versie 6 -uit-. Hier minimaliseer je dus de risicos wel weer mee.

Feit blijft dat idd die side channels vaker gaan/kunnen voorkomen. Risico blijft wel gelden voor ander type hostingpartijen die gebaseerd zijn op KVM/overig die omwille van efficiency die memory dedup functionaliteit wel aan hebben staan...daar wil je idd het OF uitzetten OF mitigerende maatregelen nemen.

edit: dycell was me net even voor

[Reactie gewijzigd door peterpaulk op 10 augustus 2016 14:04]

Als ik het goed begrijp stelen ze niet zozeer de ssh key, maar moet je al op voorhand weten wat de publieke sleutel van een van de gebruikers is. Deze zijn echter zodanig opgebouwd dat deze moeilijk te kraken (factorizeren) zijn. Door enkele bits te flippen op de originele VM kan de moeilijke publieke key echter in een gemakkelijkere publieke sleutel omgezet worden waar wel gemakkelijk een bijhorende private sleutel voor berekend kan worden.

Bvb: 97 * 113 = 10961, is 'moeilijk' te factorizeren, je moet immers alle priemgetallen tot 97 aflopen.
10961 binair = 10101011010001
Als je echter de laatste 2 bits kan flippen en er zo 10962 (10101011010010) van kan maken, dan is het veel eenvoudiger: 10962 = 2 * 3 * 3 * 3 * 7 * 29, hierbij moet je slechts de priemgetallen tot 29 aflopen.

Info voor KVM:
https://access.redhat.com...ation_Guide/chap-KSM.html

Op diezelfde pagina stond trouwens al dit:

The page deduplication technology (used also by the KSM implementation) may introduce side channels that could potentially be used to leak information across multiple guests. In case this is a concern, KSM can be disabled on a per-guest basis.

[Reactie gewijzigd door mrdemc op 10 augustus 2016 14:53]

Voor kritieke systemen is een virtuele omgeving (die gedeeld wordt met andere gebruikers) ook niet aan te raden.

Onder welke steen kom jij vandaan? Het overgrote merendeel van de huidige enterprise infrastructuren draait op het moment (en al enkele jaren) virtueel. Natuurlijk gaat het dan niet op 1 enkel servertje, maar om VMware/Hyper-V HA clusters. Van web servers tot databases, van clients (VDI) tot domain controllers.

[Reactie gewijzigd door the_shadow op 10 augustus 2016 15:20]

Ergens heeft @kritischelezer wel gelijk. Deze aanval vereist voor zover ik het begrijp dat je code danwel commando's kan uitvoeren op de host waarmee je de aanval doet. Over het algemeen hebben gebruikers geen shell toegang tot de web-, database- of fileservers waar ze gebruik van maken. Die kunnen dan ook prima gevirtualiseerd worden. Servers waar je gebruikers wel het recht geeft om direct op in te loggen via SSH, RDP of Citrix kan je dus beter bare-metal houden is denk ik het punt.

Servers worden onder andere juist gevirtualiseerd omdat de kosten van iedere jandoedel zijn eigen rackserver te geven voor veel jandoedels niet interessant zijn. Virtuele hosting is veel goedkoper. Natuurlijk kun je dan ook zeggen "jandoedel, hou er rekening mee dat jandoedel2 misschien je data kan lezen met sneaky exploits" en dan kijken of ze nog steeds willen betalen, maar het is toch fijner als dit soort vulnerabilities opgelost worden zodat je wel de boel kan virtualiseren.

Webservers en databaseservers zijn natuurlijk bij uitstek machines waar jandoedel code op kan uitvoeren, by design (be it PHP, SQL, of Javascript -- ja, Rowhammer is ook uit te buiten via JS). Fileservers wat minder, al kun je ook dan als kwaadwillende jandoedel op zoek naar exploits.

Virtuele hosting houdt altijd een beveiligingsrisico in voor als de virtualisatielaag doorbroken wordt, dat is waar. Maar fysieke scheiding is ook niet heilig, tenslotte, zolang er een netwerkverbinding tussen machines moet liggen. Kosten, baten, risico's, afweging, etc.

Ja virtualiseren is prima, maar dan op je eigen server natuurlijk. Het gaat erom dat een gedeelde server toegang geeft tot mensen die niets met je eigen site te maken hebben. Dit is in beginsel altijd een beveiligings risico.

Enig idee waarom mensen cloudflare gebruiken? Dit om ip van de server uit beeld te houden, nog niet eens over toegang tot die eigen server. Bij het delen hebben mensen zomaar je server IP en al toegang to diezelfde server...

[Reactie gewijzigd door kritischelezer op 10 augustus 2016 21:13]

Cloudflare wordt gebruikt tegen DDoS-aanvullen en niet om je server-ip te maskeren. Als je een virtuele server afneemt krijg je overigens bij vrijwel alle providers gewoon een publiek ip-adres als ware het een fysieke server in een colorack, je deelt alleen de hardware met andere virtuele servers. Normaal gesproken zijn de VM's strikt gescheiden containers en is toegang tot data van een andere VM uit den boze, daarom is deze hack ook zo high-profile.

Cloudflare kent natuurlijk veel meer opties dan alleen DDos bescherming, zoals filteren van kwaardaardige instructies. Overigens dien je voor de echte bescherming te betalen. De gratis versie geeft juist bescherming tegen het aflezen van server IP, waardoor je niet aangevallen kan worden op server level (denk aan 0 days exploits op de laag van het besturingssysteem), dan biedt virtualisatie geen enkele bescherming en onderstreept het mijn betoog om nooit kritieke websites te draaien op een virtuele omgeving die gedeeld worden met derden. Alleen virtualiseren op (eigen) dedicated server is dan prima, mits de server niet vindbaar is op internet, dus bijvoorbeeld door cloudflare te gebruiken of een andere "voordeur".

Ik gebruik cloudflare zelf naar alle tevredenheid, al kent het wat performance problemen naar mijn Duitse bezoekers op dit moment .

https://blog.cloudflare.c...on-protecting-the-origin/ om meer te lezen over het verbergen en waarom.

De gratis versie geeft juist bescherming tegen het aflezen van server IP, waardoor je niet aangevallen kan worden op server level (denk aan 0 days exploits op de laag van het besturingssysteem), dan biedt virtualisatie geen enkele bescherming en onderstreept het mijn betoog om nooit kritieke websites te draaien op een virtuele omgeving die gedeeld worden met derden.

Virtualisatie gebruik je om kosten te besparen en hardware efficiënter in te zetten en niet voor beveiliging. Ik snap dus niet helemaal welke kant je op wilt met je betoog.

Het verhaal van Cloudflare is duidelijk, maar je wilt vooral het IP van je server verbergen om te voorkomen dat een DDoS-aanval wordt gedaan door rechtstreeks naar je server te connecten in plaats van via CloudFlare (die zo'n aanval makkelijk af kan slaan). Maar dat gaat op voor alle soorten servers, gevirtualiseerd of niet.

Ik begon met de bewering dat een kritieke website niet op een virtuele omgeving moet draaien, waar ook andere gebruikers toegang toe hebben. Hierop reageerde "the_shadow", dat ik onder een steen heb gelegen.

Dus daarom begon ik uit te leggen waarom ik vind dat een virtuele omgeving op een eigen server moet draaien en niet op een gedeelde server met anderen, indien er een kritieke website op draait.

Op het moment dat een server gedeeld wordt met derden, is de server dus bekend op het internet, ik gaf aan dat door bijvoorbeeld cloudflare te gebruiken, de server niet zichtbaar is, waardoor het minder vatbaar is voor aanvallen op server nivo. En correct, dit geld voor elke server, gevirtualiseerd of niet. Overigens heeft Cloudflare ook haar beperkingen, of zet iemand 5 seconden "in de wacht" om vervolgens deze door te sturen naar de echte website.

Volgens mij moeten ze zelfs beide onder dezelfde user draaien omdat de VM-processen van een beetje OS anders geen permissies krijgen om aan elkaars geheugen te komen.

Trouwens jammer dat ik niets lees over of deze methode al succesvol is gebruikt, bij welke VM-software dit van toepassing is en op welk 'beveiligings-level' dit gedaan moet worden (moet je al 'binnen' zijn of is het echt een exploit voor online mensen?)

[Reactie gewijzigd door blorf op 10 augustus 2016 23:30]

Je moet zelf een VM kunnen draaien (of software draaien binnen een VM in ieder geval) die een fysieke host deelt met de VM die je wilt compromitteren. De hack draait er om dat 2 VM's hetzelfde stuk geheugen delen (deduplicatie) en omdat de controle door de memory controller niet goed genoeg wordt uitgevoerd kan de ene VM (onterecht) geheugen manipuleren/uitlezen van de andere VM.

Ok, maar dan moet het virtualisatie-programma volgens mij dus ook root-permissies en directe hardwaretoegang hebben, oftewel op systeem-level geinstalleerd zijn als een soort verlengstuk van het OS. Ik gebruik regelmatig Qemu of Virtualbox op user-level en het lijkt me stug dat instances daarvan aan elkaars process-space kunnen komen, zeker als ze als verschillende users draaien.

Draait VirtualBox niet als een service?

Sowieso draait de hostsoftware in bijvoorbeeld een VMware ESXi of KVM-host als root en is het aan de virtualisatielaag om de VM's te scheiden.

Ben ik de enige die van de afkorting (FFS) ook iets anders maakt?