Belső vezérlőprogram támadási felületének csökkentése (FASR)

2019 októberében a Microsoft szorosan együttműködik OEM- és Silicon-partnereinkkel a biztonságos magú számítógépek elindításában. Ezek az eszközök mélyen integrált hardverekkel, belső vezérlőprogramokkal és szoftverekkel rendelkeznek, amelyek segítenek az eszközök, identitások és adatok fokozott biztonságának biztosításában. A biztonságos magú számítógépek egyik alapvető biztonsági alappillére a belső vezérlőprogram-védelem biztosítása az eszközök számára. Ennek a pillérnek a teljesítéséhez alapvető hardveralapú funkció a Dinamikus megbízhatósági alap a méréshez (D-RTM). Jelenleg azonban nem sok eszköz kínál D-RTM-et, mivel a mögöttes lapkakészlet függősége támogatja ezt a képességet, ami akadályozza a magas biztonsági sávok minden Windows-eszközhöz való hozzáadását és fenntartását.

További teendők az összes Windows-eszköz biztonsági helyzetének javítása érdekében, beleértve a D-RTM nélküli eszközöket is. A Microsoft együttműködik a partnerekkel azoknak a kompatibilitási problémáknak a megoldásán, amelyek megakadályozták a memóriavédelem alkalmazását az UEFI belső vezérlőprogramban. Ehhez nyílt forráskódú SMM biztonsági fejlesztéseket fejleszt, amelyek további rugalmasságot biztosítanak az oem-eknek.

A belső vezérlőprogramok biztonsága iránti elkötelezettség tükrözése érdekében új megközelítést azonosítottunk annak biztosítására, hogy az eszközök megfeleljenek a védett magú számítógépek belső vezérlőprogram-védelmi követelményeinek.

A FASR áttekintése

A hardveralapú D-RTM-képességekkel nem rendelkező biztonságos magos számítógépek esetében meg kell határoznunk egy kis készlet belső vezérlőprogram-összetevőt, amely csökkentett támadási felületet biztosít, és amely tanúsítható az operációs rendszerben. Ezt a megközelítést belső vezérlőprogram támadási felületének csökkentésének (FASR) nevezzük. Ahhoz, hogy a FASR-alapú belső vezérlőprogram skálázható legyen a különböző gyártók számítógépei között, meg kellett határozni a belső vezérlőprogram rendszerindítási folyamatának új megközelítését.

A FASR két rendszerindítási útvonalat támogat:

1. Minősített rendszerindítási útvonal:

   • Csak a Microsoft által megbízható, aláírt és integrált kód hajtható végre.

   • A rendszerindítási útvonal manipulálását az operációs rendszer észleli.

   Az alábbi ábra a FASR S-RTM rendszerindítási folyamatát mutatja a hitelesített rendszerindítási útvonalon. Ez a rendszerindítási útvonal segít megakadályozni a platform váratlan belső vezérlőprogram-kódjának végrehajtását. Azonban az egyéni rendszerindítási útvonal által biztosított platformspecifikus adatokat is felhasználja. Az alábbi ábra a FASR rendszerindítási folyamatát mutatja be a hitelesített rendszerindítási útvonalon.

   

2. Egyéni rendszerindítási útvonal: Minden platform belső vezérlőprogram-kódja végrehajtható. Az adott OEM-hez/platformhoz tartozó rendszerindítási kritikus információk az egyéni rendszerindítási útvonal adataivá alakulnak, és a hitelesített rendszerindítási útvonal használatával megfelelően konfigurálja a rendszert az adott rendszerindítási útvonalon. Az alábbi ábra a FASR rendszerindítási folyamatát mutatja be az egyéni rendszerindítási útvonalon.

   

   A Biztonságos Magos PC-megfelelőséghez engedélyezett FASR-eszköz alapértelmezés szerint a hitelesített rendszerindítási útvonalra kerül, kivéve, ha olyan esemény történt, amely miatt a rendszerindítás a firmware rendszerindítási folyamatának korai szakaszában átvált az egyéni rendszerindítási útvonalra. Ilyen események közé tartozik a belső vezérlőprogram frissítése, a felhasználó kérte a belső vezérlőprogram felhasználói felületét, vagy a felhasználó úgy döntött, hogy letiltja a Védett-mag PC-t, ami azt jelenti, hogy mindig az egyéni rendszerindítási útvonalon indulnak el, amíg újra nem engedélyezi.

   Az egyéni rendszerindítás bármely operációs rendszer vagy külső szoftver rendszerindítására használható, ahogyan azt a platform belső vezérlőprogramja támogatja FASR-kompatibilis eszközön, de a Windows nem ismeri fel a rendszerindítást az egyéni rendszerindítási útvonalon biztonságos magú pc-kompatibilisként.

