'AMD Epyc-encryptie voor virtuele machines is te omzeilen'

Onderzoekers van Fraunhofer Aisec hebben een methode ontwikkeld om de Secure Encrypted Virtualization-beveiliging van AMD's Epyc-processors te omzeilen. Zo kunnen ze gegevens onttrekken aan het ram van een virtuele machine.

De onderzoekers hebben hun aanval SEVered genoemd en claimen dat ze via een kwaadaardige hypervisor de volledige inhoud van het werkgeheugen van een virtuele machine in plaintext kunnen extraheren. Daartoe omzeilen ze de hardwarematige Secure Encrypted Virtualization, of SEV, van AMD's Epyc-processors voor datacentersystemen.

De bedoeling van SEV is dat virtuele machines in ram dankzij versleuteling beschermd zijn tegen toegang van buitenaf, waaronder via hypervisors. Elke individuele virtuele machine krijgt zijn eigen id voor geheugenruimte toegewezen, die gekoppeld is aan een cryptografische sleutel die wordt opgeslagen in de AMD Secure Processor. Die sleutel wordt gebruikt voor de versleuteling en het decoderen van de gegevens van de virtuele machine.

De methode van AMD ontbeert volgens de onderzoekers voldoende integriteitsbescherming en een deel van geheugenmapping wordt verzorgd door de hypervisor. "Dit stelt ons in staat de geheugenlay-out van de virtuele machine in de hypervisor aan te passen", schrijven de onderzoekers. Ze kunnen daardoor een dienst in de virtuele machine, zoals een webserver, willekeurige blokken van virtueel geheugen in plaintext van buitenaf laten opvragen. Door dit herhaaldelijk te doen, en de pages opnieuw te mappen, kunnen ze het hele geheugen van een virtuele machine opvragen.

De Fraunhofer-onderzoekers demonstreerden hun methode op een systeem met een AMD Epyc 7251-processor, dat Debian met daarop de Apache-webserver en OpenSSH in afzonderlijke virtuele machines draaide. Ze wisten met de SEVered-aanval 2GB aan de virtuele machine te onttrekken. Volgens de onderzoekers kan AMD zich tegen de aanval weren door de integriteitsbescherming te verbeteren, wat met hoge kosten gepaard gaat. Een goedkopere, maar minder veilige oplossing zou zijn om hashes van pages te combineren.

Reacties (69)

[Squee]

Wat een interessante exploit! Ik heb net even snel door de paper heen gescanned, en ze hebben wel een leuke en interessante manier gevonden om SEV te omzeilen. Laat ik het eens proberen wat versimpeld uit te leggen (uitgaande van Type-1 virtualisatie), maar eerst wat achtergrond over virtualisatie en adres vertaling:

Intro virtualisatie/adres vertaling

Ten eerste; dit gaat over (server) systemen die met een virtualisatie laag draaien; met andere woorden, een of meerdere besturingssystemen draaien elk in hun eigen virtuele machine op dezelfde fysieke machine, net alsof ze onafhankelijke computers zijn. Deze techniek wordt bijna overal in datacenters en in de cloud toegepast omdat je veel oude services kan consolideren op grote multi-core machines, en je veel flexibeler en efficienter bent in het gebruiken van je hardware. Om deze virtuele machines te beheren draait er een Hypervisor die de fysieke machine opsplitst en deelt tussen de virtuele machines die hun eigen besturingssysteem draaien.

Op een computer zonder virtualisatie laag doet het besturingssysteem ook aan een vorm van virtualisatie; elk programma, oftwel proces, dat draait heeft zijn eigen stuk geheugen toegewezen en zijn eigen geheugen adressen. Een besturingssysteem doet dit door virtuele adressen aan te maken en de processor te programmeren zodat deze automatisch vertaald worden naar de fysieke locaties in het geheugen. Deze Virtual Addess (VA) to Physical Address (PA) vertaling wordt gedaan door de Memory Management Unit in je processor, oftewel MMU. Het besturingssysteem heeft voor elk proces een tabel (de page table - al is het op de meeste processoren een boom-structuur) die de vertaling van adressen bepaald, en de Translation Lookaside Buffer (TLB) is een cache die de meest recente vertalingen bijhoudt zodat ze niet steeds opnieuw opgezocht hoeven worden. Doordat elk proces zijn eigen VA's heeft kan je niet zomaar bij het geheugen van een ander proces.

