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.

Linux am Dienstag: Das Weihnachtsmeeting 2021

Liebe Linuxfreunde,

es weihnachtet wieder und deswegen ist es Zeit für die Abschlussveranstaltung 2021 von Linux am Dienstag \o/

Linux am Dienstag: Das Weihnachtsmeeting 2021

Heute, 21.12., ab 19 Uhr haben wir natürlich wieder Linux und Opensource im Fokus u.a. mit diesen Themen:

Kernel – Wenn die Firmware nicht mehr laden will
Sicherheit – Log4J geht in Runde 4
Sicherheit – Schwachstellen in Xorg gefunden
Sicherheit
– Eine Woche keine Chromelücke

Fedora – Carola goes Repo

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Kleine Anmerkung: Die bisherigen Vorträge findet man jetzt unter https://linux-am-dienstag.de/archiv/ .

Fedora 34: Wenn Wifi weg ist…

Wenn das Wifi auf einem Tablet nicht mehr geht, ist man gewöhnlicherweise am Allerwertesten, aber es gibt vielleicht Hilfe für Euch.

Fedora 34: Wenn Wifi weg ist…

Mein Surface Tablet war mal wieder dran mit seinem Update, weil Netflix mit dem „alten“ Firefox von vor 3 Wochen nicht mehr spielen möchte, also gab es das sowieso fällige Fedora 34 Update. Das hätte ich besser nicht gemacht, denn nun habe ich Gnome 40+ und mein Tablet ist jetzt gehandycrapt. *sniff*

Aber bevor das neue Gnome überhaupt zum Problem werden konnte, überraschte mich Fedora 34 damit, daß mein Tablet kein Wifi mehr hatte, dabei hatte ich gar keinen neuen Kernel benutzt, sondern den gleichen Surface Kernel gebootet, wie sonst auch.

Bei näherer Betrachung stellte ich das hier raus:

Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: enabling device (0000 -> 0002)
Dez 18 13:59:00 surface kernel: mwifiex_pcie: try set_consistent_dma_mask(32)
Dez 18 13:59:00 surface kernel: mwifiex_pcie: PCI memory map Virt0: 00000000938ad086 PCI memory map Virt2: 0000000061c369a5
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: Direct firmware load for mrvl/pcie8897_uapsta.bin failed with error -2
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: Failed to get firmware mrvl/pcie8897_uapsta.bin
Dez 18 13:59:00 surface kernel: mwifiex_pcie 0000:02:00.0: info: _mwifiex_fw_dpc: unregister device

Und jetzt steht Ihr da genauso wie ich. WTF is pcie8897_uapsta.bin? ok, eine Firmware für den Chip. Soweit so gut. Aber wieso kann der Kernel das File (das in dem Listing unten) nicht mehr laden??

[ ~]$ ls -la /usr/lib/firmware/mrvl
insgesamt 5320
drwxr-xr-x. 3 root root 4096 30. Nov 21:18 .
drwxr-xr-x. 102 root root 36864 2. Dez 09:11 ..
-rw-r–r–. 1 root root 444052 28. Okt 15:33 pcie8897_uapsta.bin.xz
-rw-r–r–. 1 root root 287784 28. Okt 15:33 pcie8997_wlan_v4.bin.xz
-rw-r–r–. 1 root root 388188 28. Okt 15:33 pcieuart8997_combo_v4.bin.xz
-rw-r–r–. 1 root root 392276 28. Okt 15:33 pcieusb8997_combo_v4.bin.xz
drwxr-xr-x. 2 root root 4096 30. Nov 21:18 prestera
-rw-r–r–. 1 root root 165260 28. Okt 15:33 sd8688.bin.xz
-rw-r–r–. 1 root root 1804 28. Okt 15:33 sd8688_helper.bin.xz
-rw-r–r–. 1 root root 330112 28. Okt 15:33 sd8797_uapsta.bin.xz
-rw-r–r–. 1 root root 164668 28. Okt 15:33 sd8801_uapsta.bin.xz
-rw-r–r–. 1 root root 377276 28. Okt 15:33 sd8887_uapsta.bin.xz
-rw-r–r–. 1 root root 439804 28. Okt 15:33 sd8897_uapsta.bin.xz
-rw-r–r–. 1 root root 370612 28. Okt 15:33 sdsd8977_combo_v2.bin.xz
-rw-r–r–. 1 root root 381952 28. Okt 15:33 sdsd8997_combo_v4.bin.xz
-rw-r–r–. 1 root root 297988 28. Okt 15:33 usb8766_uapsta.bin.xz
-rw-r–r–. 1 root root 342532 28. Okt 15:33 usb8797_uapsta.bin.xz
-rw-r–r–. 1 root root 162968 28. Okt 15:33 usb8801_uapsta.bin.xz
-rw-r–r–. 1 root root 446100 28. Okt 15:33 usb8897_uapsta.bin.xz
-rw-r–r–. 1 root root 371036 28. Okt 15:33 usbusb8997_combo_v4.bin.xz

Ja… das dauert ne Weile, deswegen langweile ich Euch ( grummel…neuer xz algo… brabbel ) nicht damit und komme zum Wesentlichen: xv -d pcie8897_uapsta.bin.xz ; reboot  \o/ GEHT \o/

Als erstes sucht der Kernel nach der ungepackten Version der Firmware, wenn es die nicht gibt, dann nimmt er auch eine gepackt. Leider gabs da wohl ein Update und der bisherige Kernel kann die XZ komponente zum Entpacken nicht mehr benutzen und damit die Firmware nicht mehr laden. Durch das Auspacken der Firmware nimmt das mehr Platz weg, aber kann wieder geladen werden. Hat man dazu Worte? 🙁