A spektrum biztonsági résének mérséklése

A sérülékenységi spektrum mérséklése technikák összessége a hibás számítógépes biztonság megszüntetésére . Ez a probléma a kísértet sebezhetőségének felfedezésével és népszerűsítésével merült fel, és biztonsági rést hagyott számos számítógépes rendszerben.

A teljesítmény javításának folyamatos kutatása arra késztette a gyártókat, hogy spekulatív kódfuttatást hajtsanak végre a processzoron belül, de ez a biztonság szempontjából költséges. A Spectre sebezhetőségének enyhítése a megszerzettnek gondolt, de a processzorok spekulatív végrehajtása által megnövekedett teljesítményért feláldozott biztonság helyreállítását célozza.

Enyhítés elve

A kísértet támadások elleni védekezés nagy részét 3 kategóriában foglalhatjuk össze:

  1. A lefedett csatornák pontosságának mérséklése vagy csökkentése az adatok kinyerése céljából;
  2. A spekuláció enyhítése vagy abbahagyása a végrehajtás során potenciálisan hozzáférhető adatok esetén;
  3. Győződjön meg arról, hogy a rejtett adatok nem érhetők el.

A mérséklésnek ez a három kategóriája alkalmazható szoftveres megoldásokkal vagy hardveres megoldásokkal.

Hardveres megoldások

A leghatékonyabb mérséklési megoldás a spekulatív végrehajtás letiltása a processzorokon, amely a Spectre típusú támadások végrehajtásához szükséges. Ez a megoldás nem reális, mert jelentős teljesítményvesztéshez vezetne.

Az egyik lehetséges mérséklési megoldás a Spectre számára a Safespec néven az, hogy ideiglenes struktúrát használ az eljárás visszatérési címének védelmére szolgáló mechanizmusként . Ez a struktúra azon adatok védelmére szolgál, amelyekre a spekulatív végrehajtás sor kerül. Ha az adatokat kereső utasítás sikeresen befejeződik (ami azt jelenti, hogy az utasítást a processzor engedélyezte, és nem ad hozzáférést az érzékeny adatokhoz), akkor az adatokat az úgynevezett állandó struktúrákba ( cache memóriába ) helyezzük át . Ellenkező esetben az adatok törlődnek az ideiglenes struktúrából, és soha nem kerülnek a gyorsítótárba. Ezért az utasítások adatai, amelyek nem eredményeznek sikert, láthatatlanok a támadó számára, mert nem kerülnek a számítógép memóriájába. Ez a megoldás megköveteli az ideiglenes struktúra számára fenntartott memóriaterület hozzáadását, amely teljes védelmet tesz lehetővé a Spectre típusú sebezhetőségek ellen. Hasonlóképpen, az Illinoisi Egyetem kutatói a Safespechez hasonló megoldást fejlesztenek. Ennek az Invispec nevű megoldásnak az a célja, hogy láthatatlanná tegye a cache spekulatív végrehajtásával kapcsolatos terheléseket. Ez a rejtés egy spekulatív pufferrel működik, amely hasonlóan működik a SafeSpec ideiglenes struktúráihoz, amelyek a betöltött információkat tárolják a gyorsítótár helyett. Mondottak szerint az egyetem, InvisiSpec képes kezelni az összhangot a cache adatokat, valamint a menedzsment Multi Thread kivégzések ellentétben SafeSpec és ideiglenes építményeket.

A PoisonIvy egy megoldás a spekulatív végrehajtás nyomon követésére és az integrált áramkörön kívüli adatok expozíciójának megakadályozására. Ez a megoldás megakadályozza vagy korlátozza egy harmadik fél esetleges hallgatását a memória buszon. A PoisonIvy figyeli az információáramlást, hogy felkutassa a spekulatív végrehajtás során keletkezett adatokat vagy az attól függő adatokat.