Wil je nu het bovenstaande model virtualiseren en meerdere onafhankelijke machines op een enkele server kunnen draaien, dan zal je moeten voorkomen dat de gebruikte PA's van de onderliggende besturingssystemen niet overlappen, en je zal ook je fysieke geheugen moeten partitioneren. Dit is een van de taken van de Hypervisor (HV), en dat doet deze door een 2e laag adres vertaling te introduceren. Deze translatie zal de door een guest besturingssysteem geziene PA's vertalen naar werkelijk fysieke geheugen locaties. Vandaar dat je in het diagram bij dit artikel de GVA en GPA regios ziet; de Guest Virtual Addresses - de virtuele adressen gezien door een proces wat binnen een virtuele machine draait, en de Guest Physical Address - de adressen die het besturingssysteem binnen de virtuele machine beschouwt als zijn fysieke adressen, maar die door de HV laag nog (onzichtbaar voor het besturingssysteem) normaals vertaald worden.

Wat is SEV?

In Secure Encrypted Virtualization kan een guest besturingssysteem zijn Guest Physical Address space versleutelen. Dit heeft enkele voordelen; mocht een andere guest in een virtuele machine toegang verkrijgen tot data via Hypervisor, dan kan deze niet zomaar het geheugen uitlezen van elke willekeurige ander virtuele machine omdat hij daar niet de juiste encryptie sleutel voor heeft. Het idee was ook dat een kwaadwillende Hypervisor zelf niet zomaar de data kan lezen van een virtuele machine, wat vooral in Cloud omgevingen interessant is waar je je virtuele machine draait op hardware van iemand anders, die je hoopt te kunnen vertrouwen.

Maar hoe werkt die exploit nou?

De exploit bestaat uit twee delen, en vereist dat de Hypervisor of kwaadwillend is, of op zijn minst door een andere exploit arbitraire code kan uitvoeren. Het gaat uit van een situatie waar er een bepaalde dienst in een virtuele machine draait die door de aanvaller zonder probleem benaderd kan worden, bijvoorbeeld een webserver.

Het eerste wat de aanvaller doet is een bepaald soort request naar de virtuele machine sturen, in het webserver geval bijvoorbeeld het downloaden van een bepaalde pagina of van een specifiek bestand. Dit bestand zal dan door de webserver uit het geheugen geladen worden en terug gestuurd (veel bestanden zullen in het geheugen gecached worden). De kwaadwillende Hypervisor moet dan de 2e niveau adres vertaling voor deze virtuele machine tijdelijk ongeldig maken, en zal dan verzoeken ontvangen om de vertaling te genereren wanneer de virtuele machine dit GPA probeert te benaderen. Door dit veelvuldig te doen kan de kwaadaardige HV er achter komen welke GPA adres regios overeen komen met de locatie van het bestand wat wordt opgevraagd in de requests naar de webserver.

Nu komt stap twee; aangezien de HV controle heeft over alle geheugen locaties die een guest heeft in zijn GPA regio, verandert de HV nu een van de adres mappings naar het bestand naar een arbitrair ander fysiek adres wat overeen komt met een ander geldig adres in de GPA regio. Dit is compleet onzichtbaar voor het besturingssysteem in de virtuele machine; in feite maakt de HV het geheugen nu corrupt, maar wanneer je wederom een request stuurt naar de webserver zal deze in plaats van de correcte inhoud van het bestand nu een ander deel van het fysieke geheugen van die virtuele machine verzenden, zelfs een deel waar het webserver proces normaal helemaal niet bij zou moeten kunnen. Aangezien het geheugen nog steeds wordt gelezen door de virtuele machine zelf, zal dit gewoon leesbaar zijn omdat het de juiste encryptie sleutels geinstalleerd heeft.

