BootHole - GRUB2 sebezhetőség nyithat utat a Window és Linux rendszereken való tetszőleges kódfuttatás előtt

Bug

 

 

Részletek itt. A Debian projekt figyelmeztetője itt. Red Hat figyelmeztető itt.

( Caro | 2020. 07. 30., cs – 09:05 )

Szoktuk mondani, hogy ha valaki egy géphez hozzáfér....

A secure boot meg semmit nem ér, soha nem értettem hogy minek erőltetni. 1992-t írunk, hogy boot vírusoktól tartunk, vagy mi?

Ezzel nagyon egyetértek, kb. csak önszopatásra jó a Secure Boot. Persze én GRUB-ot se használok, a Linuxaim UFI stub vagy UEFI systemd-boot-tal bootolnak, kiválóan meg lehet lenni nem csak Windows, nem csak secure boot, de GRUB nélkül is. Ezt csak ilyen tudományos fantasztikumnak írom, hogy ilyenről is terjedjen a városi legenda, hogy ijesztgetni tudják vele a kisgyerekeket lefekvés előtt.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( Vamp | 2020. 07. 30., cs – 09:22 )

Ma jott frissites grub-hoz, Ubuntu serveremen. Gyanitom ezt fixalja.

( prion | 2020. 07. 30., cs – 11:03 )

Elég sok ember lehet most boothurt.

( asch v | 2020. 07. 30., cs – 11:15 )

TLDR valaki? Hogy lehet kihasználni? Indításkor bennfelejtett kraftolt pendrive kell hozzá? EFI partícióra írt ellenséges dolgok? User módban futó  program meg tudja csinálni? Böngészőben futó webalkalmazás meg tudja csinálni?

Nincs nagy veszély!

Adott támadónak root jogosultság kell adott gépen, hogy a grub.cfg-t módosítsa, hogy az betöltéskor buffer overflow-al tetszőleges kódot futtasson boot-kor. Ehhez vagy fizikálisan már van hozzáférése megfelelő joggal, vagy egyéb hibákat kihasználva kell jogosultságokat szereznie, de akkor célzottabb a támadás, mert ismerni kell, hogy adott komponensek milyen verzión futnak és milyen sebezhetőségeik vannak.

Ráadásul még arra is rá kell venni az áldozat gépét, hogy az újrainduljon.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

a grub.cfg-t módosítsa

Akkor ennyi erovel a kernelt is ki tudja cserelni, vagy a bootloadert. Az egyetlen eset amikor szamithat ez hogyha secure bootod van mert akkor azzal idaig nem tudtal barmit betolteni, de most mar kb igen. Es a grub update nem old meg semmit, attol a regi grub alairasa valid marad amig a disztrok nem allnak at uj certre es revokoljak a regit a biosbol a userek. Viszont van fizikai hozzaferesed a gephez, akkor amugy is at tudod allitani a biost, szoval a secure boot ott se er sokat, ha meg remote szerezett root jogot a tamado akkor meg eleve vegtelen lehetosege van a kartekony program elrejtesere.

Ez alapjan nekem egy kicsit tulhypeoltak tunik ez a bejelentes.

I hate myself, because I'm not open-source.

Es a grub update nem old meg semmit, attol a regi grub alairasa valid marad amig a disztrok nem allnak at uj certre es revokoljak a regit a biosbol a userek.

Idézet a linkelt Red Hat oldalról:

Remediation

Red Hat recommends all customers to update their grub2 packages. Red Hat customers using Secure Boot need to update kernel, fwupdate, fwupd, shim and dbxtool packages containing newly validated keys and certificates.

Users running Secure Boot with Red Hat Enterprise Linux 8 need to take additional steps to boot into previously released RHEL 8 kernels after applying the grub2 package updates. See the RHEL 8 section below for more details.

...

Red Hat Enterprise Linux 8

Due to hardening within the kernel, which is released as part of these updates, previous Red Hat Enterprise Linux 8 kernel versions have not been added to shim’s allow list. If you are running with Secure Boot enabled, and the user needs to boot to an older kernel version, its hash must be manually enrolled into the trust list.

Valamint:

Viszont van fizikai hozzaferesed a gephez, akkor amugy is at tudod allitani a biost

Simán lehet root hozzáférésed a rendszerhez (akár legálisan, akár egy privilege escalation vulnerabilityn keresztül), miközben a bios-hoz nincs hozzáférésed.

Ha esetleg dual (vagy több) boot a rendszer, akkor ezzel így nem csak a támadott rendszerhez lehet hozzáférni, hanem bármelyikhez. Vagy akár BIOS módosítást is lehet injektálni és akkor hiába telepíted újra a rendszert vagy dobod ki a merevlemezt, a kód még ott van...

