Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Intel gaat Spectre-lek in Software Guard eXtensions dichten

Onderzoekers hebben een Spectre-sidechannelaanval op Intels Software Guard Extensions beschreven waarmee het geheugen van beschermde SGX-enclaves uitgelezen kan worden. Intel komt met een patch voor de sdk.

De onderzoekers beschrijven hun aanval in een paper met de titel SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution en Intel verklaart tegen ZDNet dat op 16 maart een nieuwe SGX-toolkit met patch verschijnt. De sidechannelaanval maakt een einde aan de vertrouwelijkheid die SGX moet bieden en volgens de onderzoekers lijkt het erop dat elk programma dat gebruikmaakt van SGX-enclaves kwetsbaar is voor SgxPectre.

Software Guard Extensions is instructiecode voor recente Intel-processors die voor enclaves zorgt: afgeschermde delen van het geheugen voor gevoelige code, waar zelfs het besturingssysteem of hypervisors niet direct bij mogen. Met behulp van de SGX-sdk kunnen ontwikkelaars applicaties maken die code in de enclaves kunnen laten draaien.

De aanvallers ontdekten fouten in de implementatie van branche prediction, een eigenschap van alle moderne cpu's om de werking te versnellen: code van buiten de enclave bleek gebruikt te kunnen worden om de code binnen de enclave waar de branche prediction zich op richt, te manipuleren. Bovendien bleken veranderingen in de cachestaat te achterhalen te zijn, wat uit te buiten is voor een geslaagde aanval.

Om branch target injection-aanvallen zoals Spectre tegen te gaan heeft Intel microcode voor processors uitgebracht, met de technieken Indirect Branch Restricted Speculation, Single Thread Indirect Branch Predictors en Indirect Branch Predictor Barrier. De gaan ook SgxPectre-aanvallen tegen, maar applicaties die gebruikmaken van SGX gaan standaard niet na of de processor de laatste versie van de micocode draait. In theorie zou een aanvaller de patches van Intel kunnen terugdraaien om een SgxPectre-aanval te doen slagen.

De onderzoekers hebben een scanningtool uitgebracht om kwetsbare code in enclave-programma's te vinden. Ze zijn van plan om exploits op een later moment vrij te geven. Intel raadt ontwikkelaars aan de sdk-toolkit te gebruiken die 16 maart verschijnt en die applicaties bestand maakt tegen de beschreven aanval.

Door Olaf van Miltenburg

Nieuwscoördinator

05-03-2018 • 09:20

28 Linkedin Google+

Lees meer

Reacties (28)

Wijzig sortering
okee ik heb het hele filmpje gekeken. maar wat is hier nou het nut/gevaar van voor de normale huis, tuin en keuken gebruiker?