Maakt dat SEV dan waardeloos?

Nee, zeker niet, maar het biedt duidelijk geen bescherming tegen dit soort kwaadaardige Hypervisors. Deze exploit vereist dat er op Hypervisor niveau arbitraire code uitgevoerd moet kunnen worden, of dat er een malafide HV geinstalleerd wordt.

Ten eerste geeft SEV nog steeds wel bescherming tegen het lekken van data uit een virtuele machine naar een ander virtuele machine, mocht er een datalek via de Hypervisor zijn; zoals bijvoorbeeld de recente Spectre en Meltdown exploits. Dan zal je nog steeds versleutelde data lezen, en daar heb je als het goed is weinig aan. Ten tweede, op precies dezelfde manier ben je ook beschermd tegen de recente Rowhammer aanvallen; omdat je niet meer weet wat/hoe de fysieke bits opgeslagen worden in je geheugen, ze zijn immers versleuteld, kan je niet zomaar een bit-flip forceren met het gewenste resultaat. Nou zal een EPYC server systeem ook vaak ECC geheugen gebruiken, wat voor zover ik weet op dit moment ook nog steeds niet vatbaar is voor Rowhammer aanvallen (behalve corruptie/denial of service dan).

[hooibergje]

Processors zijn zo enorm ingewikkeld! Complete mega-steden van silicium op een paar vierkante centimeter. Nu er zo veel ophef is geweest rond Meltdown en Spectre is gebleken dat het erg loont om een foutje aan het licht te brengen. Ik vermoed dat er nog flink wat meer boven water zal gaan komen, als elk steegje en straatje in de processorstad wordt uitgekamd.

[batjes]

Waar niets mis mee is. Die processors hebben een boel legacy uit een tijdperk waar security niet van belang was (alles in software land tot en met het XP tijdperk voldeed hier eigenlijk aan, hardwareland loopt een paar jaar achter).

Veel van die legacy shit hebben we de afgelopen 20 jaar hard op doorgeborduurd, en we hebben eigenlijk nooit met terugwerkende kracht al die mogelijke security exploits uitgepluist. Het is in mijn ogen juist prachtig dat we de laatste decenia langzaam stappen hebben gezet richting een veilige omgeving.

Linux is lang voorloper geweest en MS is echt mee gaan doen vanaf Vista. Google ook pas sinds een paar Android releases geleden en Apple nam security in eerste instantie ook alles behalve serieus.

De afgelopen 10 jaar is security langzaam prioriteit numero uno geworden in software en hardware development land. Dit process is zeker 30 jaar bezig geweest en nu eindelijk pas beginnen we de echt serieuse (en complexe) exploits te vinden... Sommige hiervan die dus al sinds de jaren 90 bestaan.

Als grote bedrijven met veel kennis en een groot budget al enorme security exploits in hun designs hebben zitten (En AMD neemt security bv echt wel serieus)... bedenk je eens hoe lek je moederbord is, je NIC en weet ik het allemaal wat.

Security is sinds een jaar of wat echt "helemaal in", en dat is helemaal niet erg. Hoe meer hype, hoe beter voor ons. Want reken maar dat veel van die exploits die nu langzaam naar buiten druppelen, bij de AIVDs en CIA's van de wereld al lang en breed bekend waren.

[Ventieldopje]

Bij AMD/Intel is de concurrentie op gebied van snelheid moordend. Als Intel de keus maakt om veiligheid voorop te stellen dan gaat dit ten koste van de snelheid en liggen ze achter op AMD. Uiteraard zijn ze dan bang dat dit marktaandeel gaat kosten omdat de gewone consument geen idee heeft (en de pro’s van dit soort lekken vaak ook niet totdat het uitlekt).

