Tag Archives: grub.cfg

Wenn Grub nicht mehr bootet

Posted on by

Manchmal haben Bugs eine Geschichte und die Geschichte dieses Grubbugs wird heute erzählt werden.

Wenn Grub nicht mehr bootet

Damit der Eintrag nicht zu lang wird, gibt es nur die Highlights. Nehmt einfach an, daß da noch viel mehr in Spiel war 😉

Vor ein paar Jahren stellte ich auf meinem Fedora Surface Tablet fest, daß trotz dessen, daß neue Kernels installiert wurden, diese nicht im Bootmenü angezeigt wurden bzw. der gewählte Bootkernel nicht benutzt wurde, dafür waren uralte Einträge da drin bzw. nahm er immer den ersten Kernel.

Weil es eine recht neue Installation und das Gerät ein UEFI Bios hatte, wurde eine EFI Partition angelegt und eingebunden, ganz so, wie das sein muß. Auf dieser EFI Partition wird vom OS, hier Fedora, ein passender Ordner angelegt und u.a. der BootShim hingelegt:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 6523 3. Okt 2020 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Wie man sehen kann, liegt hier eine grub.cfg und eine grubenv , diverse Backups durch RPM und mich rum. Die gleichen Dateien findet man unter /boot/grub2/ auch nochmal, dort gehören Sie aber eigentlich auch hin.

Damals passierte folgendes

GRUBBY schrieb die Änderungen der Bootreihenfolge nach /boot/grub2/grubenv , aber GRUB lud die grubenv von /boot/efi/EFI/fedora/grubenv. Das ist die Quintessenz einer langen Investigation.

Die ganze Geschichte war etwas komplizierter, wie man in Bug #1625124 sehen kann.

Die Lösung war damals einfach: eine der Dateien mußt zur Anderen verlinkt werden.

ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv 

Damit waren beide immer in Sync und das von GRUB selbst geschaffene Problem, zwei verschiedene Orte zu benutzen, behoben. Jahrelang blieb der Fix bestehen und das mittlerweile auf Fedora 39 aktualisierte Tablet bootete immer korrekt.. bis diesen Montag 🙁 Da bootete es nicht mehr.

Stattdessen kam nur die GRUB-Shell. Alles reinstallieren vom GRUB-Bootloader, Konfig neu bauen half nichts.Ergo war das ein Fall für Linux am Dienstag, bei dem wir ganz praktisch das Problem besprochen, analysiert, gescheitert und dann final erfolgreich waren \o/

Was war passiert?

Am Wochenende waren Updates eingespielt worden, auch von Kernels und Grub. Was keiner dem Benutzer und damit dem Patch erzählt hat war der Umstand, daß das GRUB Team den 6 Jahre alten Problemfall behoben hat:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 159 20. Sep 18:03 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Achtet mal auf die Größe der grub.cfg : 159 Bytes

Das steht drin:

# cat /boot/efi/EFI/fedora/grub.cfg
search –no-floppy –root-dev-only –fs-uuid –set=dev 0669a2db-8ba9-4054-a629-cd7cf2eb12c8
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Man hat also endlich nur noch einen Ort für die Grub.cfg nämlich /boot/grub2/grub.cfg . Die im EFI Ordner ist jetzt nur noch ein Wrapper, der die eigentliche grub.cfg einbindet, so muß man nur noch eine erzeugen und bleibt rückwärtskompatibel, außer, man hatte das Problem selbst bereits gelöst, dann landete man in der GRUB-Shell, weil …

Wenn die GRUB-Config gebaut wird, wird zuerst der kurze Wrapper /boot/efi/EFI/fedora/grub.cfg erzeugt, DANN erst die /boot/grub2/grub.cfg geschrieben.

Wenn aber /boot/grub2/grub.cfg ein LINK auf /boot/efi/EFI/fedora/grub.cfg ist, dann wird die kurze Fassung durch die Hauptkonfig ersetzt und nagelt dabei den Prefix für das Bootdevice weg. Als Folge kann Grub die Bootpartition nicht mehr finden und bootet nicht mehr.

Lösung:

rm -f /boot/grub2/grub.cfg /boot/grub2/grubenv
grub2-mkconfig > /boot/grub2/grub.cfg
grub2-install –force –target=x86_64-efi /dev/nvme0n1 ( in meinem Fall)

Danach war /boot/efi/EFI/fedora/grub.cfg wieder normal und das System hat endlich wieder gebootet.

Dank nochmal an alle die gestern Abend bei Linux am Dienstag geholfen haben, das war knifflig, aber genau dafür machen wir diese Videokonferenz: Linux basteln 😀

CVE-2021-3981: mysteriöser Security Bug in Grub2

Posted on by

Heute morgen erreicht uns ein mysteriöser Security Bug für Grub2: CVE-2021-3981

CVE-2021-3981: mysteriöser Security Bug in Grub2