A Cambridge-i Egyetem 2010- ben kezdte fejleszteni a CHERI (Capability Hardware Enhanced RISC Instructions) nevű architektúrát . Jelenleg folyamatban van a CHERI architektúrának megfelelő processzor prototípus fejlesztése. Ez a prototípus fejlesztés alatt áll, és egy pillanatra arra törekszik, hogy egy programozható logikai áramkörön vagy FPGA-n (terepi programozható kaputömb) használja. Ezen kívül az egyetem létrehozta a QEMU alatt futó CHERI megvalósítását is . Végül ennek a processzornak megvan a saját adaptációja a FreeBSD-től, amely lehetővé teszi a processzor elindítását, de a memória védelmi lehetőségeinek használatát is. Az egyetem műszaki jelentést tett közzé2018. februára processzor teljesítményének kezelése a Spectre és a Meltdown támadások ellen . A CHERI típusú processzorok védettek az 1. és 3. típusú spektrum támadásokkal szemben.

Szoftveres megoldások

Javasolt szoftveres megoldás az assembler utasítás használata LFENCE. Ez az utasítás megakadályozná a processzort abban, hogy előre végrehajtsa a műveleteket, és így ellensúlyozza a Spectre 1. variánst. Azonban megfontoltan kell használni, különben a teljesítmény komolyan veszélybe kerülhet.

Bizonyos architektúrákban, például az ARMv8 architektúrákban , feltételeket lehet rájuk MOVállítani az assembler parancsokkal CMOV, elágazás használata nélkül. Ennek eredményeként lehetséges enyhíteni a Spectre támadásainak egy részét. Egyes megvalósításokban továbbra is lehetséges a spekuláció , ebben az esetben a MOVfeltételeket korlátokkal kell párosítani. Ez a megoldás önmagában azonban továbbra is elegendő számos jelenlegi mikro-architektúrához.

A Retpoline (visszatérő trambulin) a 2. típusú spektrális támadások védelmére szolgáló megoldás, amely a visszatérő ágak cseréjén, valamint az RSB (Return Stack Buffer) szennyezésén alapul. A Retpoline beállításához hozzáférés szükséges a forráskódhoz és engedélyre van szükség a fordításhoz . A puffermemória szennyezésének eredeti alapelve az , hogy blokkolja a spekulatív végrehajtást a végtelen ciklust generáló assembler parancsok hozzáadásával, amíg a processzor észleli a veszélyes előrejelzést. A támadó a visszatérő verem puffer segítségével próbál információkat szerezni, amelyeken általában az összeállítási parancsok visszatérési címei vannak tárolva CALL. Ezek az adatok ezután visszaállíthatók egy visszahívás segítségével, ahol a processzor az adatokat közvetlenül a visszatérő verem pufferen keresi. A Retpoline azonban lehetőséget kínál arra, hogy megvédje magát a visszatérő verem címének módosításával, hogy különbség alakuljon ki a visszatérő verem puffer és a memória busz között. Végül ezzel a különbséggel a processzor ki tudja üríteni a visszatérő verem puffert, és folytathatja a kód végrehajtását a memória buszról letöltött címmel.

A webböngészőket is befolyásolja a hibaspektrum. Ennek enyhítése érdekében a legtöbb böngésző úgy döntött, hogy letiltja a JavaScript objektumot, SharedArrayBufferamely lehetővé tette tömb létrehozását megosztott memória használatával.

Enyhítési kérdések

Helyezze vissza a biztonságot

A 2018. január 3, A Project Zero kutatói cikket közölnek a Spectre és a Meltdown sebezhetőséggel kapcsolatos megállapításaikról . Ez a cikk jól látható volt, ami lehetővé tette a rosszindulatú emberek számára, hogy támadásokat hajtsanak végre azzal a céllal, hogy információkat rejtsenek el egy számítógépes rendszerben. Mivel a hiba a processzorok egy tulajdonságát érinti, fontos volt, hogy az érintett gyártók gyorsan javasolják a korrekciót, hogy a hatás a lehető legkisebb legyen.

Ban ben 2018. december, szép számmal olyan javítások kerültek bevezetésre, amelyek látszólag ellensúlyozzák a Spectre támadásokat. Azonban még mindig nem világos, hogy a biztonsági rés továbbra is fennáll-e a rendszerén, mivel az első javítások után új Spectre variánsokat fedeztek fel.

Lehetővé teszik annak ellenőrzését, hogy rendszerük sérülékeny-e ezekre a hibákra, valamint ingyenes hozzáférési kódot, amely lehetővé teszi a támadás újratermelését.

Korlátozza a teljesítményvesztést

