Fedora & Kernel 6.3.4 und die nichtendenwollende Geschichte mit Nvidia

Ich bin ja gestern Abend schon gewarnt worden, daß das Kernel 6.3.4 Update Probleme bringen würde, aber hey, ich hatte doch damals im Januar, als Kernel 6.1.5 plötzlich mit schwarzem Bildschirm bootete, schon alles in Grub so geändert, daß es bereits funktioniert hat! Trotzdem hatte ich heute morgen einen schwarzen Bildschirm vor mir. Tja.

„Ups, we did it again“ ?

Ich erspare Euch mal viel Geschreibsel zur Suche, aber Ihr solltet vorher das hier gelesen haben:

Fedora: „Nein, es ist keine Verschwörung die User zum HW Wechsel zu bekommen.“

Heute morgen hatte ich also genau das gleiche Fehlerbild: schwarzer Bildschirm beim Booten. Passworteingabe blind.

Die Ursache war eine falsch zusammengebaute BLS Config, die sich aus den Grubdefaults ( /etc(/default/grub ) eine Kommentarzeile reingezogen hat, die aber seit dem Januarvorfall auskommentiert ist:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=“$(sed ’s, release .*$,,g‘ /etc/system-release)“
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
#GRUB_TERMINAL_OUTPUT=“console“
#GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init“
GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau“
GRUB_DISABLE_RECOVERY=“true“
GRUB_VIDEO_BACKEND=vbe
GRUB_FONT_PATH=/boot/grub2/fonts/unicode.pf2
GRUB_GFXMODE=0x11b
GRUB_GFXPAYLOAD_LINUX=“keep“
GRUB_TERMINAL_OUTPUT=“gfxterm“
#GRUB_GFXMODE=“1440x900x32″
GRUB_ENABLE_BLSCFG=true

Nachdem das aus der BLS Configdatei für Kernel 6.3.4 raus war, funktionierte es auch wieder. Entscheidend war das hier „initcall_blacklist=simpledrm_platform_driver_init„, welches den Init vom SimpleDRM System verhindert hat. Scheinbar wurde endgültig der Support der alten Treiber, die durch die falsche gebaute Config immer noch benutzt wurden, endgültig aus dem Kernel entfernt. Damit die BLS Config dann wieder richtig geschrieben wird, muß die Kommentarzeile raus und grub2-mkconfig ausgeführt werden. Da in der /boot/grub2/grub.cfg aber die richtige Zeile drinstand, ist das schon ein sehr kurioser Fehler vom grub2-mkconfig.

Für Euch: Immer genau hinsehen, ob etwas wirklich so ist, wie es sein sollte.

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

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.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Eine wichtige Ressource für alle, denen der Grub2 Security Fix ihrer Distribution das Booten sabotiert hat, ist:

https://docs.pagure.org/docs-fedora/the-grub2-bootloader.html

Die ist zwar für Fedora, aber da steht alles in Kleinarbeit drin, wie man Bootloaderprobleme selbst behebt.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Für alle != Fedora oder RH basierten Distris gelten die gleichen Schritte nur die Pakete heißen anders.

Das Vorgehen ist immer das Gleiche:

1. Von einem USB Stick booten
2. die lokale Systemplatte mounten
3. chroot /*mount_systemplatte*
4. /boot/ einhängen
5. mit dem hoffentlich eingerichteten Netzwerk die alte Grubversion aus dem Repo ziehen.

Beispiel DNF:  „dnf downgrade shim grub2*“

6.  grub2-install /dev/sda

wobei /sda  das richtige Laufwerk von Eurer Systemplatte sein muß, müßt Ihr mal schauen wie das heißt.

7. aus der chroot raus, alles unmounten, rebooten .. sollte wieder gehen.

Für alle, die das mit dem alten Grub2 Paket nicht hinbekommen, auf der LIVE-Disk die Ihr dafür benutzt IST einen alter Grub2 drauf! Den könnte man auch mal direkt versuchen 😉

Wenn Ihr EFI bootet, dann braucht es auch den passenden shim im /boot/efi/ Pfad, das ist schliesslich der Auslöser des Übels gewesen 😉  Und oh Freude, auch der ist schon passend zum Grub2 auf der Livedisk drauf, braucht man nur kopieren.

Noch etwas: Für Fedora gibt es noch kein Grub2 Update, nicht mal im Alpha Stadium. Die wissen schon wieso 😉 (hoffe ich)