Dokumentálatlan MSR-ek felderítése és kihasználása, nemcsak támadásra

A modern CPU-k modell-specifikus regisztereiről (MSR) már korábban is ismert volt, hogy meglehetősen szelektíven dokumentáltak. A gyártók a regiszterek egy részét közzéteszik a CPU architektúra programozási útmutatóban, ezzel lehet bizonyos CPU feature-öket, egyes utasítások támogatását, vagy különféle teljesítménynövelő megoldásokat ki-be kapcsolni. Viszont sokszor ezen regiszterek egyes bitjei is "Reserved", "Unused" és hasonló jelzőkkel vannak ellátva, másrészt találtak már korábban is olyan MSR-eket amik teljesen hiányoztak a dokumentációból.

Ennek kapcsán az első igazán nagy horderejű eredmény Cristopher Domas nevéhez fűződik, aki a Via C3 processzorokban szándékosan beépített backdoort fedezett fel, ezidáig ez az egyetlen eset, amikor egy processzor biztonsági hibája minden kétséget kizáróan szándékosan került beépítésre. A hátsó ajtó aktiválásához dokumentálatlan MSR-eket kellett meghatározott módon felprogramozni. A munka kulcsfontosságú része ezek felderítése volt.

Nemrég a Grazi Műszaki Egyetem (Daniel Gruss kutatócsoportja - a nevük ismert lehet a Spectre és Meltdown sebezhetőségről) valamint a Helmholtz számítógépes biztonsági kutatóközpont és az Amazon AWS egy kutatója publikáltak egy új módszert a rejtett MSR-ek felderítésére: Finding and Exploiting CPU Features using MSR Templating címmel.

A munka számos eredménnyel járt, a szokásos új támadási módszereken túl kivételesen új védekezési lehetőséget is találtak: egyes dokumentálatlan MSR-eket már ismert sebezhetőségek hatástalanítására is fel lehet használni, ráadásul - a méréseik szerint - szinte észrevehetetlen teljesítményvesztés árán.

A munkájuk eredményei nagy vonalakban:

  • Fejlesztettek egy új eszközt az MSR-ek felderítésére: msrevelio, mely képes a csak olvasható, csak írható regisztereket is megtalálni, valamint meglevő dokumentált regiszterekkel összevetni
  • Megvizsgáltak számos BIOS/UEFI firmware-t, hogy a magyarázat nélküli, titokzatos "advanced" opciók (pl.: "Machine Check", "K1 off", "Strong weak leaker") melyik MSR-t módosítják és valójában mit is csinálnak.
  • Számos CPU-t (kb 10 évvel ezelőttről a Sandy Bridge-től kezdve, Intel és AMD-től egyaránt) végigteszteltek. A meglepő eredmény, hogy míg az Intelnél kb az MSR-ek 25%-a volt rejtett, az AMD-nél 93%-volt a dokumentálatlan regiszterek aránya.
  • A gyártók sokszor mikrokód frissítéssel vezetnek be új MSR-eket meglevő processzorokba. A CPU-k mikrokód verzióit lépésről lépésre végigtesztelték, hogy visszamenőleg megtalálják egyes MSR-ek melyik verzióval jelentek meg. Ennek külön érdekessége, hogy így sok biztonsági hibára adott fixet (már amiknek a bekapcsolására új MSR-t vezettek be) már hónapokkal a hivatalos bejelentés előtt kiadott verzióban azonosították. Vagyis a módszerük a jövőben alkalmazható lesz a gyártó által már ismert, de még be nem jelentett sebezhetőségek felfedésére is.
  • Találtak új támadási módszert, az AES-NI utasítások menet közbeni letiltására alapozva, de ez egyrészt BIOS módosítást igényelt, másrészt csak az SGX-et használó Secure Enclave-kban történő kulcsok kiszivárogtatására alkalmas. A leírtak alapján meglehetősen speciális támadó-modellről van szó, ami feltehetően nagyon kevés átlagfelhasználót érint.
  • Xen hypervisorban találtak problémát, mivel ez korábban a guest VM-ek elől csak bizonyos, ismert, biztonsági szempontból veszélyes MSR-eket maszkolt le. Nyilvánvaló, hogy a dokumentálatlan, és mikrokód verziónként változó MSR-ekhez a hozzáférést ilyen módon nem lehet megakadályozni. A kutatás eredményeképpen megfordították a megközelítést és most már az alapeset a tiltás és csak néhány tételesen felsorolt MSR van explicit engedve.
  • A talált dokumentálatlan MSR-ek közül kiválasztottak néhányat, amik átállításával ismert sebezhetőségeket tudtak megelőzni, pl: KASLR elleni software-prefetch támadások, MEDUSA, ill. CrossTalk támadások. Ezek némelyikére ez az első szoftveres védekezési lehetőség. Bár természetesen megjegyezték, hogy kockázatos a gyártó által hivatalosan nem támogatott módszerre alapozni ilyen védekezést.

Hozzászólások

Nagyon jó kis összefoglaló, köszi!