A FASR mögötti biztonsági technológiák jobb megismerése érdekében szeretnénk megosztani a Windows rendszerindítási folyamatának gyors áttekintését.

Windows rendszerindítási folyamat

A megbízhatóság gyökere

A belső vezérlőprogram kezdeti végrehajtása egy modern pc-ben egy olyan rendszerindítási folyamatot követ, amelyben a kezdeti kódkészlet más kódot tölt be, és a funkció szintje a rendszerindítás előrehaladásával bővül. Minden kódkészlet ellenőrzi a következő kódkészletet, amely megbízhatósági láncot alkot. Amikor az UEFI belső vezérlőprogram átvesz az irányítást, a biztonságos rendszerindítási szabványt követi, amely ellenőrzi a szoftver aláírásait, hogy a megbízhatósági láncot egészen az operációs rendszerig folytatni tudja. Ezután a Windows rendszerindítási betöltője folytatja a megbízhatósági láncot a Megbízható rendszerindítással, amely az indítási folyamat minden más operációsrendszer-összetevőjét ellenőrzi, mielőtt betöltené.

Általánosságban elmondható, hogy a támadók a rendszerindítási folyamat során a lehető legkorábbi ellenőrzésre törekednek, mielőtt engedélyezve lettek a rendszer védelmét segítő biztonsági funkciók és zárolások. Amikor a rendszer kikerül az alaphelyzetből, a végrehajtott kód kezdeti állományának bizalmon kell alapulnia. A korai kódellenőrzés végrehajtásához szükséges szerepet betöltő hardverellenőrzési technológiát a megbízhatóság gyökerének nevezzük. Bár a pontos részletek hardverszállítónként eltérőek, a megbízhatóság minden gyökere általában az SOC nem módosítható hardvereiben vagy ROM-jaiban gyökerezik.

Mért rendszerindítás

A biztonságos rendszerindítás a megbízhatóság gyökerében rögzítve biztosítja az összes belső vezérlőprogram digitális aláírásának ellenőrzését; azonban az is kívánatos, hogy legyen egy feljegyzés arról, hogy pontosan milyen belső vezérlőprogramot hajtottak végre. A Windows hardverkompatibilitási program megköveteli, hogy minden Windows 10 és Windows 11 rendszerű számítógép tartalmazzon egy megbízható platformmodul (TPM) nevű chipet. A TPM platformkonfigurációs regiszterek (PCR-k) nevű memóriahelyeket tartalmaz. Minden PCR tartalmazza a rendszerindítás során betöltött kód és/vagy adatok kivonatát, például a nemvolatilis tárolóeszköz belső vezérlőprogram-kódját (például SPI flash), a PCI-eszközökről származó beállítási ROM-okat vagy az operációsrendszer-rendszerindítási betöltőt. A PCR-ben tárolható értékek méretét a támogatott kivonatoló algoritmus kivonatolási mérete határozza meg. Egy SHA-1 PCR például 20 bájtot tárolhat, míg egy SHA-2 PCR 32 bájtot tárolhat. Az ugyanahhoz a kivonatolási algoritmushoz társított több PCR-t banknak nevezzük. A TCG PC ügyféloldali TPM-profil specifikációja meghatározza, hogy legalább egy 24 regisztrációval rendelkező PCR-bank szerepel-e.

