Információt hoztak nyilvánosságra a GRUB8 rendszerbetöltő 2 sebezhetőségéről, amelyek lehetővé teszik az UEFI Secure Boot mechanizmusának megkerülését és ellenőrizetlen kód futtatását, például a rendszerbetöltő vagy a kernel szintjén futó rosszindulatú programok megvalósítását.
Emlékezzünk vissza, hogy a legtöbb Linux disztribúcióban az UEFI Secure Boot módban történő ellenőrzött rendszerindításhoz egy kis alátétréteget használnak, amelyet a Microsoft digitálisan aláír. Ez a réteg saját tanúsítvánnyal ellenőrzi a GRUB2-t, ami lehetővé teszi, hogy a disztribúciófejlesztők ne rendelkezzenek minden kernel- és GRUB-frissítéssel a Microsoft által tanúsított tanúsítvánnyal. A GRUB2 biztonsági rései lehetővé teszik a kód végrehajtását a sikeres alátétellenőrzést követő szakaszban, de az operációs rendszer betöltése előtt, a bizalmi láncba ékelődve, amikor a biztonságos rendszerindítási mód aktív, és teljes irányítást szerezhet a további rendszerindítási folyamat felett, beleértve másik operációs rendszer betöltése, az operációs rendszer összetevőinek rendszerének módosítása és a zárolás elleni védelem megkerülése.
A tavalyi BootHole sebezhetőséghez hasonlóan a rendszerbetöltő frissítése sem elegendő a probléma blokkolásához, mivel a támadó, függetlenül a használt operációs rendszertől, a GRUB2 régi, digitálisan aláírt, sebezhető verziójával bootolható adathordozót használhat az UEFI Secure Boot feltörésére. A probléma csak a tanúsítvány visszavonási lista (dbx, UEFI Revocation List) frissítésével oldható meg, de ebben az esetben elvész a régi telepítési adathordozó használatának lehetősége Linux alatt.
Frissített tanúsítvány-visszavonási listával rendelkező firmware-rel rendelkező rendszereken csak a Linux disztribúciók frissített buildjei tölthetők be UEFI Secure Boot módban. A disztribúcióknak frissíteniük kell a telepítőket, a rendszerbetöltőket, a kernelcsomagokat, az fwupd firmware-t és az illesztőréteget, új digitális aláírásokat generálva számukra. A felhasználóknak frissíteniük kell a telepítőkészleteket és más rendszerindító adathordozókat, valamint be kell tölteniük egy tanúsítvány-visszavonási listát (dbx) az UEFI firmware-ébe. A dbx UEFI-re való frissítése előtt a rendszer sebezhető marad, függetlenül attól, hogy az operációs rendszerben telepítették-e a frissítéseket. A biztonsági rések állapotát a következő oldalakon lehet felmérni: Ubuntu, SUSE, RHEL, Debian.
A visszavont tanúsítványok terjesztése során felmerülő problémák megoldására a jövőben az SBAT (UEFI Secure Boot Advanced Targeting) mechanizmust tervezik használni, amelynek támogatását a GRUB2, shim és fwupd esetében is megvalósították, és a következő frissítésektől kezdve a dbxtool csomag által biztosított funkciók helyett. Az SBAT-ot a Microsofttal közösen fejlesztették ki, és új metaadatokat adnak hozzá az UEFI-összetevők futtatható fájljaihoz, amelyek a gyártóra, a termékre, az összetevőre és a verzióra vonatkozó információkat tartalmaznak. A megadott metaadatok digitális aláírással vannak hitelesítve, és emellett felvehetők az UEFI Secure Boot engedélyezett vagy tiltott összetevőinek listájára. Így az SBAT lehetővé teszi az összetevők verziószámainak módosítását a visszavonás során anélkül, hogy újra kellene generálnia a biztonságos rendszerindítás kulcsait, és anélkül, hogy új aláírásokat generálna a kernelhez, a shim, a grub2 és az fwupd számára.
Azonosított sebezhetőségek:
- CVE-2020-14372 – A GRUB2 acpi parancsának használatával a helyi rendszeren egy jogosult felhasználó betöltheti a módosított ACPI táblákat úgy, hogy SSDT-t (másodlagos rendszerleíró táblát) helyez el a /boot/efi könyvtárban, és módosítja a grub.cfg fájl beállításait. Bár a Secure Boot mód aktív, a javasolt SSDT-t a kernel hajtja végre, és ezzel letiltható a LockDown védelem, amely blokkolja az UEFI Secure Boot bypass útvonalait. Ennek eredményeként a támadó a digitális aláírás ellenőrzése nélkül elérheti kernelmoduljának betöltését vagy kód futtatását a kexec mechanizmuson keresztül.
- A CVE-2020-25632 az rmmod parancs végrehajtása során felszabadított memória-hozzáférés, amely akkor következik be, amikor egy modult a hozzá kapcsolódó függőségek figyelembevétele nélkül próbálnak kirakni. A biztonsági rés nem zárja ki olyan kihasználás létrehozását, amely a biztonságos rendszerindítási ellenőrzést megkerülő kódfuttatáshoz vezethet.
- CVE-2020-25647 Határon kívüli írás az USB-eszközök inicializálása során meghívott grub_usb_device_initialize() függvényben. A probléma egy speciálisan előkészített USB-eszköz csatlakoztatásával aknázható ki, amely olyan paramétereket állít elő, amelyek mérete nem felel meg az USB-struktúrákhoz lefoglalt puffer méretének. A támadó az USB-eszközök manipulálásával olyan kód végrehajtását érheti el, amelyet a Biztonságos rendszerindítás nem ellenőrzött.
- A CVE-2020-27749 egy puffertúlcsordulás a grub_parser_split_cmdline() függvényben, amelyet 2 KB-nál nagyobb változók megadása okozhat a GRUB1 parancssorban. A biztonsági rés lehetővé teszi, hogy a kódfuttatás megkerülje a biztonságos rendszerindítást.
- CVE-2020-27779 – A cutmem parancs lehetővé teszi a támadó számára, hogy címtartományt távolítson el a memóriából a biztonságos rendszerindítás megkerülése érdekében.
- CVE-2021-3418 – A shim_lock módosításai egy további vektort hoztak létre a tavalyi CVE-2020-15705 biztonsági rést kihasználva. A GRUB2 aláírásához használt tanúsítvány telepítésével a dbx-ben a GRUB2 lehetővé tette bármely kernel közvetlen betöltését az aláírás ellenőrzése nélkül.
- CVE-2021-20225 – Határon túli adatok írásának lehetősége, amikor nagyon sok opciót tartalmazó parancsokat futtat.
- CVE-2021-20233 - Az adatok határokon kívüli írásának lehetősége a pufferméret helytelen kiszámítása miatt idézőjelek használatakor. A méret kiszámításakor azt feltételezték, hogy egyetlen idézőjelből három karakterre van szükség, pedig valójában négyre volt szükség.
Forrás: opennet.ru