Nem tudok elképzelni olyan esetet, hogy ezt így kihasználják, de a lehetőség megvan.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

A dual boot meg valid pont lehet, pl valami keylogger szeruseget felrakni ami ellopja a full disk encryption passwordot. A BIOS-t mondjuk nem ertem, a grub-nak pontosan ugyan annyi joga lesz piszkalni a bios beallitasai kozott mint a linuxnak (legrosszabb esetbe valami custom kernel modul fog kelleni hozza, de ha root vagy akkor azt is be lehet tolteni).

I hate myself, because I'm not open-source.

( Pene | 2020. 07. 30., cs – 15:18 )

Amelyik sérülékenységnek nincs saját arculati kézikönyve, dedikált weboldala, logója és grafikái, az annyit is ér. Ergo ezt komolyan kell venni :)

( _Franko_ v | 2020. 07. 30., cs – 18:33 )

Tehát bejutok, valahogy root jogosultságom lesz, hogy átírjam a grub.cfg-t, ami majd kódot injektál, de amúgy le tudom cserélni a Grub-ot a régire, ha közben frissítették egy jó változatra. Hol tévedek? :)

https://iotguru.cloud

Sebezhető Windowsból kiindulva eddig ilyen könnyen nem lehetett kompromittálni a másik dualboot Linuxot, különösen drive titkosítás mellett. 

Abban igazad van, hogy egy rendszeres Linuxnál ha már írás jogot tudott szerezni a támadó a grubhoz akkor már tényleg mindegy. 

Nem olvastam még mélyen utána a témának, de szerintem úgy logikus ha grub fixálással párhuzamosan a Linux kernelt is módosítjuk.  Azaz friss Linuxot nem tudja betölteni a régi még javítatlan grub. Bár nyilván ez is sok kellemetlenséget okoz, de csak így lehet hatékonyan javítani ezt a sérülékenységet. 

Idézet a cikkből: "The boot process naturally involves a variety of players and components including device OEMs, operating system vendors, and administrators. Given the fundamental nature of the boot process, any sort of problems run a high risk of rendering a device unusable. As a result, updates to Secure Boot are typically slow and require extensive industry testing."

Szerintem ez érkezhet firmware update-tel, meg gondolom arra is van lehetőség, hogy konfigurálással vegyen fel valaki új elemet a tiltott szignatúrák listájára.

( asch v | 2020. 07. 31., p – 02:41 )

Lazán kapcsolódik, de érdemes időnként felemlegetni, hogy mi is ez a secure boot valójában?

Richard Stallman szavai innen kimásolva: http://bytesmedia.co.uk/2012/07/17/richard-stallman-uefi/

"In any case, what secure boot does is that it causes the machine to only work with (?) programs that are signed with a certain key, your keys. And as long as the user controls which keys they are, then it’s a security feature. However, it can be chained into a set of digital handcuffs when the user doesn’t control the keys. And this [is] happening.

Microsoft demands that ARM computers sold for Windows 8 be set up so that the user cannot change the keys; in other words, turn it into restricted boot. Now, this is not a security feature. This is abuse of the users. I think it ought to be illegal."

Addig jó nekünk, ameddig meg lehet törni a secure bootot. Ha már majd nem lehet megtörni, akkor eggyel nagyobb fokozatba kapcsolnak, és egyszerűen letilthatnak minden home brew oprendszert, amiben például nincsen "telemetria". Olyanok lesznek a számítógépek, mint a teleképek. Nem lesz LineageOS, meg /e/, meg QubesOS!

Ennek a secure boot mániának az a következő lépése, amikor egy villanyóra mellé szánt, totál leplombált eszközön is megkövetelik a secure boot-ot. Köznyelven hívhatjuk ezt az eszközt "bojler kapcsolónak".

Kérdem én, ha már a plombát feltörik, akkor nem tudja ugyanúgy lopni az áramot? De ő biztos majd az oprendszert akarja feltörni :D

Azt kellene már az agyakba vésni, hogy a bizalmi láncon alapuló rendszerek megbízhatatlanok (ez egyébként a társadalomban is így van). Melyiket nem törték eddig fel? Elég ha egyszer kikerül a master key, és ez már annyi esetben megtörtént a DVD lejátszóktól kezdve a netes tanúsítókig...

Másrészről, ha hozzáférek a géphez, egyszerűen kiveszem belőle a lemezt, aztán azt csinálok vele amit akarok. Vagy bedugok egy USB keyloggert... asztali gépen ki fogja észrevenni? Majd a következő a secure keyboard lesz, lefogadom :D

mindezt ahelyett, hogy átállnánk egy olyan titkosítási rendszerre, amit nem lehet megkerülni, mint a smartcard