A TPM-ben minden belső vezérlőprogram-összetevő frissítheti vagy bővítheti a megfelelő PCR-t, mivel az új kód és az adatok betöltve vannak a rendszerindítási folyamatba. A kiterjesztési folyamat úgy frissíti a PCR-értéket, hogy az a kivonatoló algoritmus eredménye legyen, amely a jelenlegi PCR-érték és az új kód vagy adatargumentum összefűzésével készül bemenetként. Ennek az az eredménye, hogy a rendszerindítási folyamat után a PCR-k megvizsgálhatók annak meghatározásához, hogy mit hajtottak végre. Ez lehetővé teszi, hogy az operációs rendszer szoftvere megértse, hogy a rendszerindítási folyamat eltér-e az előző rendszerindítási folyamattól. Biztonsági szempontból érzékeny környezetben az operációs rendszer értesülhet az egyes PCR-kben elvárt kódmérések pontos készletéről a váratlan belső vezérlőprogram-kód végrehajtásának észleléséhez. Mivel a bank első 16 PCR-jét csak a teljes TPM alaphelyzetbe állításával lehet visszaállítani, ezek megbízhatók, és a fontos mérések TPM-ben való tárolásának előnyben részesített helyei.

A mérés megbízhatóságának gyökere

Most, hogy megvizsgáltuk a megbízhatóság gyökerének szerepét és a mért rendszerindítás használatát, két gyakori módszert vizsgálunk meg a megbízhatóság gyökerének létrehozására a mérési lánc TPM-nek való jelentéséhez: statikus és dinamikus.

A méréshez való megbízhatóság statikus gyökere (S-RTM) megbízhatóságot hoz létre a rendszer alaphelyzetbe állításakor, és megköveteli a megbízhatóság fenntartását a teljes rendszerindítási folyamat során. Ha a rendszerindítási folyamat bármely pontján sérül a megbízhatóság, a rendszer alaphelyzetbe állításáig helyreállíthatatlan. Az alábbi ábra az S-RTM használatát mutatja be a minősített rendszerindítási útvonalon.

Ezzel szemben a dinamikus megbízhatósági gyökér a méréshez (D-RTM) csak a lapkakészlet korai inicializálási firmware kódjának egy kis részében bízik, valamint egy hardverügynökben, amely a rendszerindítás során dinamikusan helyreállítja a megbízhatóságot. A rendszer kezdetben nem megbízható firmware kódba tud elindulni, de—röviddel az indítás után—megbízható állapotba áll vissza, amikor átveszi az összes CPU irányítását, és egy jól ismert és mért útvonalra kényszeríti azokat. Az alábbi ábra áttekintést nyújt a hagyományos D-RTM-folyamatokról.

Az S-RTM és a D-RTM között kompromisszum van. Az S-RTM nem igényel speciális hardveres képességeket, de megköveteli, hogy a szoftver jobban figyelembe vegye a teljes rendszerindítás során végrehajtott kódot. A D-RTM speciális hardveres képességeket igényel, de lehetővé teszi, hogy a szoftver dinamikusan indítson megbízható állapotba a rendszer élettartama alatt.

A Windows biztonságos magú számítógépei a biztonságos indításban egy D-RTM-et használtak, amely lehetővé teszi a rendszergyártók széles körének rugalmasságát a belső vezérlőprogram egyedi funkcióinak és szolgáltatásainak implementálásához, ugyanakkor hozzájárul ahhoz, hogy a rendszer megbízható és mért állapotba kerüljön, amely elfogadható a biztonságos operációsrendszer-környezet üzemeltetéséhez. A D-RTM indítási eseményt arra használjuk, hogy a biztonságos kernel betöltése előtt újra létre hozzuk a megbízhatóságot egy ismeretlen környezetből. Az alábbi ábra a D-RTM indítási eseményét mutatja be egy ismert rendszerkörnyezet újbóli létrehozásához.

Korábban az S-RTM több eszközön is implementálható volt, mivel nem függ a speciális hardveres képességektől a rendszer biztonsági állapotának ellenőrzéséhez, de az operációs rendszer nem rendelkezett megbízható módszerrel annak megerősítéséhez, hogy megbízhat az adott Windows-eszközön az S-RTM használatával jelentett mérésekben.