Dus tenzij iemand flinke testikelen toont en dat statement durft te maken dat veiligheid voorop staat zal er niet zo veel gebeuren aan preventie als de snelheid daar te veel onder lijd.

Bij NICs en enterprise netwerk spul is dit een stuk minder lijkt mij. Daar is veiligheid een speerpunt. Bij NICs heb je een bepaalde snelheid te halen en heb je hooguit iets krachtigere hardware nodig voor de extra veiligheidsmaatregelen. Hier dus puur concurrentie op veiligheid

[Reactie gewijzigd door Ventieldopje op 25 juli 2024 05:12]

[Aetje]

Waarom niet een keuze bieden?
- Een "Fast" processor model, welke geschikt is voor geisoleerde processen die veel kracht vereisen en waarop alleen vertrouwde code gedraaid wordt.
- Een "Secure" processor die niet aan speculative execution doet. Wat trager, maar je bent beschermd tegen dergelijke lekken.

Dat "Secure" model is simpelweg nog niet ontwikkeld omdat er geen markt voor was. En de nadruk kan op "was" gelegd worden hier...

[EraYaN]

Eigenlijk omdat het gewoon allebei moet. Consumenten kunen die keuze helemaal niet maken, al helemaal niet voor zich zelf.

En de aanname "waarop alleen vertrouwde code gedraaid wordt." gaat nooit op hebben we wel gezien.

[batjes]

Daarom is die hype niet erg.

Security is echt belangrijk, men onderschat dat echt enorm. En we lopen echt achter, zo ontzettend veel legacy shit die nu aan het internet hangt en waar de tech al decenia op voorborduurt, die voor veel zaken uiterst belangrijk is, welke allemaal zo'n beetje niet onderdoen voor de beste Zwitserse gatenkaas. De vorige keer toen we als IT wereld een hype de media in werkte (Y2K), was het ook broodnodig om het zo te hypen, anders zou het onmogelijk zijn geweest die luie zakken van management en hoger die IT als een kostenpost zien, over te halen de shit in orde te maken.

Als nu de pleuris uitbreekt zoals begin vorige eeuw (of de gehele geschiedenis van de mensheid daarvoor), dan ga je blij zijn met die focus op security en de hype in de media.

[GekkePrutser]

En dit is nog wel een groter probleem. Bij Y2K was het probleem precies bekend (de mogelijke effecten niet allemaal, maar de oorzaak wel).

Met security weet je nooit wat er morgen weer gevonden gaat worden.

[Rataplan_]

en claimen dat ze via een kwaadaardige hypervisor...
Dat houdt dus in dat je in eerste instantie al fysieke of root toegang op de host moest hebben om een hypervisor te 'manipuleren' dit toe te staan? In dat geval zie ik nog niet meteen een heel groot gevaar hierin?

[batjes]

Omdat je als hypervisor admin/root niet zo maar toegang hebt tot de data binnen de VM's.

Die VM's gebruiken allemaal hun eigen encryptie keys om hun stukjes geheugen te encrypten. Deze slaan die encryptie keys dus op in dat secure gedeelte van de CPU. Welke je nu als root dus kan uitlezen remappen, en zo dat geheugen kan decrypten.

Zodra iemand root op een hypervisor omgeving is, heb je ook wel andere problemen die je aandacht nodig hebben. Maar aan de andere kant, 1 van je VM's hoeft maar een exploit te vinden om root privileges te bemachtigen op hypervisor niveau en je hebt een uiterst groot probleem.

[Reactie gewijzigd door batjes op 25 juli 2024 05:12]

[Verwijderd]

Volgens mij is je conclusie niet correct. De keys lijken niet uitgelezen te worden uit het secure gedeelte. De key's kunnen dit gedeelte niet uit. De aanval lijkt gebaseerd te zijn op het re-mappen van het geheugen door met flags te spelen.

De gelinkte PDF beschrijft dit mechanisme. https://arxiv.org/pdf/1805.09604.pdf

[batjes]