en kan ik deze code ook ergens downloaden zodat ik dit zelf kan doen (in beschermde (ouwe laptop) omgeving?
Gevaar voor de thuisgebruiker is er niet meteen, omdat SGX bij consumentensoftware bijna uitsluitend gebruikt wordt door DRM implementaties. Voor rechtenhouders of platformen als Netflix of Apple kan het dan weer wel een bedreiging zijn wanneer hun DRM implementaties kwetsbaar worden, zeker als dit slechts kan opgelost worden door een patch van het systeem van de eindgebruiker.
Onzichtbare code draaien op processoren van burgers, die het besturingssysteem niet kan aanpassen. Waar natuurlijk weer kwetsbaarheden in zitten. De overheid zou dit m.i. moeten verbieden. Reden te meer om categorisch tegen DRM te zijn.
Intel management vergeten?

Zit op moederbord ipv cpu en door spectre geweld uit oog verloren.

Meeste Intel systemen met intel chipset bevatten een veel groter risico dan spectre.
Dat ook, inderdaad. Mijn stelling geldt voor alle vergelijkbare manieren waarop burger geen controle meer hebben over hun eigen hardware.
Hebben ze nooit gehad.

Op je msx/c64 had jij ook niets te zeggen.

Alleen moest men wel fysiek langskomen om iets van je privacy te ontnemen.

En je 300baud modem werkte ook niet mee om je 75dpi scans van je foto van tape te stelen. Om maar te zwijgen dat iemand bandje moet terug spoelen en op play moest drukken.

[Reactie gewijzigd door totaalgeenhard op 5 maart 2018 23:05]

SGX code is niet onzichtbaar en de code moet weldegelijk door het besturingssysteem of een ander stuk software ingeladen worden. SGX heeft ook geen speciale mogelijkheden, het zorgt er enkel voor dat de interne werking van de SGX kernel niet geanalyseerd of gewijzigd kan worden door andere software op het systeem.

De eindgebruiker is bovendien volledig in staat om een systeem zonder SGX kernels te kiezen voor zijn of haar computer, of om SGX uit te schakelen in de BIOS van zijn moederbord, al verlies ja dan wel de mogelijkheid om bepaalde diensten te gebruiken.
Het blijft aanklooien als ik dit artikel zo lees. Bewijst tevens dat de echte oplossing enorm moeilijk en complex is of gaat worden. Wel een beetje verbazend dat intel nog niet veel verder is gekomen dan "dit".
Klopt, het echte probleem zit immers in de hardware, dus de basis van het probleem is niet op te lossen met een software-fix. Men zal de processor opnieuw moeten ontwerpen en moeten produceren. Dat duurt een tijd. En ook daarna blijven er natuurlijk enorm veel oude processoren in omloop...
Ergste is nog dat ze dit 15 jaar geleden al wisten.
Ergste is nog dat ze dit 15 jaar geleden al wisten.
Dat is volkomen onzin. Het probleem bestaat al heel lang (geen idee of het precies 15 jaar is), maar het is pas halverwege vorig jaar ontdekt.
Intel weet t al een tijdje, maar geen 15 jaar.
Dat is ook de redenen dat zo wel intel als AMD worden aangeklaagd, door het stil houden.
True, het probleem bestaat al 15 jaar. Intel weet t niet al 15 jaar.
Het is maar hoe je dit bekijkt. 15 jaar geleden (eigenlijk al veel langer) was het theoretisch mogelijk om de kwetsbaarheid uit te buiten, maar pas nu is men zo ver om dat in de praktijk te kunnen doen.

In theorie zijn er sowieso enorm veel kwetsbaarheden op elk denkbaar technisch en software vlak in de IT.
Aanklooien. Het is waarschijnlijk een van de grootste vulnerabilities (backdoors) ooit. Grove nalatigheid kan in dit geval ook wel gebruikt worden - zeker omdat men processoren die kwetsbaar zijn gewoon blijven produceren. Men downplayed het door te zeggen dat deze 'kwetsbaarheden' moeilijk toe te te passen zijn.

Wat mij zelf opvalt is hoe weinig aandacht er eigenlijk in de pers over is. Dan bedoel ik de massa media.

[Reactie gewijzigd door litebyte op 5 maart 2018 11:08]

Wat mij zelf opvalt is hoe weinig aandacht er eigenlijk in de pers over is. Dan bedoel ik de massa media
Natúúrlijk is er weinig aandacht !

Het is een (voor de gemiddelde lezer) saai, ingewikkeld en vaag verhaal wat er verteld moet worden. Bovendien is de conclusie steeds dat het een hardware probleem is en er eigenlijk geen andere oplossing is dan alle oude hardware te vervangen. Geen (gemiddelde) lezer die op dat bericht zit te wachten. Dus geen journalist die er over schrijft.

Een lezer denkt: "Hé, er is een probleem ! Wat is de oplossing ? Oh, die is er niet. Dan kan ik er ook niks mee. *einde aandacht* "

[Reactie gewijzigd door T-men op 5 maart 2018 11:18]

Precies dit, ik beschouw mezelf niet als gemiddelde lezer, maar uitleg is dodelijk saai, en geen oplossing.
Oh er is wel een oplossing, er zijn er zelfs 3...
1) Korte termijn: Haal systemen waarin CPU's zitten zonder problemen terug (van de vuilstort?)