Belső vezérlőprogram biztonsági fejlesztései

A belső vezérlőprogram összetevőinek minimalizálása az operációs rendszer rendszerindítási útvonalán

Az S-RTM-mérések megbízhatóságának egyik módja az, hogy a végrehajtásra engedélyezett belső vezérlőprogram-összetevők számát minimálisra csökkentjük. Ha az S-RTM-et használó összes eszköz ugyanazt a belső vezérlőprogram-összetevőt használja, az operációs rendszernek csak az ismert és megbízható összetevőkre vonatkozó, várt PCR-értékek egyetlen készletében kell megbíznia. Ezzel az SRTM-alapú megközelítéssel úgy tekinthető, hogy egy eszköz megfelelt a védett magú számítógépek belső vezérlőprogram-védelmi követelményeinek, ha a rendszerindító belső vezérlőprogram-készlete csak a Windows által tanúsítható Microsoft-aláírt szoftvereket tartalmazza. Ha jobban szeretné megtudni, hogy ezek a belső vezérlőprogram-összetevők miben különböznek a normál pc-rendszerindítási összetevőktől, vizsgáljuk meg a rendszerindítási folyamatot előtte és utána.

A modern PC-belső vezérlőprogram által kínált rugalmasság és számos funkció miatt az operációs rendszer előtt végrehajtott kód nagyobb támadási felületet eredményez. Az alábbi ábra egy hagyományos S-RTM rendszerindítási folyamatot mutat be.

A belső vezérlőprogram fő feladatai a rendszerindítás során jelentősen leegyszerűsíthetők a következőre:

• Platformspecifikus: Olyan funkciók, amelyek csak az adott platformhardver-kialakításra vonatkoznak.

• Nem platformspecifikus: Iparági szabványnak megfelelő és más hardverekre jellemző funkciók.

A modern belső vezérlőprogram viszonylag kis része általában platformspecifikus. A belső vezérlőprogram infrastruktúra-kódjának nagy része, amely olyan gyakori feladatokat hajt végre, mint a memória kiosztása, a belső vezérlőprogram-illesztőprogramok elküldése, az események kezelése stb., ugyanaz az összes (vagy a legtöbb) UEFI-alapú rendszer között. A firmware bináris illesztőprogramok ezekhez a feladatokhoz újra felhasználhatók a számítógépeken. Emellett az iparági szabványos hardverspecifikációk és interfészek lehetővé teszik a gyakori belső vezérlőprogram-illesztőprogramok számára a merevlemezek, USB-vezérlők és egyéb perifériák inicializálását. A hardver belső vezérlőprogramjának bináris illesztőprogramjai a számítógépeken is újra felhasználhatók. Összefoglalva, a PC-k minimális közös firmware-illesztőprogramokkal indíthatók el.

A rendszerindítás során betöltött belső vezérlőprogram-illesztőprogramok teljes készletének csökkentése további előnyökkel járhat:

• Továbbfejlesztett rendszerindítási idő

• Csökkent a szállítók frissítéseinek koordinációja

• Csökkentett hibaexpozíció

• Csökkentett támadási felület

FASR rendszerindítási útvonal ellenőrzése és biztonságos magos megfelelőség

Ahhoz, hogy egy FASR-rendszer megfeleljen a védett magú számítógépek belső vezérlőprogram-védelmi követelményeinek, a hitelesített rendszerindítási útvonalon kell elindulnia. A FASR belső vezérlőprogram ezt úgy teszi lehetővé, hogy az operációs rendszernek egy Microsoft által aláírt jegyzékfájlt, a FASR-jegyzékfájlt (a TPM-ben mérve) adja meg, amely tartalmazza a modul rendszerindítási sorozatának várt PCR-értékeit a hitelesített útvonalon. Ez összehasonlítható a hitelesített útvonalon történt tényleges rendszerindítási sorozattal. Ha ezek a mérések egyeznek, a rendszer úgy tekinthető, hogy megfelelt a védett magú PC-program belső vezérlőprogram-védelmi követelményeinek. A várt minősített rendszerindítási útvonal-sorrendtől való eltérés miatt váratlan méréseket végeznek a TPM operációs rendszer által észlelt platformkonfigurációs nyilvántartásaiban (PCR-ekben).

