A Secure Boot lényege és halálos rései
A Secure Boot-ot eredetileg azért vezették be 2012-ben, hogy a firmware-támadások, főleg az úgynevezett bootkitek ellen védjék a számítógépeket. Egy sikeres támadó, ha rövid időre hozzáfér egy eszközhöz – akár kikapcsolt állapotban is – telepíthet bootkitet, ami az operációs rendszer alatt, közvetlenül a hardveren fut, és gyakorlatilag láthatatlan a legtöbb védelem számára. Az elmúlt években többször is lelepleztek ilyen támadásokat, többek között orosz állami hackerek használták ki ezt a sérülékenységet. De nemcsak a Windows, hanem számos Linux-disztribúció – például a Red Hat, az openSUSE vagy az Oracle – is beépített shim-eket, azaz áthidaló programokat, amelyek a Secure Boot-ot rugalmasabbá tették.
Mindezek dacára ha egy támadó kézbe kap egy még érvényes, de már rég hibásnak minősített régi shim-et, gyakorlatilag hatástalaníthatja a védelmet. Elég némi alapszintű UEFI-ismeret ahhoz, hogy a Secure Boot teljesen feleslegessé váljon a gépen.
Mi is az a shim, és miért ilyen óriási a hiba?
A shim-ek szerepe, hogy közvetítőként működjenek a Secure Boot és más szoftverek, például különféle Linux-segédprogramok között. Ezeket a Microsoft írja alá, de a tanúsítványlánc a lemezen is továbbvihető, és az alaplap- vagy szoftvergyártókhoz kötődik. Ha a shim-et valaha hibásnak találják, a Microsoftnak vissza kellene vonnia. Azonban a most felfedezett 11 shim-et másfél évtized során sem vonták vissza, így a kihasználhatóság máig fennállt.
Ugyanis minden rendszerindításkor a gép ellenőrzi az engedélyezett és tiltott tanúsítványok adatbázisát (db/dbx). Linux-rendszerek esetén azonban fizikai korlátok miatt nem lehet minden egyes komponenst felsorolni, ezért alternatív visszavonási módszereket – például SBAT (Secure Boot Advanced Targeting) és SVN (Secure Boot Security Version Number) – is alkalmaznak. Ezekkel inkább egész hibás szoftvergenerációkat tiltanak le, mint egyes aláírásokat.
A gond csak az, hogy az érintett shim-ek nem jártak ekkora szigorúsággal: sokukat még azelőtt írták, hogy ilyen védelem létezett volna, mások hibás programkódot tartalmaznak, vagy korábbi, hibás verziókat engednek be a rendszerbe. Ezáltal minden bootfolyamat során egy régi, soha vissza nem vont shim-en keresztül teljesen kompromittálható a védett rendszer.
Miért ilyen nehéz kijavítani a hibát?
A Secure Boot rendszer bonyolultsága önmagában is növeli a hibalehetőségek számát. Minden komponens saját metaadatot, tanúsítványt és generációs azonosítót hordoz, amelyeket célzottan kellene tiltani. Ehhez azonban hatékony frissítési, új politikákat bevezető (például SbatLevel) és metaadatkezelő mechanizmusokra lenne szükség – de ezek bevezetésével és karbantartásával mostanáig gondok voltak.
Szintén nehezíti a helyzetet, hogy a Microsoft által 2019-ben használt aláíró tanúsítványok lejárata sem volt elegendő ahhoz, hogy az ESET kutatói által felfedezett hibás shim-eken keresztül történő betöréseket megállítsák.
A hibás shim-ek és a sebezhetőség következményei
Az ESET által azonosított problémás shim-ek olyan másodlagos komponenseket is beengedhetnek a rendszerbe, amelyekről régóta tudott, hogy sebezhetőek. Például az Oracle-hez köthető shim egy közismerten hibás binárist enged át, és ezek kihasználása csupán alacsony technikai tudást igényel. Más shim-ek nem támogatják az újabb védelmi listákat (például MOK tiltólista [deny-list] vagy SBAT), sőt, magukban is tartalmaznak sebezhetőségeket, amelyek korabeli, már akkor is aggályos kódrészletektől származnak.
Egyes Windows- és Linux-változatok alapból nem érintettek – például a Windows 11 Secured-core PC-k –, de kizárólag azok a felhasználók vannak biztonságban, akik 2026 júniusában telepítették a Microsoft frissítéseit. Linux-felhasználók esetén tanácsos sürgősen konzultálni az adott disztribúció készítőivel, és ellenőrizni, hogy a saját rendszerükön mely shim-ek tiltódtak le.
A Secure Boot modell teljes kudarcot vallott?
Nem túlzás azt mondani, hogy ez az eset kemény kritikát jelent a Secure Boot modell egészére nézve. Nagyságrendben több ezer, hivatalosan is aláírt, de valójában kompromittált állomány lehet még most is forgalomban, hiszen az aláírások kezelése, a rendszer bonyolultsága és a Microsoft központi szerepe miatt szinte lehetetlen átlátni a teljes ökoszisztémát. Mindezt ráadásul súlyosbítja, hogy a legfontosabb hibák nem új, kreatív támadások, hanem évtizedes, egyszerűen elfelejtett visszavonások miatt jöttek létre.
A végeredmény egy sok helyen lyukas, kiszámíthatatlan és jelen formájában megbízhatatlan biztonsági rendszer. Sürgős változtatásra, gyakorlatilag teljes újratervezésre van szükség, különben a Secure Boot hosszabb távon inkább hamis védettséget, mint valódi biztonságot jelent.