Mérhetjük a jelenleg alkalmazott mérséklési technikák teljesítményveszteségeit, és képet kaphatunk az eredményekről. Pontos eredményt azonban nehéz adni, mivel ezek a kontextustól és az alkalmazott mérséklési elvektől függően változhatnak.

Az elemzéseket nagy csomópontú párhuzamos számításokon végeztük több csomóponton , összehasonlítva őket az egy csomópontú számításokon végzett elemzésekkel. Ezeket az elemzéseket a CentOS Linux operációs rendszerrel és annak Spern- és Meltdown-támadásokban használt spekulatív végrehajtását és közvetett elágazást előrejelző hibáit rögzítő kernelének frissített változatával végeztük . Ezek az eredmények körülbelül 2-3% -kal lassabbak az egycsomópontú párhuzamos feladatoknál, és körülbelül 5-11% -kal lassabbak a több csomópontú párhuzamos feladatoknál.

Részletesebb elemzéseket végeztek a MIT Lincoln laboratóriumaiban, hogy elemezzék a Spectre és Meltdown mérséklési technikáit. A cél egy vagy több paraméter hozzáadásával kideríteni, hogy melyikeknek van a legnagyobb hatása a Linux kernelbázisból:

Ezeket a különböző paramétereket három különböző összefüggésben tesztelik:

Az eredmények a paraméterek alkalmazása utáni lassulás formájában kifejezett átlagos százalékban kifejezve a következők:

Internetkapcsolat
Tűzfal nélkül Tűzfallal
Grsecurity nélkül 15% 21%
Grsecurity-val 15% 61%

Vegye figyelembe, hogy a hatás nagyobb, ha ezeket a mérséklési technikákat tűzfalon alkalmazzák. A tűzfal használata ugyanis a TCP-kapcsolatok elfogadásakor sok átmenetet eredményez a felhasználói térből a kerneltérbe . Ezek az átmenetek számos olyan rendszerhívást adnak hozzá , amelyeket a mérséklő technikák befolyásolnak.

Merevlemez-hozzáférés
Helyi környezet Csillár
Grsecurity nélkül 50% 33%
Grsecurity-val 90% 33%

A merevlemez-hozzáférés eredménye kirívó. Ami a lemez írását és olvasását illeti, a rendszer drága rendszerhívásokat indít. Ezért logikus, hogy erőteljesen csökkenjen a teljesítmény, különösen az intenzív tesztek során. Azt is észrevesszük, hogy a hatás nagyobb a helyi környezetben, mint a Luster esetében. Ennek oka, hogy a Luster összességében lassabb, ha kis blokkméretekkel használják, amire a tesztelés során szükség volt.

Számítástechnika intenzív
MATLAB Tensorflow
Minden enyhítési paraméter 21% 16%
Csak a BIOS frissítése 19% 15%

Ez utóbbi összefüggésben az eredmények kevésbé változnak. A tesztek ugyanis kevés rendszerhívást indítanak. Látható azonban, hogy az összes korábban említett enyhítési paraméter alkalmazásakor a lassulás egybeesik azokkal az eredményekkel, amikor csak a BIOS frissítést alkalmazzuk. Ez azt jelenti, hogy a frissítés szükségességétől kezdve nehéz korlátozni a teljesítményvesztést.

Alkalmazott megoldások

Processzor

Intel

Az elnök az Intel bejelentette a csökkentési lehetőség 1 szoftver megoldások és variánsok a 2. és 3. lényeges változások processzor 8 th generációs növelése az adatvédelem.

AMD

Biztonsági szoftverfrissítéseket hajtott végre az AMD 2018 folyamán a kísértetek sebezhetőségének enyhítése érdekében.

Operációs rendszer

Microsoft

A 2018. március 15, A Microsoft közzétesz egy cikket, amely három megoldást javasol a spekulatív végrehajtási sebezhetőségek enyhítésére: a spekulációs technikák megakadályozása, az érzékeny adatok eltávolítása a memóriából és a megfigyelési csatornák eltávolítása.

A Spectre 1 variáns megoldásaival kapcsolatban a Windows rendszer bináris fájljainak újrafordításán túl változtatásokat hajtottak végre a fordítójukon . A 2. variánst úgy sikerült ellensúlyozni, hogy új processzor-utasításokat hívtunk meg az ágspekulációk kiküszöbölésére kockázatos helyzetekben.

