Bug in grub2, zwar jetzt gefixt aber peinlich

[schwedenmann]

Hallo


https://www.heise.de/news/BootHole-Bugs ... 59293.html


mfg
schwedenmann

P.S.
Und wieder hat opensource eben nicht dazu geführt, das der Bug aufgespürt wurde, selbst von den grub2 maintainern nicht.

[hikaru]

Und wieder hat opensource eben nicht dazu geführt, das der Bug aufgespürt wurde, selbst von den grub2 maintainern nicht.

Woher weißt du das?

In the course of Eclypsium’s analysis, we have identified a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg).

(Quelle: [1])
Meiner bescheidenen Erfahrung nach hilft es beim Finden von Buffer Overflows ungemein, den Quellcode studieren zu können.


[1] https://eclypsium.com/2020/07/29/theres ... /#breaking

[wanne]

Super Peinlich. GRUB2 hat eine Lücke in einem "Feature", dass sie aktiv bekämpft haben, dass es nicht in den Standard kommt aber auf Druck von MS trotzdem rein kam in debian sowieso abgeschaltet ist und bei MS schon wie oft einen Fehler hatte?

Die fast gleiche Lücke bei MS:
https://cve.mitre.org/cgi-bin/cvename.c ... -2016-3320

Gleiche Auswirkung:
https://cve.mitre.org/cgi-bin/cvename.c ... -2019-1368
https://cve.mitre.org/cgi-bin/cvename.c ... -2019-1294
https://cve.mitre.org/cgi-bin/cvename.c ... 2018-12336
https://cve.mitre.org/cgi-bin/cvename.c ... -2016-3320
https://cve.mitre.org/cgi-bin/cvename.c ... -2016-3287
CVE- mitre hat da mittlerweile sogar eine Kategorie für...

Btw hat sich MS zu keiner Zeit selbst aus dem EFI geschmissen, weil sie passende Lücken hatten. Wir sind mal gespannt, wie das mit GRUB laufen wird.

Und wieder hat opensource eben nicht dazu geführt, das der Bug aufgespürt wurde, selbst von den grub2 maintainern nicht.

Doch.

[schwedenmann]

Hallo

Doch.

ne, eben nciht, der bug ist ja erst duch eine Sicherheitsfirmas (genauer deren team) entdeckt worden und eben nicht von maintainern, oder linuxusern. nach der medlung hat man dann noch 7 andere bugs gefunden, was ja eigentlich, wenn man immer den linuxern glauben soll, schon vorher hätte auffallen müssen.


mfg
schwedenmann

[MSfree]

ne, eben nciht, der bug ist ja erst duch eine Sicherheitsfirmas (genauer deren team) entdeckt worden

Von wem die Bugs entdeckt wurden, ist doch völlig egal. Glaubst du, eine Sicherheitsfirma kann das auch ohne den Quelltext?

[schwedenmann]

Hallo

Von wem die Bugs entdeckt wurden, ist doch völlig egal. Glaubst du, eine Sicherheitsfirma kann das auch ohne den Quelltext?

darum geht es nciht.

Es geht darum, das obwohl open-source, weder der maintainer noch irgendein linux-neerd das entdeckt haben, entgegen der allgemeine meinung hier im DF, das sowas ja eigentlich jeder finden kann, da ja auch jeder den code einsehen kann, was aber offensichtlich (nicht das erste mal) keine Sau tut.
Damit ist doch offensichtlich das opensource eben nciht sicherer ist als closed-source, weil ja jeder den code sich anschauen kann. Was hier noch für mich erschwerend hinzukommt, das der Debian-Maintainer und das Sicherheitsteam das nicht gesehen haben.
Vor diesem Hintergrund (es hat eine Sicherheitsfirma und keine Linuxneerd oder debianmantainer den bug gefunden) ist open-source auch nciht sicherer zu bewerten, wie closed-source.

mfg
schwedenmann

[wanne]

ne, eben nciht, der bug ist ja erst duch eine Sicherheitsfirmas (genauer deren team) entdeckt worden und eben nicht von maintainern, oder linuxusern.

Genau das ist der Vorteil von OpenSource dass eben auch ANDERE Leute den Quelltext lesen und Fehler finden können. Das es die Entwickler selbst können, ist überall so. Das ist ein schönes Beispiel, dass das nicht ausreichend ist.

entgegen der allgemeine meinung hier im DF, das sowas ja eigentlich jeder finden kann, da ja auch jeder den code einsehen kann, was aber offensichtlich (nicht das erste mal) keine Sau tut.

Doch genau das ist passiert. Ein dritter hat den Sorcecode gelesen und einen Fehler gefunden.

Vor diesem Hintergrund (es hat eine Sicherheitsfirma und keine Linuxneerd oder debianmantainer den bug gefunden) ist open-source auch nciht sicherer zu bewerten, wie closed-source.

Logisches Denken ist nicht so deine Stärke was?

hinzukommt, das der Debian-Maintainer und das Sicherheitsteam das nicht gesehen haben.

