Veel processors proberen te voorspellen wat de volgende stappen zullen gaan zijn, en halen alvast de benodigde data daarvoor op. Deze Data Memory-Dependent Prefetchers (DMP’s) zorgen voor veel meer snelheid, maar vormen vaak ook een risico bij de beveiliging.

Dat zien we ook bij een nieuw gepubliceerd beveiligingsprobleem (Pdf, 627 KB) dat door de betrokken onderzoekers ‘GoFetch’ is gedoopt.



In een mail aan ArsTechnica leggen de onderzoekers het als volgt uit:

Prefetchers kijken meestal naar ‘adressen’ van geraadpleegde gegevens (waarbij de waarden van geraadpleegde gegevens worden genegeerd) en proberen toekomstige ‘adressen’ te raden die nuttig zouden kunnen zijn. Het DMP is in dit opzicht anders, omdat het naast ‘adressen’ ook de gegevenswaarden gebruikt om voorspellingen te doen (‘adressen’ voorspellen om waar naar toe te gaan en te prefetchen). In het bijzonder, als een datawaarde er ‘uitziet’ als een pointer, zal het worden behandeld als een ‘adres’ (terwijl het dat eigenlijk niet is!) en de data van dit ‘adres’ zal naar de cache worden gebracht. De aankomst van dit adres in de cache is zichtbaar, het lekt over zijkanalen van de cache.

Onze aanval maakt hier gebruik van. We kunnen versleutelingscodes niet direct lekken, maar wat we wel kunnen doen is het manipuleren van tussenliggende data in het versleutelingsalgoritme zodat het eruit ziet als een pointer via een gekozen invoeraanval. De DMP ziet dat dan als gegevenswaarde ‘eruit ziet’ als een adres en brengt de gegevens van dit ‘adres’ in de cache, waardoor het ‘adres’ lekt. Het maakt ons niet uit dat de gegevenswaarde wordt geprefetched, maar het feit dat de tussenliggende gegevens eruit zagen als een adres is zichtbaar via een cachekanaal en is voldoende om de geheime sleutel na verloop van tijd te onthullen.

Het zal veel creativiteit vergen om dit op te lossen zonder dat het ten koste gaat van de snelheid van het verwerken van de data door de processor. Een geruststellende gedachte in de tussentijd is dat het hoogstwaarschijnlijk altijd nodig is om fysieke toegang te hebben om deze aanval uit te voeren, voorlopig lijkt dit niet op afstand uitgevoerd te kunnen worden.

Nu lijken vooral de M1 en de M2 gevoelig voor deze aanval. Het DMP op de M3 Apple, heeft een speciale bit die ontwikkelaars kunnen aanroepen om het uit te schakelen, maar de onderzoekers weten nog niet zeker wat het effect is op de snelheid als deze prestatie-optimalisatie wordt uitgeschakeld.



 #AppleSilicon #Beveiliging

Was al opgemerkt hier

Een geruststellende gedachte in de tussentijd is dat het hoogstwaarschijnlijk altijd nodig om fysieke toegang te hebben om deze aanval uit te voeren

Inderdaad, en ter verdere relativering:

But real-world risks are low. To exploit the vulnerability, an attacker would have to fool a user into installing a malicious app, and unsigned Mac apps are blocked by default. Additionally, the time taken to carry out an attack is quite significant, ranging from 54 minutes to 10 hours in tests carried out by researchers, so the app would need to be running for a considerable time. (bron)