Ezenkívül a Windows csak akkor ad ki hipervizor által védett titkos kódokat, ha sikeresen ellenőrzi az aláírt FASR-jegyzékfájlt az aktuális rendszerindítás során rögzített méréseken. Ha egy hitelesített rendszerindítási útvonalon vagy kapszulafrissítésen a FASR-jegyzék nem jelenik meg, az aláírás ellenőrzése sikertelen vagy PCR-eltérés történik, és a VSM-titkos kulcsok nem lesznek feloldva vagy migrálva.

Hogyan kezeli a FASR belső vezérlőprogram a memóriavédelmet és az SMM-et?

Most, hogy egyetlen, minimális funkcionalitással rendelkező Microsoft-aláírt binárist definiáltak, az magában foglalhatja a belső vezérlőprogram alapvető, de hiányzó biztonsági védelmét, amelyet a Microsoft a partnerekkel együttműködve hoz forgalomba. A minősített rendszerindítási útvonalnak legalább meg kell felelnie a következő követelményeknek:

1. A kód nem olvas és nem ír a NULL/0. oldalra.

2. A képkód és az adatszakaszok külön vannak választva

3. A képszakaszok 4 KB-os oldalhatáron vannak igazítva.

4. Az adatokat csak adatmemóriatípusokba, a kódot pedig kódmemóriatípusokba foglalják le.

5. A kódképek nincsenek betöltve az UEFI bináris fájlként elosztott kódból (csak a kijelölt diszpécserek)

6. A kód a lefoglalt memóriapufferek határain belül marad, az oldalfoglalásokat körülvevő védőoldalakkal.

7. A verem túlcsordulását észlelheti

8. A kód nem fut a veremből

9. A /NXCOMPAT DLL-jellemző az NX-védelem engedélyezésére van beállítva

A harmadik féltől származó beállítási ROM-okat, UEFI-alkalmazásokat és UEFI-illesztőprogramokat gyakran nem építették és nem ellenőrizték ezzel a követelménykészlettel. Ezért nem hajtanak végre a hitelesített rendszerindítási útvonalon. Az egyéni rendszerindítási útvonal opcionálisan dönthet úgy, hogy csökkenti a szükséges védelmi szintet, de a rendszerindítási útvonal nem minősül az operációs rendszer által megfelelő védett magú számítógépnek.

Rendszerfelügyeleti mód (SMM)

Az SMM egy speciális processzorüzemmód x86 architektúrában. Egyedülálló kihívást jelent a rendszerbiztonság számára, mivel az SMM-környezetben végrehajtott kód átlátszatlan az operációs rendszer számára, és általában a gazdagép processzorán lévő szoftverek legmagasabb szintű jogosultsági szintjén (más néven "Ring -2") hajtja végre. Belépéskor az SMM a laptábla beállításával, a megszakítás-küldő táblával (IDT) és más rendszerstruktúrákkal konfigurálja a saját környezetét. Az SMM egy jelentős támadási felületet jelent, amelyet rosszindulatú kódok használhatnak a Virtualization-alapú biztonság (VBS) által engedélyezett operációs rendszerek védelmének veszélyeztetésére vagy megkerülésére. Az SMM által okozott veszély csökkentése érdekében az SMM funkciói elméletileg feloszthatók az SMM alapvető infrastruktúrájára és az SMM-illesztőprogramokra az alábbiak szerint:

• SMM core: Az architekturális és infrastruktúra-feladatokat ellátó összes SMM-implementációra jellemző kód

• SMM-illesztőprogramok: Az SMM-ben platformspecifikus feladat végrehajtására írt kód

Az SMM életciklusának néhány fontos pillanata a következő:

1. Az SMM-alap (vagy mag) létrehozásakor – az SMM kezdeti programbetöltése (IPL)

2. SMM-illesztőprogramok betöltésekor – SMM-illesztőprogramok küldése

3. Amikor az SMM-be való belépés történik – rendszerfelügyeleti megszakításon (SMI) keresztül