2) Lange termijn: Stop alle productie per direct, en ontwerp nieuwe chipsets ... over een jaar of 4 hebben we dan nieuwe systemen.

3): min of meer reeel:
gebruik CPU;s die wel veilig zijn zoals bv. Itanium, ARM van een vorige generatie..
Van al deze systemen moet vrij snel weer een lijn in te richten zijn (Itanium is tot vorig jaar Juni geproduceerd geweest.).
1) Korte termijn: Haal systemen waarin CPU's zitten zonder problemen terug (van de vuilstort?)
Elke CPU die oud genoeg is om deze problemen niet te hebben is ook meteen veel te oud om in moderne systemen te passen (andere socket) en komt nog niet in de buurt van de rekenkracht die nodig is voor het draaien van moderne toepassingen. Deze oplossing is volkomen onzinnig; dit gaat nooit werken.
2) Lange termijn: Stop alle productie per direct, en ontwerp nieuwe chipsets ... over een jaar of 4 hebben we dan nieuwe systemen.
Niet per direct, pas zodra de nieuwe ontwerpen beschikbaar zijn. Een paar maanden lang (in grote dele van de markt) geen enkele CPU verkopen is geen realistische oplossing. Ja, dat betekent dat we tijdelijk chips kopen waarvan we weten dat ze kwetsbaar zijn. Niets aan te doen.

Over een aantal jaar is een groot aantal van de consumentensystemen vervangen. Maar zelfs daar lang niet allemaal; computers gaan tegenwoordig een stuk langer mee dan tien jaar geleden. Voor industriële systemen geldt dit al helemaal niet; kijk maar onder elk artikel uit de categorie "MS beëindigt support voor Windows XP / Vista / 7 / 8", daar komen altijd reacties onder van mensen die gaan "opbieden" welke oude meuk er bij hen op het het werk nog gebruikt wordt. Het begint vaak met Windows 95, dan iemand die nog ergens Windows 3.11 draait en tot slot kent iemand een voorbeeld van een machine die tot op de dag van vandaag op MS-DOS loopt (al heb je dan, in het kader van dit artikel, het voordeel dat die MS-DOS bak in elk geval niet kwetsbaar is voor Meltdown en Spectre :+ ).
3): min of meer reeel: gebruik CPU;s die wel veilig zijn zoals bv. Itanium, ARM van een vorige generatie.. Van al deze systemen moet vrij snel weer een lijn in te richten zijn
Je weet dat Itanium is afgeschaft omdat zo ongeveer niemand het gebruikte? Er was nauwelijks software die erop draaide. En zelfs als alle software die je nodig hebt beschikbaar is, dan nog zul je grondig willen testen of alles ook echt naar behoren werkt. Die controles zullen (voor een compleet nieuw platform) behoorlijk wat tijd vreten.

Daarnaast, wie zegt dat Itanium veilig is? *) Die dingen hebben ook speculative execution en out-of-order execution. Toegegeven, de OoO is compleet verschillend (dependencies worden gemarkeerd door de compiler) van wat x86 en x86-64 doen (depenencies worden on-the-fly uitgezocht door de CPU), maar zonder in de details te duiken durf ik niet te zeggen of het moeilijker is, of echt volledig onmogelijk om deze aanvallen op Itanium uit te voeren.