A 2018. december 5, A Microsoft bejelenti azt a döntést, hogy a Google által kifejlesztett Retpoline megoldást használja az operációs rendszer teljesítményének javítására a 2. spektrum variánssal szemben.

alma

Technikai megjegyzésben az Apple azt állítja, hogy kiadta az iOS és a macOS High Sierra frissítéseit, amelyek célja a Spectre elleni védelem javítása az alkalmazott mérséklési technikák részletezése nélkül.

Linux

Linux alatt megtudható, hogy a rendszere sérülékeny- /sys/devices/system/cpu/vulnerabilitiese a fájlokkal spectre_v1és a mappában található két Spectre variánssal szemben spectre_v2. Ugyanez az információ a linux paranccsal is megszerezhetőlscpu

Példa a frissített rendszerű fájlok tartalmára:

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling

Az 1. get_userspektrumváltozatot a Linux kerneljében a sérülékeny funkció javításával, a 2-es változatot pedig a Retpoline megoldással elleneztük.

böngésző

Google

A Google Chrome böngésző elkülöníti az egyes webhelyeket a különböző folyamatok között. Ez az elkülönítés nem enyhíti teljes mértékben a spektrális támadásokat, a CORB-hez (Cross-Origin Read Blocking) kapcsolódó korlátozások miatt, amelyek nem védenek minden típusú webtartalmat. A webfejlesztőknek ezért azt javasolják, hogy kövessék a biztonsági gyakorlatokat az enyhítés maximalizálása érdekében.

A JavaScript objektumot SharedArrayBufferletiltották a Chrome 63 frissítésében. A Chrome 67-től kezdve az objektumot újra engedélyezték, feltéve, hogy a böngészőben engedélyezve van a webhelyek elkülönítése.

Mozilla

Firefox böngészőjüknél a Mozilla SharedArrayBufferalapértelmezés szerint deaktiválta a JavaScript objektumot az 57-es verziótól. Azonban a böngésző opcióiban egy változó megváltoztatásával aktiválható.

Ezenkívül az performance.now()időbélyeg létrehozására szolgáló JavaScript függvény , amely állítólag pontosabb, mint a függvény Date.now(), bizonyos módosításokon ment keresztül. A 60-as verziótól kezdve a függvény által visszaadott eredményt ezredmásodpercre kerekítjük.

Hivatkozások

  1. Műszaki Egyetem, 2018 , p.  9.
  2. Jann Horn 2018 , p.  12.
  3. Árnyékszerkezet 2018 , p.  10.
  4. InvisiSpec 2018 , p.  13.
  5. Műszaki Egyetem, 2018 , p.  10.
  6. InvisiSpec 2018 , p.  3
  7. széf
  8. PoisonIvy
  9. Cheri University of Cambridge 2010 , p.  20
  10. CHERI Végrehajtás 2018 , p.  2
  11. CHERI jegyzetek 2010 , p.  10.
  12. Intel 2018 , p.  8.
  13. AMD 2018
  14. rfc 2018
  15. CHERI cmov 2010 , p.  8.
  16. retpoline 2018
  17. Lusta 2018 , p.  4
  18. blepingcomputer 2018
  19. Mozilla 2018
  20. Project Zero 2018
  21. Brewster 2018
  22. Techrepublic 2018
  23. Dzone 2019
  24. Tencent Xuanwu Lab 2018
  25. ascendr 2018
  26. Simakov 2018 , p.  2
  27. Simakov 2018 , p.  3
  28. Andrew Prout 2018
  29. RedHat 2018. október
  30. Corbet 2017. november
  31. Coldewey 2018. január
  32. PaX Team 2012. október , p.  3
  33. Shawn C. 2018. augusztus
  34. Andrew Prout 2018 , p.  3
  35. Intel név 2018
  36. 2018
  37. swiat 2018
  38. Microsoft 2018
  39. Microsoft 2018
  40. Apple 2018
  41. LWN.net 2018
  42. LWN.net 2018
  43. Króm 2018
  44. Króm 2018
  45. Chromium 2018
  46. Króm 2018
  47. Mozilla 2018
  48. Mozilla 2018

Bibliográfia

Lásd is

Egyéb bibliográfiai források