Ah thanks, ik heb er niet op ingedoken en ging van het Tweakers artikel uit. Bedankt voor de opheldering, aangepast

[Olaf van der Spek]

In dat geval zie ik nog niet meteen een heel groot gevaar hierin?

Deze feature is toch specifiek ontworpen om dit tegen te gaan? Zullen ze niet voor niks gedaan hebben..

[watercoolertje]

Niet voor niks, maar dat zegt weinig over de grote van het gevaar

Tientallen jaren zonder was ook geen groot probleem, dus het zal wel mee vallen.

Kwalijker vind ik dat dit een usp is die niet nagekomen kan worden.

[Sandwalker]

Ik heb nog geen reactie van AMD hierop gezien, dus ik weet ook niet wat ze gaan doen. De uitspraak van Fraunhofer hoe dit op te lossen, behoeft niet alomvattend te zijn. Het is goed mogelijk dat AMD hiervoor iets anders kan verzinnen, of niet natuurlijk. Het zou wel prettig zijn als AMD het voor elkaar krijgt om op een robuste manier deze encryptie te implementeren.

[tweaknico]

Een VMWare aangepast op aanwijzing van NSA oid tbv. bedrijfs spionage?...
Kwaadaardig kan in andere vormen dan je denkt...

Ze hebben ook Cisco hardware gemodificeerd (ook zonder medeweten (volgens opgave) van Cisco).

[the_stickie]

Mja, maar de NSA heeft daar dan nog steeds niks aan als ze niet aan de hypervisor kunnen. Bovendien zijn er eenvoudigere manieren om aan data te komen als je er vanuit gaat dat ze met aangepaste, kwaadaardige OS'en hun doel willen bereiken.
Volgens mij is de kwetsbaarheid vooral een probleem voor cloudservices, waar de infrastructuur partij niet dezelfden zijn dan diegenen die de VM beheren.

[MiesvanderLippe]

Stel je host je VM bij een derde dan zijn er wel een paar situaties denkbaar waarbij ik de zekerheid dat iemand niet bij mijn data kan waardeer.

1) Kwaadaardige beheerder. Stel iemand bij bijvoorbeeld Azure kan bij een host dan kan deze persoon niet bij de inhoud van de VM's.
2) Overheid. Stel er is een inval in het serverpark waar jouw VM draait dan is het fijn als het alsnog onmogelijk is om er data uit te halen.
3) Hacks. Stel de host wordt gehackt dan is het van belang dat er nog andere beveiligingen zijn.

[supersnathan94]

Volgens mij zul je dan zelf al op applicatie niveau ook al maatregelen moeten treffen met bijvoorbeeld encryptie van persistente data. Anders gaat dit bijvoorbeeld niet heel veel helpen aangezien men dan alleen niet bij het spul in memory kan.

[Reactie gewijzigd door supersnathan94 op 25 juli 2024 05:12]

[R4gnax]

Volgens mij zul je dan zelf al op applicatie niveau ook al maatregelen moeten treffen met bijvoorbeeld encryptie van persistente data. Anders gaat dit bijvoorbeeld niet heel veel helpen aangezien men dan alleen niet bij het spul in memory kan.

Disk-storage kan al langer versleuteld afgehandeld worden op OS niveau. Het is juist het 'levende' werk-geheugen waar AMD's encryptie systeem een nog overgebleven gat vult.

[supersnathan94]

True maar dat zit dan wel in de VM zodat er vanuit onderliggende lagen niet bijgekomen kan worden. Dat bedoel ik met vanuit de applicatie. Als de hypervisor het gaat doen heb je daar immers ook niets aan want een kwaadaardige hypervisor kan er dan alsnog in.

[klakkie.57th]

Of een partij die deze mogelijkheden heeft cloud-providers te dwingen om dit te doen.

Maw je data-at-rest mag dan nog geencrymteerd zijn met een hyok scenario, het haalt gewoon niets uit.

[InsanelyHack]

Wat dacht je van de VMS die bij Cloud providers draaien en meer dwang van een overheid die VMS wil uitlezen?

