„Súlyos hiba történt” – figyelmeztetnek a dual-boot rendszerek a Microsoft frissítése után

Múlt kedden több Linux-felhasználó – sokuk az év elején kiadott csomagokat használva – jelentette, hogy a gépük nem indul el. Ehelyett egy rejtélyes hibaüzenetet kaptak, amely a következő mondatot tartalmazta: „Súlyos hiba történt.”

Ok: A frissíteni A Microsoft ezt a frissítést a havi javítás részeként adta ki. Le akarták zárni Gyengeség két éves korban be grubegy nyílt forráskódú rendszertöltő, amelyet számos Linux-eszköz indítására használnak. A sérülékenység 10-ből 8,6-os súlyossági pontszámmal lehetővé tette a hackerek számára, hogy megkerüljék a Secure Boot funkciót, amely az iparági szabvány biztosítja, hogy a Windows vagy más operációs rendszert futtató eszközök ne töltsenek be firmware-t vagy rosszindulatú programokat a rendszerindítási folyamat során. A CVE-2022-2601-et 2022-ben fedezték fel, de tisztázatlan okokból a Microsoft csak múlt kedden javította ki.

Sok új és régi operációs rendszer érintett

A keddi frissítés következtében a kettős rendszerindítású eszközök – vagyis azok, amelyek Windows és Linux futtatására is konfigurálva vannak – nem tudtak az utóbbiról elindulni, amikor a Secure Bootot kényszerítették. Amikor a felhasználók megpróbálták betölteni a Linuxot, a következő üzenetet kapták: „SBAT alátét adatellenőrzés sikertelen: Biztonsági szabályzat megsértése. Súlyos hiba történt: SBAT önellenőrzés sikertelen: Biztonsági szabályzat megsértése.” Szinte azonnal támogatja és vita Fórumok világított -vel Jelentések Alárendelt megbukni.

„Ne feledje, hogy a Windows azt mondja, hogy ez a frissítés nem vonatkozik a Windows és Linux operációs rendszerre” – írta egy csalódott személy. „Ez nyilvánvalóan nem igaz, és valószínűleg a futó rendszer konfigurációjától és disztribúciójától függ. Úgy tűnik, hogy emiatt egyes linux efi shim rendszerbetöltők nem kompatibilisek a microcrap efi rendszerbetöltőkkel (ezért működik az MS efi-ről a shim-re való váltás) „egyéb operációs rendszer” az efi beállításban). Úgy tűnik, hogy a Mint rendelkezik egy alátét-verzióval, amelyet az MS SBAT nem ismer fel.”

A jelentések szerint számos disztribúció, köztük a Debian, az Ubuntu, a Linux Mint, a Zorin OS és a Puppy Linux egyaránt érintett. A Microsoft még nem ismerte el nyilvánosan a hibát, nem magyarázta el, hogy a tesztelés során miért nem fedezték fel, és nem adott technikai útmutatást az érintettek számára. A cég képviselői nem válaszoltak a választ kérő e-mailre.

A Microsoft CVE-20220-2601-es közleménye kifejti, hogy a frissítés települ kóma— Linux-mechanizmus a rendszerindítási útvonal különböző összetevőinek felülbírálására – de csak a Windows futtatására konfigurált gépeken. Ily módon a Windows rendszerű gépeken a Secure Boot nem lesz sebezhető a sérülékenységet kihasználó GRUB-csomagot hordozó támadásokkal szemben. A Microsoft biztosította a felhasználókat, hogy a kettős rendszerindítású rendszereiket ez nem érinti, bár figyelmeztette, hogy a Linux régebbi verzióit futtató gépeken problémák léphetnek fel.

„Az SBAT érték nem vonatkozik a Windows és Linux rendszert egyaránt futtató kettős rendszerindító rendszerekre, és nem érinti ezeket a rendszereket” – áll a közleményben. „Elképzelhető, hogy a régebbi Linux-disztribúciók ISO-fájljai nem működnek. Ha ez megtörténik, lépjen kapcsolatba Linux-szállítójával a frissítés beszerzéséhez.”

Valójában a modernizáció Megvan Windowst és Linuxot is futtató eszközökön valósul meg. Ez nem csak a kettős rendszerindító eszközöket foglalja magában, hanem a Linuxot futtató Windows-eszközöket is ISO képVagy USB-meghajtót vagy optikai adathordozót. Ezen túlmenően, sok érintett rendszeren nemrégiben kiadott Linux-verziók futnak, köztük az Ubuntu 24.04 és a Debian 12.6.0.

Most mi van?

Mivel a Microsoft elkötelezte magát a vezeték nélküli csend mellett, a hiba által érintettek kénytelenek voltak saját megoldásokat találni. Az egyik lehetőség az EFI kártya elérése és a biztonságos rendszerindítás kikapcsolása. A felhasználó biztonsági igényeitől függően előfordulhat, hogy ez a lehetőség nem elfogadható. A legjobb rövid távú megoldás az SBAT törlése, amelyet a Microsoft múlt kedden tolt. Ez azt jelenti, hogy a felhasználók továbbra is részesülnek a Secure Boot előnyeiből, még akkor is, ha továbbra is sebezhetők a CVE-2022-2601 kódot kihasználó támadásokkal szemben. Ennek a kezelésnek a lépéseit elmagyarázták itt (Köszönjük Manothing (Referenciaként).

A konkrét lépések a következők:

1. Tiltsa le a Biztonságos rendszerindítást
2. Jelentkezzen be Ubuntu felhasználójához, és nyissa meg a terminált
3. Törölje az SBAT szabályzatot a következővel:

kód: Válassza ki az összeset

sudo mokutil –set-sbat-policy delete

4. Indítsa újra a számítógépet, és jelentkezzen be az Ubuntuba az SBAT-házirend frissítéséhez
5. Indítsa újra, majd engedélyezze újra a Secure Boot funkciót a BIOS-ban.

Ez az incidens a legutóbbi, amely rávilágít arra, hogy a Secure Boot milyen rendetlenné vált, vagy talán mindig is az volt. Az elmúlt 18 hónap során a kutatók legalább négy sebezhetőséget fedeztek fel, amelyeket kihasználva teljesen le lehet győzni a biztonsági mechanizmust. Az előző közelmúltbeli incidens a közel 500 eszközmodell biztonságos rendszerindítási hitelesítéséhez használt tesztkulcsok eredménye. A kulcsokon jól láthatóan a „Ne bízz” felirat szerepelt.

„Végső soron, bár a Secure Boot biztonságosabbá teszi a Windows működését, úgy tűnik, hogy egyre több olyan hiba van benne, amelyek nem teszik annyira biztonságossá, mint tervezték” – mondta Will Dorman, az Analygence biztonsági cég vezető biztonsági elemzője. „A SecureBoot rendetlenné válik, mert nem csak a Microsoft játéka, pedig náluk vannak a királyság kulcsai. A SecureBoot komponensben lévő bármilyen sérülékenység csak a SecureBootot támogató Windows-okat érintheti. Ezért a Microsoftnak kezelnie kell/blokkolnia kell a sebezhető dolgokat.”