Az SMM kezdeti programbetöltése (IPL)

A cpu speciális funkciókkal rendelkezik, amelyek magas szintű jogosultságot biztosítanak az SMM-kódnak, és segítenek megvédeni. Egy mechanizmus például az SMM szoftveres vagy hardveres eseményeken keresztüli beírására szolgál, az SMM-ből való visszatéréshez processzorutasítást használnak, és több regiszter is definiálva van az SMM hozzáférésének vezérléséhez és zárolásához. Ezek közül a vezérlőregisztrátorokat az SMM IPL-kód konfigurálja, hogy korlátozza az SMM-kód és az adatok tárolására szolgáló memóriaterülethez való hozzáférést (az úgynevezett System Management RAM-ot vagy SMRAM-et).

Mivel az SMRAM-terület a fő memóriában (DRAM) található, csak akkor hozható létre, ha a DRAM engedélyezve van a rendszerindítás során. A DRAM engedélyezési eljárásai szilícium-gyártónként eltérőek, de a fő memória rendelkezésre állása előtt elég sok megabájtnyi kód futtatható közvetlenül a CPU LLC-gyorsítótárból (beleértve a DRAM-t inicializáló kódot is).

A FASR firmware korábbra hozza az SMM IPL pontot a rendszerindításkor, mint a legtöbb más rendszer esetében. Ez csökkenti a lehetőséget, hogy a támadók aláássák ezt a folyamatot, és átvehessék a rendszer irányítását az SMM beállítása előtt. Ennek és a FASR belső vezérlőprogramban az SMM egyéb fejlesztéseinek jobb megértéséhez többet kell tudnunk a belső vezérlőprogram rendszerindítási folyamatáról.

Platform inicializálás (PI) az UEFI rendszerindítójában

A modern PC-belső vezérlőprogram számos specifikáció köré épül. Az UEFI specifikáció határozza meg az UEFI-kompatibilis operációs rendszer, például a Windows és az eszköz belső vezérlőprogramja közötti felületet. A platform inicializálásának (PI) egy másik specifikációja határozza meg a belső vezérlőprogram-illesztőprogramok létrehozásának módját, és magát a rendszerindítási folyamatot részletezi. Magas szinten az UEFI specifikáció az egyik olyan szabványnak tekinthető, amely lehetővé teszi, hogy egyetlen Windows-rendszerkép annyi különböző eszközzel működjön együtt, és a PI-specifikáció az egyik olyan szabványosítás, amely lehetővé teszi, hogy a különböző hardvergyártók firmware-lemezképei működjenek együtt. Mindkét specifikációt az UEFI Fórum tartja fenn.

A PI-specifikáció meghatározza a rendszerindítási fázisokat, és hogy mely illesztőprogramokat írja a rendszerindítási fázisba. A belső vezérlőprogram indítása során minden fázis a következőre lép, és a legtöbb esetben az átadásra kerülő fázis illesztőprogramjai már nem használatosak, és csak a fontos adatok kerülnek át a következő fázisba, hogy folytatódjon a rendszerindítási folyamat. A rendszerindítási fázisok a következőképpen foglalhatók össze:

1. SEC – A vezérlés megszerzése a CPU alaphelyzetbe állítási vektoránál, majd váltás az assembly nyelvről a C-kódra a PEI betöltéséhez.

2. PEI – A rendszerállapot inicializálása a DXE betöltéséhez és a DRAM inicializálásához

3. DXE – A rendszer további inicializálásának végrehajtása, amely magában foglalja az operációs rendszer betöltéséhez szükséges támogatási BDS biztosítását

4. BDS – Fedezze fel az aktuális rendszerindítás rendszerindítási beállítását (például operációsrendszer-rendszertöltőt), és próbálja meg elindítani ezt a beállítást

5. OPERÁCIÓS RENDSZER – Az operációs rendszer kernele

Az SMM kezdeti programbetöltésének (IPL) védelme