*) Ik kan zo gauw geen goede bron vinden. Hier wordt wel geclaimed dat Itanium niet vatbaar is, maar de halve pagina zit x86 af te zeiken, waardoor ik twijfel aan de objectiviteit van de auteur, en de argumenten zelf zijn nogal zwak.
mbt. Meltdown... dat is een execute voordat de privilege check was.
Itanium heeft geen speculative instructions AFAICT. ook geen out of order...
(Itanium verwerkt in parallel, maar EXPLICIET, niet impliciet de archtectuur heet dan ook EPIC)

En het 64bit voordeel dat er was werd door AMD64 mode snel minder een voordeel.
Daarnaast moesten alle compilerbouwers opnieuw leren omgaan met een heel andere architectuur.
De compilerbouwers moesten het speculatief uitvoeren in hunn streams gaan bouwen.
En de Itanium is vrij onvergeeflijk..., er kan geen instructie herstart worden zonder dat het heel duur wordt. Alignment is een issue (was ook op de 68000 zo trouwens).
Doordat feitelijk alles opnieuw uitgevonden moest worden was er meer tijd nodig om het platform van de grond te krijgen, en die was er eerst wel maar na de komst van de AMD64 niet echt meer.
Die was eenvoudiger in bestaande compilers te stoppen en de CPU was relatief goedkoper...

En ja "tegelijkertijd"wordt (Zolang het mogelijk is) gelijktijdig aan verschillende delen van een stuk code gewerkt. ---
for (i=0; i<j; i++) { ...... }
Zolang het kan zullen in een loop bv. voor index i=0 en i=1 en i=2 gelijtijdig uitgerekend worden en als dan blijkt dat j == 2 dan zal de uitkomst van het pad i==2 niet meer gebruikt worden.
Het heeft alleen geen neven effecten dit gebeurd dus altijd.
(meestal gebeurd het een en ander in 3 voud).

Zowel HPE, als VSI hebben dat in een statement aan hun klanten gemeld....
de HPE versie kon ik niet vinden, hier de VSI brief: https://www.vmssoftware.c...2018_Meltdown_Spectre.pdf
Itanium heeft geen speculative instructions AFAICT.
Alle instructies waarvan de naam eindigt op ".s", voorbeeld. Doordat het expliciet is (de programmeur / compiler zegt "ik wil dat je dit speculatief uitvoert" in plaats van dat de processor besluit "ik heb toch niets anders te doen, laat ik wat speculatief werk verzetten") zou het minder vatbaar moeten zijn, maar keihard zeggen "het is per definitie niet vatbaar" lijkt mij een brug te ver.
ook geen out of order
Ja en nee, hangt er vanaf hoe je er tegenaan kijkt. Als je op x86 zegt:
mov eax, [ebp]
add eax, 42
mov ebx, 37
Dan zal de tweede mov (zeer waarschijnlijk) voor de add worden uitgevoerd, dat is een duidelijk voorbeeld van OoO.

Op Itanium kun je niet simpelweg zeggen:
ld r33 = [r32]
add r32 = r32, 42
ld r34 = 37
Dit is waarschijnlijk geen geldige syntax; ik heb nooit echt met Itanium gewerkt.
Je moet expliciet (inderdaad, de "E" van "EPIC") aangeven welke dependencies er zijn tussen de instructies, door "bundles" van instructies te maken die allemaal onafhankelijk van elkaar zijn. In bovenstaand voorbeeld zul je dus twee bundels nodig hebben, omdat de eerste en tweede instructie wel degelijk van elkaar afhankelijk zijn. Daarbij zou je ervoor kunnen kiezen om zelf de tweede en derde instructie om te draaien, zodat beide loads bij elkaar in een instruction bundle kunnen en de add in zijn eigen bundle. Binnen de bundle mag een Itanium CPU de instructies in elke willekeurige volgorde uitvoeren. Het lijkt mij zeker mogelijk dat hierdoor een soortgelijke aanval ook op Itanium kan werken.
Zowel HPE, als VSI hebben dat in een statement aan hun klanten gemeld....
de HPE versie kon ik niet vinden, hier de VSI brief: https://www.vmssoftware.c...2018_Meltdown_Spectre.pdf
Die had ik nog niet gezien, bedankt voor de link! Heb nog een keer opnieuw gezocht en alsnog een mededeling van Intel zelf gevonden:
Are Intel® Itanium® processors affected?
No. Intel® Itanium® processors are not affected.
Dat klinkt alsof ze er zelf in elk geval wel van overtuigd zijn. Ik vind het wel jammer dat ik nog steeds geen onderbouwing heb kunnen vinden waarom dat per definitie zo is; begrijpen waarom het zo is heeft toch net wat meer overtuigingskracht dan alleen maar een simpel "het is zo".