[servicedb]

Het punt is dat AMD hiermee een extra beveiligingslaag wilt hebben waardoor je zeker weet dat je cloud provider bijvoorbeeld niet bij je data kan. Als je dit combineert met encryptie op de harde schijf dan heb je een bijzonder goede beveiliging van je data op een laag niveau. Natuurlijk zorgd dit er niet voor dat de overige software op je webserver veiliger is, maar je weet in ieder geval we waar je data is. Dat is ook een van de zaken waar AMD aandacht aan heeft gegeven bij de lancering, al duurde het even voordat het daadwerkelijk beschikbaar was.

Daarbij komt natuurlijk dat als de hypervisor al is “gehacked” dat je vms in theorie nog steeds veilig zouden moeten zijn. Ben het eens dat als het zover is dat er al iets goed fout gaat, maar die encryptie kan een hoop problemen voorkomen.

Je kan een eigen fysieke server nemen om extra veilig te draaien, maar als je een vm hetzelfde kan met dezelfde beveiliging dan zijn er meer mogelijkheden en kan je verantwoorden dat je goed met je data om gaat.

[leuk_he]

Het is de eerste keer dat ik dit zie dat AMD deze feature heeft. Nam altijd aan dat als men root had op de hypervisor het game over was.

Maar dan vraag ik me meteen af:
-Hoe krijg je de keys uit de security processor als je naar een andere host moet? en als dat kan kan je heel de guest VM toch gewoon clonen naar een andere omgeving en daar gaan hacken op de guest

[XenoniaN]

Als je de VM even afsluit is er ook geen geheugen in gebruik waar dus ook geen encryptie meer over zit.

[Verwijderd]

Als jij een VM huurt in een cloud heb je normaal gesproken toch root op die machine? Ik heb ik het verleden voor m'n werk wel een aantal VM's moeten beheren in de Azure cloud, op al die machines had ik root. Dat is ook wel zo handig als ik iets op die machines wil installeren waar klanten wat aan hebben.

[Laurens-R]

root op de guest VM ja, geen root toegang tot de host/hypervisor (de machine waarop de VMs draaien).

Dus Rataplan_'s punt is valide; het is een vrij ingewikkelde exploit om uit te voeren omdat je eerst root toegang tot de host moet hebben.

[Reactie gewijzigd door Laurens-R op 25 juli 2024 05:12]

[Verwijderd]

Ah OK, dat had ik er zo gauw niet uitgehaald. Uiteraard had ik geen root op de fysieke machine.

[Verwijderd]

Op die vm wel, maar niet op de host van de vm

[Neko Koneko]

Volgens mij betekent het dat je root toegang moet hebben op de hypervisor, dus het host systeem, om dit te kunnen doen. Volgens mij heb je dus toegang nodig tot het host systeem en het cliënt systeem om dit te laten werken.

[terror538]

Root op een VM die in de cloud draait betekent nog niet dat je root op de ring0 host hebt!

Dat betekent dus dat je minstens fysieke toegang moet hebben tot de machine of met management netwerk vanaf waar het ring0 os bereikbaar is.
En dan om de hypervisor te vervangen zal zeer waarschijnlijk het systeem gereboot moeten worden; dus geenzins dingen die ondetecteerbaar zijn.

[procyon]

integriteitsbescherming te verbeteren, wat met hoge kosten gepaard gaat

Waarom is dat kostbaar? Omdat het hardwarematig zal moeten met een terugroepactie tot gevolg?

[Reactie gewijzigd door procyon op 25 juli 2024 05:12]

[Verwijderd]

The best solution seems to be to provide a full-featured
integrity and freshness protection of guest-pages additional to the
encryption, as realized in Intel SGX. However, this likely comes with
a high silicon cost to protect full VMs compared to SGX enclaves.
A low-cost efficient solution could be to securely combine the hash
of the page’s content with the guest-assigned GPA. This ensures
that pages can not easily be swapped by changing the GPA to HPA
mapping. Adding a nonce additionally ensures that an old page
for the GPA cannot be replayed into the guest by a malicious HV.