A hagyományos UEFI PI-specifikációnak megfelelő belső vezérlőprogram betölti az SMM IPL-t a DXE rendszerindítási fázisában. A FASR belső vezérlőprogramja betölti az SMM IPL-t a PEI rendszerindítási fázisában. A rendszer megbízható számítástechnikai bázisa (TCB) az azt védő védelmi mechanizmusok teljes készlete, beleértve a hardvert, a belső vezérlőprogramot és a szoftvert. Az SMM IPL DXE-ről PEI-be való áthelyezésével a teljes DXE-fázis (amely a PEI-nél nagyobb és gazdagabb környezet) törlődik a TCB-ből. Az alábbi ábrán az UEFI rendszerindítási folyamat korábbi szakaszában áthelyezett SMM IPL látható.

A PEI- és DXE-kód a 0. körben fut, és nem marad meg (néhány kivétellel) az operációs rendszerben. Az SMM-kód a 0. gyűrűnél (és a hipervizornál) magasabb jogosultsággal fut, és az operációs rendszerben marad, így a DXE biztonsági rések nem befolyásolják az SMM létrehozását, csökkenti az általános rendszertámadási felületet. Emellett mivel az SMM a rendszerindítási folyamat korábbi szakaszában indult el, az SMM védelmére szolgáló zárolási bitek a rendszerindítás során korábban engedélyezhetők, így a támadók ablakának további minimalizálása az SMM veszélyeztetése érdekében.

Az SMM-illesztőprogramok kézbesítési folyamatának védelme

A PI-specifikációban két SMM-mód van definiálva: hagyományos MM és önálló MM. A hagyományos MM egyenértékű a PI-kompatibilis belső vezérlőprogramban korábban használt SMM szoftvermodellel, amely az iparág legtöbb UEFI belső vezérlőprogramját alkotja. Az önálló MM egy viszonylag új mód, amely felülvizsgálja a korábbi modellt az SMM-környezet biztonságának javítása és a hagyományos MM-implementációkban elkövetett gyakori hibák megelőzése érdekében, amelyek számos hordozhatóságot és biztonsági kihívást eredményeztek az évek során.

A FASR belső vezérlőprogram kizárólag önálló MM módban működik. Ez lehetővé teszi, hogy a FASR belső vezérlőprogramja az SMM-ben a szoftvervégrehajtás fegyelmezett megközelítését kövesse. Manapság sok SMM-alapú biztonsági rést a hagyományos MM-ben az SMM-kódban engedélyezett helytelen eljárásoknak köszönhet, amelyek egyszerűen eltávolíthatók önálló MM-ben. Magas szinten ez azért fordul elő, mert – a hagyományos MM-modellben – kétszer küld egy SMM-illesztőprogramot, egyszer a 0. körben a DXE diszpécser, majd ismét az SMM SMM-diszpécsere. Ez bőséges lehetőséget biztosít arra, hogy a DXE-környezetben futó illesztőprogram-kód olyan mutatókat gyorsítótárazzon az SMRAM-en kívüli erőforrásokhoz, amelyekhez a belépési pont visszatérése után már nem lenne szabad hozzáférniük. Az SMM-en kívüli kód meghívására irányuló SMM-kódtól függő támadásokat gyakran nevezik "SMM-hívási támadásoknak".

Az SMM-be való belépés védelme

Az adatok egy SMI-kezelőnek a "kommunikációs puffer" nevű struktúrán keresztül kerülnek átadásra. Az SMI kezelője felelős annak ellenőrzéséért, hogy az adatok megfelelnek-e a belépési pont bizonyos követelményeinek. A Windows SMM biztonsági csökkentési táblázat (WSMT) egy olyan mechanizmus, amellyel enyhíthetők az operációs rendszer virtualizációalapú biztonságát fenyegető, nem ellenőrzött SMI-kezelők által jelentett fenyegetések. A Microsoft kóddal járult hozzá a TianoCore-projekthez a kommunikáció pufferérvényesítésének javítása érdekében. A két technika alkalmazása mellett a FASR-kód szigorú memóriahozzáférési védelmet is alkalmaz, így az SMM-kód csak a kifejezetten engedélyezett memóriatartományokhoz fér hozzá.

Felügyeleti mód felügyelője (MM-felügyelő)