[Reactie gewijzigd door robvanwijk op 5 maart 2018 20:23]

Bij EPIC is het belangrijkste verschil meet voorgaande systemen, dat de compiler al moet bepalen wat de meest efficiente volgorde van instructies inclusief de overhead van memory fetches etc.

Bij Itanium worden er altijd bundels van 3 instructies uitgevoerd (evt. een NOP als placeholder).
omdat niet de hardware op basis van cache informatie een ander besluit neemt is er geen verschil in timing of er wel of niet iets in een cache zit.
Door een bekend stukje code uit te voeren (paar 1000 keer) met info in cache en nogmaals met chaches leeg kun je bepalen of er een bepaalde waarde in een cache stond.
Bij Itanium zal er geen verschil optreden omdat de cache geen invloed op instructie volgorde / timing heeft in die mate dat dit goed zichtbaar zal zijn.
Dat is voor mij en wellicht 90% van de pc gebruikers geen oplossing.. succes met het uitvoeren ervan.. :)
De downplay is anders wel feitelijk correct. Een PC is een doel met vele verschillende aanvalshoeken. Het is echt niet als of heel duister denkend computerland massaal over is gestapt op aanvallen die Intel bugs gebruiken. Dit alleen al zou aan moeten geven dat de wereld niet in elkaar stort.

Intel gaat echt niet in een keer hun productielijn om gooien, nieuwe processors waar designveranderingen in terecht moeten komen hebben een redelijk lange tijd nodig voor ze ergens degelijk getest in de schappen kunnen liggen. Een simpele stepping zal deze fix niet zijn.
Downplayen (bagatelliseren) is natuurlijk nooit correct (als u de betekenis ervan begrijpt) en op welke feiten wilt u dat dan baseren?

Intel kan tot nu toe 32 rechtzaken verwachten. als de juridische fase begint dan wordt het tenminste weer een leuk 'spannend' item voor in de massamedia (zeker als er financiele compensaties op wat voor manier dan ook aan vast zitten.)
Het is waarschijnlijk een van de grootste vulnerabilities (backdoors) ooit. Grove nalatigheid kan in dit geval ook wel gebruikt worden - zeker omdat men processoren die kwetsbaar zijn gewoon blijven produceren. Men downplayed het door te zeggen dat deze 'kwetsbaarheden' moeilijk toe te te passen zijn.
Daar denk je denk ik aan Meltdown. Spectre is meer een gevolg van de architectuur van de bijna alle processors, dus dat kun je sowieso niet zomaar even aanpassen.
Ik heb begrepen dat een aantal spectre/metldown vulnerabilities gepatchd kunnen worden met een OS update en dat een deel van de vulnerabilities gepatchd moeten worden via een firmware update.
Al mijn systemen thuis zijn wel up to date qua OS niveau, maar wanneer er hardware patches komen van intel hoe makkelijk zal het zijn om deze te installeren? Mijn oudste systeem is bijna 8 jaar oud en ik heb nog nooit een firmware update gedaan op mijn hardware op mijn systemen thuis, zou ook niet weten hoe je deze nog zou moeten installeren, of worden deze deels uitgerold door de OS maker? En zijn er al cpu's uit die geen spectre/meltdown vulnerabilities hebben?

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True