Ze bedoelen daar fabricage en performance kosten.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 05:12]

[MSalters]

Performance kosten. Moderne encryptie (vanaf ruwweg DES) is geoptimialiseerd voor digitale verwerking; een paar gates extra zijn de kosten niet op een miljard gates totaal. Alleen, élke geheugentoegang moet gedecodeerd worden (met SGX is het een grote uitzondering). Dat betekent dat die decryptie hard moet werken. Zelfs dat leidt niet tot een merkbaar verschil aan geheugen bandbreedte (kwestie van genoeg hardware), maar het heeft wel twee andere gevolgen: de latency van read access neemt toe (je moet wachten op de decryptie) en het kost wel allemaal energie.

[Verwijderd]

Nou, volgens de experts (ook wat ik al had geqoute overigens) is er wel een hoge kosten aan verbonden.

However, this likely comes with
a high silicon cost to protect full VMs compared to SGX enclaves.

Buiten dat om, ik zie je niet met "een paar gates" een volledig logisch eenheid in elkaar zetten. Latency en energie zijn ook nare symptomen inderdaad. Hoofdzaak is dat je een hoop meer silicium oppervlakte nodig hebt om het goed te doen (volgens de experts dan he).

[procyon]

Een dergelijke fix kan (moet) toch gewoon mee in de volgende revisie?
Lijkt mij business as usual. Of is dit zo'n ingrijpende verandering dat het 10% meer die size betekend?

[Verwijderd]

Dat is wat ze bedoelen te zeggen.

[Titan_Fox]

The best solution seems to be to provide a full-featured
integrity and freshness protection of guest-pages additional to the
encryption, as realized in Intel SGX.

Intel's SGX had recentelijk ook de nodige problemen op beveiligingsniveau. De techniek die zij gebruiken is daarom alles behalve zaligmakend :

nieuws: Intel gaat Spectre-lek in Software Guard eXtensions dichten

[rickboy333]

Het Xeon platform kan hier toch ook last van krijgen? Of kunnen deze zich wel weren tegen deze aanvallen?

[Astennu]

Xeon heeft volgens mij helemaal geen encryption die qua features vergelijkbaar is met SEV van AMD. Daar kunnen ze er al makkelijker bij komen.

[Reactie gewijzigd door Astennu op 25 juli 2024 05:12]

[Zer0]

Leuk om te roepen dat een Xeon het niet heeft, maar die hebben dat volgens mij gewoon ook.
https://lwn.net/Articles/686808/
https://eprint.iacr.org/2016/204.pdf
https://security.stackexc.../136993/intel-sgx-details

[Loggedinasroot]

Dit gaat om SGX vs SME(Secure Memory Encryption) volgens mij.
Terwijl het artikel over de SEV(Secure Encrypted Virtualization) gaat.

Volgens mij stond in de Epyc slides dat ze de enige waren die dit toen aanbieden. Maar kan het mis hebben.

[Astennu]

Ik heb mijn bewoording even wat aangepast.
Intel wel beveiligingen maar wat AMD doet ging op bepaalde punten verder dan wat Intel op dit moment kan.

[Verwijderd]

lijkt me beter dan helemaal niks.

[psycho202]

Bezit het Xeon platform wel over dit soort bescherming?

[Loggedinasroot]

Volgens mij heeft Xeon dit nog niet.

[Kalief]

Ze kunnen daardoor een dienst in de virtuele machine, zoals een webserver, willekeurige blokken van virtueel geheugen in plaintext van buitenaf laten opvragen.

Dit lijkt mij een cirkelredenering: ze hebben een aanpassing nodig om een stuk geheugen op te vragen die ze nodig hadden voor die aanpassing.

[Verwijderd]