Redhat hat ein Update für Grub angeordnet, dessen Sinnhaftigkeit sich nicht sofort erschließt:

grub2: Incorrect permission in grub.cfg allow unprivileged user to read the file content [fedora-all]

Der eigens dafür kreierte CVE 2021-3981 gibt leider nichts her. Durchsucht man die Portale nach Informationen stößt man lediglich auf einen Verweis von Ubuntu ins Jahr 2008:

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/248843

Dabei handelt es sich im einen Fehler in Tiger, einem Intrusion Detection Tool, daß auch für Security Audits benutzt werden kann. Dieses hatte im Jahr 2008 herausgefunden, daß die /boot/menu.lst und andere Files, Gruppenleserechte haben, was gefährlich sein könnte, wenn ein unprivilegierter User in der dazugehörigen Gruppe ist und in der Datei ein Passworthash gespeichert wird, was mir bislang gar nicht bekannt war, daß das irgendwie Sinn machen würde.

Zehn Jahre später

Im Jahr 2018, wurde der Fehler dann endgültig behoben. Jetzt, Ende 2021, taucht bei Fedora ein ähnliches Problem auf. Die grub.cfg hatte wohl Weltleserechte, was im Falle eines Passworts ein Sicherheitsproblem wäre, käme ein unprivilegierter User da dran. Probier wir das doch mal:

[marius@eve ~]$ ls -la /boot/grub2/
ls: Öffnen von Verzeichnis ‚/boot/grub2/‘ nicht möglich: Keine Berechtigung

Egal wie die Leserechte auf der grub.cfg aussehen, ein unprivilegiert Benutzer kommt da nicht dran, weil /boot/grub2/ einen chmod von 700 hat.

Daher überrascht dieser Security Bug, der im Redhat Customerportal nur für „bezahlende“ Kunden erreichbar ist, ein bisschen, weil sich dadurch keine Lücke ergeben kann. Soweit man in den spärlichen Quellen sehen kann, wird die Lücke auch mit der Gefährlichkeit LOW eingeordnet, aber wenn das so ist, und eh nur root dran kommt an die Datei, wieso dann eine CVE erstellen?

Falls das jemand aufklären kann, könnt Ihr ja einen Kommentar da lassen.

Boothole – Ja, und?

Posted on by

Ähm.. ich fühle mich geradezu .. ähm.. genötigt.. auch was zum Grubproblem zu schreiben:

Ja, und?

Als ich bei Heise das erstmal davon gelesen hatte, ging mir nur das Satzfragment „ja,und?“ durch den Kopf? Was bitte ist an einer Lücke mit der einen PC „übernehmen“ kann, für die man aber schon Root sein muß, besonders? Naja, nichts. Wenn ich schon durch einen Hack Root wurde, dann brauche ich diese Lücke nicht mehr, weil ich schon drin bin. Wenn man diese Lücke von außen per physischem Zugriff ausnutzen kann, dann brauche ich das auch nicht mehr, denn dann hatte ich schon den Zugriff auf den PC mit allem was drauf ist, denn die meisten haben keine Festplattenvollverschlüsselung. Ich kann als Angreifer also nicht nur den Bootbereich, sondern alles ändern, wenn ich das wollte.

Es bleibt also nur die eine Kombination übrig, für die das ein Problem ist: Systeme mit Verschlüsselung + physikalischem Zugriff  und hier auch nur die, wo /Boot unverschlüsselt ist.

Jetzt ist das mit dem physischem Zugriff so eine Sache, denn was bitte hindert mich daran, einen Bootloader auf die Platte zu bannen und dem Bios des Pcs zusagen, es soll Legacy booten, ergo der Secureboot ist nicht mehr im Spiel? Ein BIOS-Passwort vielleicht? Nicht wirklich, weil physischer Zugriff meint halt auf alles, ich könnte als Angreifer also auch mit genug Zeit, das Mainboard austauschen und so das Biospasswort umgehen, oder ich resette das einfach.

Antwort von Euch: „Dann schließ das Gehäuse halt ab.“ .. ja, das ist so.. ich war mal bei den deutschen Meisterschaften im Schlösserknacken dabei ( Zuseher ) und naja, so sicher wie man glaubt,  sind Schlösser gar nicht. Türschlösser z.b. sind in unter 3 Sekunden geöffnet. Es gibt sogar einen Sportverein der sich ganz der Schlossknackkunst verschrieben hat. Wenn uns das eins lehrt: Schlösser sind kein Hindernis für Profis und die (baulich)einfachen Schlösser von PC Gehäusen oder ausm Baumark schon gar nicht.

Merke.. wer physischen Zugriff auf Euren PC hatte, stellt IMMER ein unkalkulierbares Risiko da. Daher kann einen diese Lücke nicht wirklich schrecken. Spannender wird die Frage, wie M$ das nötige Secure-Bootupdate für die Sperre alter Grub Shims verteilen möchte, weil ohne das, ist der Fix oder nicht Fix komplett unwichtig 😀