Maintainer machen keine Sicherheitsaudits sondern sollen bösartige und minderwertige Software erkennen. Ähnlich wie Apple das bei seinem Appstore macht. Und da machen sie bei debian einen verdammt guten Job. Es gab noch keinen Fall von Malware in den Debian-Repos. Beim Appstore der in der Hinsicht als Goldstandard gilt. Haben es sogar schon mehrfach versäuchte Apps in die Top 500 Gescahft und sie werden meist in ganzen Bundeln entdeckt: https://threatpost.com/click-fraud-malw ... re/149496/

[schwedenmann]

Es haben keine auds der Comunity oder von debian oder hier im DF den bug ebntdeckt, ergo liest den Quellcode im grunde keine Sau.

Offensichtlich ja doch. Und wer außer irgend einer Security bude soll sich den Sonst für Devicesecurity interessieren. Wenn jemand im DF so nen Bug gefunden hätte wäre er vermutlich eher froh gewesen und hätte ihn für sich behalten.

Von einer Sicherheitsfirma erwarte ich das sie bugs findet, aber due finden auch bugs in closed-source-code, dafür gibt es afik SS oder sie bekommen den Quellcode geliefert.

Nein. Die hat niemand beauftragt die haben den einfach gefunden. Die hätten niemals den Sorcecode von MS bekommen.

Nein kein Dritter, sonder eine Sicherheitsfirma, kein Neerd, kein mantainer die das ja,nach dem Verständnis von opensource, ein leichtes tun könnten

Der Maintainer wäre eben kein Dritter gewen. Die Sicherheitsfirma ganz sicher schon. Und bei den meisten Sicherheitsfirmen ist der Nerdanteil eher groß.

das waren Profis, eben keien aus der linuxcommunity Die Linuxcommunity besteht fast nur aus Profis:

Hier beispielhaft die Entwickler selbst ~75% Profis: http://www.extremetech.com/wp-content/u ... 937757.jpg
Da arbeiten Firmen (Intel) zusammen, die jede für sich größer als z.B. die größten Softwareentwickler alla MS oder Google sind.

und für die profis ist es egal ob exe oder py hinten steht um die zu lesen.

Und genau das ist Quatsch. Gerade bei Profis ist Schluss wenn es über Sourcecode hinaus geht. Die Mitarbeiter sollen produktiv sein und nicht Jahre damit verbringen irgend welche obfuscatedten Binaries lesen.

[habakug]

Hallo,

Das Ausnutzen dieser Lücken erfordert bereits Root-Rechte oder zumindest physischen Zugang zum System, damit der Angreifer die Datei grub.cfg verändern kann.

Da hat jemand zu tief in den "Schuh" geschaut.

Gruss, habakug

[1] https://www.heise.de/news/BootHole-Bugs ... 59293.html

[Livingston]

Doch genau das ist passiert. Ein dritter hat den Sorcecode gelesen und einen Fehler gefunden.

Nein kein Dritter, sonder eine Sicherheitsfirma

Dritter == Sicherheitsfirma, eigentlich ganz einfach. Dieser Dritte hätte auch schwedenmann heißen können, wenn er sich die Mühe gemacht hätte, das Produkt, welches er täglich benutzt, selbst anhand des Quellcodes zu checken.

Ansonsten empfehle ich den Umstieg auf ein aktuelles MS-Produkt. Da finden die Mitarbeitenden bestimmt jeden Fehler - nur leider kein/e Dritte/r.

[debianuser4782]

Hallo

Doch.

ne, eben nciht, der bug ist ja erst duch eine Sicherheitsfirmas (genauer deren team) entdeckt worden und eben nicht von maintainern, oder linuxusern. nach der medlung hat man dann noch 7 andere bugs gefunden, was ja eigentlich, wenn man immer den linuxern glauben soll, schon vorher hätte auffallen müssen.


mfg
schwedenmann

So weit ich die Sicherheitslücken verstanden habe, geht es doch vor allem um eine Umgehung vom UEFI-Schutz. UEFI wurde in Debian jedoch erst kürzlich mit Buster implementiert.
Vielleicht war zudem der Blick in Richtung "Boot von Linux & Bios-Firmware" auch deshalb etwas nüchtern geblieben, da dort eben vieles de facto closed source ist.

[MSfree]

Hallo,

Das Ausnutzen dieser Lücken erfordert bereits Root-Rechte oder zumindest physischen Zugang zum System, damit der Angreifer die Datei grub.cfg verändern kann.

Da hat jemand zu tief in den "Schuh" geschaut.

Zumal sich diese "Lücke" nur bei eingeschaltetem secure Boot auswirkt. Ohne secure Boot kann man beliebig manipulierte Bootloader und/oder Linuxkernel booten, da steht das Bootsystem sowieso scheunentorweit offen.

[mcb]

Follow up:

"The update for grub2 released as DSA 4735-1 caused a boot-regression
when chainloading another bootlaoder and breaking notably dual-boot with
Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in
version 2.02+dfsg1-20+deb10u2."

[ung]

Es geht noch weiter:

DSA-4867-1 grub2 -- security update
GRUB2 UEFI SecureBoot vulnerabilities - 2021