Az SMM alapkódja gyakori, és a rendszerek közötti minimális változás nélkül meg van osztva. Az SMM által előírt támadási felület jelentősen csökkenthető az SMM-környezet jogosultsági elkülönítésének bevezetésével. Ezért a FASR belső vezérlőprogram tartalmaz egy SMM-felügyelőt, amely önálló MM-ben fut. Ez egy jól definiált SMM-környezetet eredményez, amely minimális TCB-vel rendelkezik, és a jogosultsági szinteket a létrehozáskor kényszerítik ki. Az MM-felügyelő korlátozásokat helyez el az IO-portokhoz való hozzáférésre, a modellspecifikus nyilvántartási (MSR-) hozzáférésekre, az MMIO-hozzáférésre, a CPU-mentési állapot elérésére és az SMM-környezetben engedélyezett utasításokra. Az SMM felügyeleti szabályzata a hardvererőforrások korlátozásának pontos részleteinek konfigurálására szolgál, és ezek a pontos részletek szilícium-generációnként változhatnak.

A szabályzat a közelmúltban egy alapértelmezett megtagadási megközelítésre vált, amely jelentősen csökkenti az SMM-felügyelőn kívüli kódhoz elérhető hardvererőforrásokat. Ez a felügyelő hardverfüggőség nélkül működik a modern számítógépeken nem gyakran előforduló hardverfunkcióktól.

A FASR-ben használt MM-felügyelő nyílt forráskódú, és elérhető a Project Mu MM felügyelői adattárában.

A FASR rendszer megfelelősége a biztonságos magú PC-k követelményeinek

Az alábbi táblázat a biztonságos magú számítógépek széles körű biztonsági pilléreit vagy céljait mutatja be, valamint azt, hogy a hitelesített útvonalon induló FASR-rendszerek hogyan tudják elérni a biztonságos magú számítógépek követelményeit:

Biztonsági előnyök	Biztonsági funkciók biztonságos magú számítógépeken
A megbízhatóság hardveralapú gyökerének létrehozása	Biztonságos rendszerindítás
	Megbízható Platform Modul 2.0
	Közvetlen memóriahozzáférés (DMA) elleni védelem
Belső vezérlőprogramszintű támadások elleni védelem (lásd az alábbi megjegyzést)	System Guard Secure Launch (D-RTM) vagy S-RTM (FASR FW)
	Rendszerfelügyeleti mód (SMM) elkülönítése vagy önálló MM mm-felügyelővel (FASR FW)
Az operációs rendszer védelme a nem ellenőrzött kód végrehajtásával szemben	Memóriaintegritás (más néven HVCI)
Speciális identitásellenőrzés és -védelem biztosítása	Windows Hello
Kritikus adatok védelme elveszett vagy ellopott eszközök esetén	BitLocker-titkosítás

Ha a rendszer nem rendelkezik fejlett biztonsági képességekkel a D-RTM támogatásához, a belső vezérlőprogram-védelmi követelmények az S-RTM és az önálló MM és az MM Supervisor kombinációjával teljesíthetők, amelyek közül mindkettőt a FASR belső vezérlőprogram kínálja.

Összefoglalás

Ez néhány olyan befektetés, amelyet a Microsoft a belső vezérlőprogram-támadások növekvő számának kezelésére tett, amelyek ma már elterjedtek az iparágban. Ha nyílt forráskódú kódot használunk ezekhez a változásokhoz, lehetővé tesszük partnereink számára ezen biztonsági előnyök némelyikének használatát, ami pedig a szélesebb körű ökoszisztémát és iparágat fogja előnyben részesíteni.

A Biztonságos magú pc kezdeményezés elsődleges célja annak biztosítása, hogy az ügyfelek hozzáférhessenek a Windows rendszerű számítógépekhez elérhető legfejlettebb biztonsági képességekhez. Néhány ilyen firmware módosítással egy lépéssel közelebb kerülünk a cél eléréséhez, és frissítettük a biztonságos magú számítógépek firmware védelmi követelményeit, hogy tükrözzük ezt a módosítást. További információ a biztonságos magú számítógépekről itt.