Ik vraag mij af hoe jij dat leest, want ik lees geen cirkelredenatie. Ik lees dat ze een webserver (zoals apache) op een virtual machine gebruiken om data naar een request van buitenaf te sturen. In dit geval hebben ze een methode gevonden om het complete geheugen van de server waar de VM op draait uit te lezen en deze dus door te sturen naar de client die de request doet.

Oftewel, slecht nieuws als je in een cloud omgeving met meerdere tenants draait waar deze AMD chips gebruikt worden in de onderliggende server.

[Verwijderd]

Oftewel, slecht nieuws als je in een cloud omgeving met meerdere tenants draait waar deze AMD chips gebruikt worden in de onderliggende server.

Hoezo? dan moet je eerst al je eigen hypervisor aanpassen om dit mogelijk te maken, en dan nog is dit veiliger dan wat intel op dit moment bied. In de toekomst komt Intel nog wel eens een keer met SGX, maar dat duurt nog wel even.

De enige welke risico lopen, zijn klanten welke nu er niet meer blind op kunnen vertrouwen dat op een EPYC de VM veilig is. De veiligheid word gedegradeerd tot Intel niveau.
edit: twee typos

[Reactie gewijzigd door Verwijderd op 25 juli 2024 05:12]

[Verwijderd]

Blijkbaar stukje over kwaadaardige hypervisor gemist. Dit lijkt een beetje gezocht om headlines in de media te kunnen produceren.

[Olaf van der Spek]

Nee.. de aanpassing kan de hypervisor zelf doorvoeren.

[vinx77]

Twee vragen kwamen bij me op:

• In hoeverre kan Address space layout randomization een extra verdediging zijn?
• Werkt dit alleen bij een VM waar de data in geheugen redelijk stabiel is?

Omdat de laag eronder de VM aanvalt, is er weinig wat je kan doen. ASLR zal wel geen verdediging zijn, omdat het hele geheugen bekend is. Een snel veranderende VM zal alleen meer tijd kosten.

[MrMonkE]

Snap ik het goed dat dit is in tegenstelling tot de eerdere bugs niet echt iets dat kan worden uitgebuit zonder al toegang te hebben van 1 van de virtueele machines op dezelfde hypervisor?

[Twieka]

De reden waarom deze EPYC encryptie ten eerste is gebouwd, is juist omdat er veel Exploits zijn met betrekking tot escalatie vanuit guest naar host. Zie :
https://thenewstack.io/pr...s-patched-xen-hypervisor/
of
https://vuldb.com/?id.87169
en zo kan je nog wel een tijdje doorgaan.

Sommige interrupts moeten nog steeds door de Hypervisor afgehandeld worden, en daar zit juist de attack surface. AMD heeft dus een voorziening in hun processors gebouwd, waardoor zelfs als je uit de VM kan ontsnappen, je de andere VMs in de cloud bv. nog niet kan uitlezen. Met deze truuk van de Fraunhofer onderzoekers kan dit dus juist wel weer.. Dus in combinatie met privilege escalation een zeer kwadelijke zaak.

Overigens zou deze Secure Encrypted Virtualization beveiliging ook een verdediging kunnen zijn tegen niet te vertrouwen systeem admins, ala Edward Snowden, die toegang hebben tot de hypervisor.
Bovendien zijn sommige hypervisors open source, en kunnen kwaadwillenden ook daar exploits in bouwen.

[kuurtjes]

"De onderzoekers hebben hun aanval SEVered genoemd"

En hoe gaan we dit soort nutteloze benamingen noemen?

[418O2]

Ze zijn een stuk makkelijker te onthouden dan hun CVS codes

achtergrondartikel: reviews: Krack, Venom, Ghost en Shellshock: de zin en onzin van 'branded bugs'

[Reactie gewijzigd door 418O2 op 25 juli 2024 05:12]

[kuurtjes]

Nu nog wel ja. Binnekort gaan er zoveel zijn dat ze het jaartal erbij zetten SEVered (2018) en dan na nog meer namen steken ze er nummers bij en dan ben je weer terug bij CVE codes.