staging.inyokaproject.org

Hinweis auf geänderte Voreinstellung für os-prober seit GRUB 2.06 mit Ubuntu 22.04

kB schrieb:

Hinweis auf geänderte Voreinstellung für os-prober seit GRUB 2.06 mit Ubuntu 22.04

os-prober wurde ja nicht einfach so deaktiviert, sondern aufgrund von Sicherheitsproblemen:

https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00120.html

Hat jemand eine Ahnung, wie ein Angriff über os-prober im Detail genau ablaufen müsste? Ich habe dazu im Netz bisher nicht wirklich viel gefunden, außer ein paar Behauptungen, die dann aber auch nicht weiter erklärt oder hinterfragt werden.

Z.B. hier: https://www.phoronix.com/forums/forum/software/distributions/1297328-ubuntu-developers-figuring-out-dual-boot-changes-ahead-of-ubuntu-22-04-lts?p=1297347#post1297347

The security issue is bogus on many levels. It requires physical access to the system for exploitation.

Wird behauptet, aber nicht weiter erklärt.

LG, Newubunti

Newubunti schrieb:

kB schrieb:

Hinweis auf geänderte Voreinstellung für os-prober seit GRUB 2.06 mit Ubuntu 22.04

os-prober wurde ja nicht einfach so deaktiviert, sondern aufgrund von Sicherheitsproblemen

Das hat aber nichts mit der GRUB-Konfiguration zu tun und ist daher aus Sicht dieses Wiki-Artikels nicht relevant. Hier geht es nur um eine geänderte Voreinstellung für eine Konfigurationsvariable, die überraschenderweise das langjährig gewohnte Verhalten (d.h. fremde Betriebssysteme werden als zusätzliche Starteinträge ins GRUB-Menü eingebunden) ändert.

Bei einer Installation von Ubuntu 22.04 hat man nun ein unterschiedliches Verhalten, je nachdem, ob man von einer früheren Version upgraded oder Ubuntu frisch als einziges System installiert oder Ubuntu neben einem bereits installierten Betriebssystem frisch installiert. Chaos Vielfalt statt Klarheit.

Ob die Ursache für diese Änderung tatsächlich ein Sicherheitsproblem beseitigt, darüber kann man streiten. Es betrifft ohnehin nur Rechner, bei denen "secure boot" aktiviert ist und deren Betreiber auch ausdrücklich Wert auf dieses Feature legt. Für "secure boot", welches diesen Namen auch verdient, ist erforderlich, dass alle Komponenten der Boot-Kette signiert sind und jede Komponente den Start eines nicht signierten Nachfolgers verweigert:

• Rechner Firmware (vulgo "UEFI", enthält vom Hersteller signierten Schlüssel von Microsoft)

• der vom Bios gestartete primäre Bootmanager (bei Ubuntu-Systemen: shim.efi, signiert von Microsoft)

• shim.efi startet etwas, was grub64x.efi heißt und wenn das tatsächlich ein GRUB ist, dann ist der auch von Ubuntu signiert.

• GRUB startet dann irgendetwas aus seinem Menü oder etwas, was ihm der Bediener per Kommandozeile vorgibt. Wenn das ein Ubuntu-Linux-Kernel ist, dann ist er von Ubuntu signiert oder nicht.

• GRUB lädt außerdem eine zum Kernel passende initrd.img. Diese ist niemals signiert. Und diese enthält Software, Software und noch mehr Software, die alle nicht signiert sind, aber während des Bootvorgangs ausgeführt werden.

Die Signaturkette ist also an mehreren Stellen löchrig.

Wenn man nun os-prober benutzt, erscheinen für die fremden Betriebssystem weitere Startmöglichkeiten im Menü. Die Kernel dieser anderen Betriebssystem können signiert sein oder auch nicht oder sowieso aus der Hölle stammen und weder GRUB noch dessen Wartungssystem können das prüfen.

Also: Wer os-prober benutzt, schafft sich dadurch in der sehr wahrscheinlich (und bei Ubuntu ganz sicher) bereits löchrigen Signaturkette möglicherweise weitere Löcher. Um dieser potentielle Gefahr einer weiteren Verschlechterung entgegenzuwirken, ändert man nur die Voreinstellung des eigentlich völlig unschuldigen os-prober (denn der findet ja nur andere Betriebssysteme), indem man ihn vorsichtshalber nicht automatisch startet. Das muss dann der Anwender selbst ändern, damit man sich der großen Gefahr bewusst wird.

Das eigentliche Sicherheitsproblem ist GRUB selber, denn der startet etwas ohne Prüfung der Signatur.

Wenn man bei Linux wirkliches "secure boot" haben will,

• muss man von der UEFI-Firmware direkt den signierten Linux-Kernel starten lassen.

• Dafür muss man es aber erst einmal schaffen, dass die Schlüssel von Ubuntu auch in der Firmware hinterlegt werden.

• Und man muss selber seine initrd.img signieren und die eigenen Schlüssel ebenfalls in der Firmware hinterlegen.

• Und man muss in der initrd.img eine Routine einbauen, welche selber die initrd.img überprüft.

Das ist nichts, was man einem generellen, weitgehend automatisch ablaufendem Installateur für Laien zuverlässig anvertrauen kann, sondern Handarbeit für kenntnisreiche Fachleute.

Also Augenwischerei und Lügen in die Täsch. Aber eins ist sicher: Das Chaos ist jetzt größer.

Wem dagegen "secure boot" egal ist oder wer das sogar einfach deaktiviert hat, braucht fast gar nichts zu ändern und lebt auch mit oder ohne os-prober weder sicherer noch unsicherer als früher. Man muss sich nur merken, dass man bei Bedarf den os-prober in der Datei /etc/default/grub aktiviert und ggf. das Paket installiert. (Und das sagt einem der neue Hinweis im Wiki nun.)

kB schrieb:

Newubunti schrieb:

kB schrieb:

Hinweis auf geänderte Voreinstellung für os-prober seit GRUB 2.06 mit Ubuntu 22.04

os-prober wurde ja nicht einfach so deaktiviert, sondern aufgrund von Sicherheitsproblemen

Das hat aber nichts mit der GRUB-Konfiguration zu tun und ist daher aus Sicht dieses Wiki-Artikels nicht relevant.

Das sehe ich anders. Wenn ich etwas nun gegebenenfalls umkonfigurieren, weil es zuvor anders konfiguriert war, dann macht es schon einen Unterschied für meine Entscheidung, ob die Änderung einfach nur auf Designentscheidungen der Grub-Entwickler zurückgehen oder ob es dafür Sicherheitsgründe gibt.

In diesem Fall werden Sicherheitsgründe genannt. Da ist dann interessant zu wissen, ob das jeden betrifft oder nur manche etc.. Auf Grundlage dieses Wissens kann ich dann eine vernünftige Entscheidung treffen, ob ich die Konfiguration wieder ändere oder ob ich den Empfehlungen der Entwickler folge und dafür vielleicht Komforteinbussen in Kauf nehme.

Wenn eine Konfiguration einen Sicherheits-relevanten Hintergrund hat - der hier gegeben ist - dann sollte das im Wiki IMO auch erwähnt werden.

Diese Information vollständig zu unterschlagen halte ich für mindestens fahrlässig.

Allerdings, um es vernünftig benennen zu können und nicht einfach nur zu verunsichern, muss man den Angriffsvektor erst mal verstanden haben und das habe ich persönlich z.B. noch nicht.

Ob die Ursache für diese Änderung tatsächlich ein Sicherheitsproblem beseitigt, darüber kann man streiten.

Kann man wie gesagt erst, wenn man den/die Angriffsvektoren kennt und versteht. Und genau darauf bezog sich meine Frage.

Deine ganzen Ausführung zur Secure-Boot im allgemeinen helfen da auch nicht weiter.

Danke!

LG, Newubunti

Newubunti schrieb: […]

Ich schlage Dir zum Training Deiner offenbar schlecht entwickelten Fähigkeit zum Text-Verständnis vor, die von Dir zitierte Ankündigung der Änderung gründlicher zu lesen. Dort steht:

The os-prober is enabled by default what may lead to potentially dangerous use cases and borderline opening attack vectors. This patch disables the os-prober, adds warning messages and updates GRUB_DISABLE_OS_PROBER configuration option documentation. This way we make it clear that the os-prober usage is not recommended.

Denke darüber nach, warum hier die markierten Worte verwendet werden!

In meiner vorherigen Antwort habe ich versucht, Dir dazu einige Hintergrundinformationen zu vermitteln. Leider ist mir das misslungen.

Ich entnehme der Ankündigung:

• Es gibt keinen konkreten Angriffsvektor.

• Rein theoretisch kann aber die Möglichkeit nicht ausgeschlossen werden, dass os-prober auch ein bereits installiertes böses oder auch nur nicht signiertes Betriebssystem findet und dieses dann jemandem, der Zugang zum Grub-Menü hat, als Menüpunkt anbietet und dieser Bediener könnte es dann ganz einfach starten. (Auch ohne so einen Menüpunkt könnte ein Bediener dieses böse Betriebssystem starten, müsste dann aber GRUB über die Kommandozeile bedienen und dafür auch das Wissen haben.)

• Da GRUB bekanntlich (?) auch nicht signierte Kernel starten kann, wäre damit auch eine möglicherweise erwünschte Maßnahme "secure boot" durchbrochen.

Damit das GRUB-Projekt sich nicht dem Vorwurf aussetzt, es würde etwas per Vorgabe aktivieren, was "secure boot" durchbrechen könnte, wird nun os-prober nicht mehr per Vorgabe aktiviert. Dazu macht man es dem unterstellten Angreifer, der bereits physischen Zugang zum Rechner hat, etwas schwieriger.

Man kann os-prober wieder einschalten, muss das allerdings auch tun und dadurch wird dem Benutzer ja klar, dass er nun kein Secure-Boot-System mehr hat. (Diese Logik des GRUB-Teams trifft zwar zu, ist aber wohl für die Mehrheit der Nutzer nicht offensichtlich.)

Wer das Konzept "secure boot" nicht verwendet, für den verbessert sich natürlich das Sicherheitsniveau seines Systems in keiner Weise.

Es gibt nun Warnungen in der offiziellen Dokumentation von GRUB (Die im Artikel verlinkt ist, damit sie vom Anwender leicht gefunden werden kann und gelesen wird!) vor einer abstrakten Gefahr, die es schon immer gegeben hat und die es auch weiterhin gibt.

Newubunti schrieb:

Das sehe ich anders. Wenn ich etwas nun gegebenenfalls umkonfigurieren, weil es zuvor anders konfiguriert war, dann macht es schon einen Unterschied für meine Entscheidung, ob die Änderung einfach nur auf Designentscheidungen der Grub-Entwickler zurückgehen oder ob es dafür Sicherheitsgründe gibt.

In diesem Fall werden Sicherheitsgründe genannt. Da ist dann interessant zu wissen, ob das jeden betrifft oder nur manche etc.. Auf Grundlage dieses Wissens kann ich dann eine vernünftige Entscheidung treffen, ob ich die Konfiguration wieder ändere oder ob ich den Empfehlungen der Entwickler folge und dafür vielleicht Komforteinbussen in Kauf nehme.

Wenn eine Konfiguration einen Sicherheits-relevanten Hintergrund hat - der hier gegeben ist - dann sollte das im Wiki IMO auch erwähnt werden.

Finde ich irgendwie auch !

Allerdings, um es vernünftig benennen zu können und nicht einfach nur zu verunsichern, muss man den Angriffsvektor erst mal verstanden haben und das habe ich persönlich z.B. noch nicht.

Dies im Wikiartikel ausführlich nachvollziehbar zu erklären, halte ich allerdings für überzogen. Wie wär's mit? :

Durch die neue Konfiguration wird die \[GRUB-eigene Umgehung passender_Link\] von secure boot, falls aktiviert, erschwert, welche aber auch so nicht 100-prozentig verhindert werden kann.

UlfZibis schrieb:

Newubunti schrieb:

[…] In diesem Fall werden Sicherheitsgründe genannt.

Nein. Das GRUB-Team nennt eben keinen Sicherheitsgrund.

[…] Wenn eine Konfiguration einen Sicherheits-relevanten Hintergrund hat - der hier gegeben ist […]

Welcher sicherheitsrelevante Hintergrund ist denn angeblich hier gegeben? Ein Patch wird lediglich Sicherheitsupdate tituliert, ist aber kein solcher.

[…] Durch die neue Konfiguration wird die GRUB-eigene Umgehung von secure boot,

Was soll das bitte sein?

falls aktiviert, erschwert, welche aber auch so nicht 100-prozentig verhindert werden kann.

GRUB startet einen Kernel eines Betriebssystems – das ist seine Aufgabe. Er macht es unter Durchbrechung des Konzeptes "secure boot" – das ist nun mal seine Art. Man kann damit ganz gut leben, solange man ohne das Konzept "secure boot" auskommt. Wenn man es aber haben möchte, geht es nicht mit GRUB und dieser komische Patch ändert daran gar nichts.

kB schrieb:

[…] Durch die neue Konfiguration wird die GRUB-eigene Umgehung von secure boot,

Was soll das bitte sein?

Man könnte auch sagen, Grub hebelt secure boot aus, weil es eben alles ungeprüft starten kann.

falls aktiviert, erschwert, welche aber auch so nicht 100-prozentig verhindert werden kann.

GRUB startet einen Kernel eines Betriebssystems – das ist seine Aufgabe. Er macht es unter Durchbrechung des Konzeptes "secure boot" – das ist nun mal seine Art. Man kann damit ganz gut leben, solange man ohne das Konzept "secure boot" auskommt. Wenn man es aber haben möchte, geht es nicht mit GRUB und dieser komische Patch ändert daran gar nichts.

Wenn z.B. ein malinges USB-Medium eingesteckt ist, fügt der OS-Prober dieses dem Grub-Menü hinzu, und dann kann GRUB das System auf diesem Medium starten. Ohne OS-Prober hätte des nicht passieren können.

... oder habe ich Deine ausführliche Erklärung falsch verstanden?

Hej,

um mit grub ein O/S starten zu können, brauch man os-prober nicht! (und allein das Anstecken bewirkt noch lange keine Änderung des grub-Menü)

Aktuell ist es so, daß os-prober bei einer Erstinstallation (eines Ubuntu) dieser auch die Anwesenheit weiterer O/S feststellt und ins Menü einbindet. (btw., auch ubiquity prüft ja die Existenz anderer O/S auf der/n Platte/n, sonst könnte ein "Ubuntu neben ...installieren" nicht funktionieren, tut es aber) Siehe auch → post 9305821 von tk87

Gruß black tencate

black_tencate schrieb:

um mit grub ein O/S starten zu können, brauch man os-prober nicht!

Dann muss man das OS aber manuell in die grub.cfg reinfrickeln oder die GRUB-Konsole bemühen. Wer das beherrscht, braucht sowieso keine Sicherheitsvorkehrungen.

(und allein das Anstecken bewirkt noch lange keine Änderung des grub-Menü)

Hat das jemand behauptet? Ich dachte wir wären hier unter Fachleuten, denen man nicht alles extra ausführen muss. Denk' Dir also ein "der manuell gestartet wurde" dazu.

kB schrieb:

• GRUB startet dann irgendetwas aus seinem Menü oder etwas, was ihm der Bediener per Kommandozeile vorgibt. Wenn das ein Ubuntu-Linux-Kernel ist, dann ist er von Ubuntu signiert oder nicht.

kB schrieb:

GRUB startet einen Kernel eines Betriebssystems – das ist seine Aufgabe. Er macht es unter Durchbrechung des Konzeptes "secure boot" – das ist nun mal seine Art.

Also unter Ubuntu startet GRUB im Secure Boot Modus nicht einfach Starteinträge für unsignierte Kernel die zuvor von os-prober entdeckt wurden, z.B. ein solchen für ein Ubuntu das nur im UEFI-Modus ohne Secure Boot installiert wurde.

So banal ist es also nicht.

UlfZibis schrieb:

Dies im Wikiartikel ausführlich nachvollziehbar zu erklären, halte ich allerdings für überzogen.

Die Frage diente auch erst mal nur meinem eigenen Verständnis, um dann abschätzen zu können ob und wie weit das im Wiki erwähnt werden sollte.

LG, Newubunti

UlfZibis schrieb:

[…] Wenn z.B. ein malinges USB-Medium eingesteckt ist, fügt der OS-Prober dieses dem Grub-Menü hinzu, und dann kann GRUB das System auf diesem Medium starten. Ohne OS-Prober hätte des nicht passieren können.

... oder habe ich Deine ausführliche Erklärung falsch verstanden?

Ja, hast Du offenbar. Ich habe nichts derartiges behauptet. Tatsächlich hat der Bootmanager GRUB überhaupt gar nichts mit os-prober zu tun und benutzt ihn auch nicht beim Startvorgang. Und durch das Einstecken eines USB-Datenenträgers werden zwar möglicherweise temporäre Boot-Einträge im Menü des UEFI-Bootmanagers aus dem Bios hinzugefügt, aber ganz sicher nicht im GRUB-Menü.

os-prober wird nur vom GRUB-Wartungssystem im installierten Linux-Betriebssystem benutzt (oder eben auch nicht), um in der statischen Datei grub.cfg Menüeinträge zu erstellen. Wenn zu diesem Zeitpunkt ein USB-Stick eingesteckt ist, dann werden bei entsprechender Konfiguration des GRUB-Wartungssystems auch für diesen Menüeinträge erstellt.

Oh Mann, steht Ihr alle auf dem Schlauch. Ich meinte natürlich:

1. USB-Medium einstecken.

2. Warten, bis im Hintergrund die automatische Aktualisierung ausgeführt wird, ODER update-grub manuell ausführen.
   Falls os-prober installiert UND in /etc/default/grub aktiviert ist (vor 22.04 Standard) wird damit automatisch ein neuer Eintrag in der grub.cfg erzeugt.
   (Genau das meinte ich mit: "fügt der OS-Prober dieses dem Grub-Menü hinzu".)

3. Rechner neu starten.

4. Potentiell unsicheres System auf dem USB-Medium kann ausgewählt und gestartet werden, egal ob secure boot aktiviert ist oder nicht (= GRUB-eigene Umgehung/Aushebelung von secure boot).

5. Zusätzlich wird unabhängig von GRUB im UEFI-Bootmenü ein Eintrag erzeugt, womit das OS vom USB-Stick aber nur gestartet werden kann, wenn entweder secure boot deaktiviert ist oder/und das OS auf dem USB-Stick signiert ist. Dieser Weg kann aber nur genutzt werden, wenn im BIOS das UEFI-Bootmenü aktiviert ist, bzw. der Benutzer Zugang zum BIOS-Setup hat, was "versehentlich" nicht passieren und durch ein BIOS-Passwort gesperrt werden kann.

Somit wird durch den neuen Standard ab 22.04 verhindert, dass ein unsigniertes System mehr oder weniger versehentlich vom weniger erfahrenen Nutzer ausgeführt wird. Klassisches Beispiel: Schüler im Schulungsraum steckt USB-Medium oder CD/DVD in einen Rechner und verursacht damit absichtlich oder versehentlich Schaden.

Immer noch falsch verstanden ???

UlfZibis schrieb:

[…] Immer noch falsch verstanden ???

Ja. In keinem Fall (weder vor nach nach dieser Änderung noch nach Rücknahme der neuen Voreinstellung und auch nicht, wenn Weihnachten auf den 30. Februar fällt) wird durch os-prober unautorisiert ein wie auch immer gearteter Menüeintrag dem GRUB-Menü hinzugefügt. Immer muss dazu ein Lauf von

sudo update-grub 

(oder Äquivalent) durchgeführt werden, und der Systemadministrator root sollte wissen, was er/sie will und tut.

Newubunti schrieb:

[…] Also unter Ubuntu startet GRUB im Secure Boot Modus nicht einfach Starteinträge für unsignierte Kernel die zuvor von os-prober entdeckt wurden, z.B. ein solchen für ein Ubuntu das nur im UEFI-Modus ohne Secure Boot installiert wurde.

Bist Du Dir da ganz sicher? Das wäre mir nämlich neu, dass sich GRUB so verhält. Es widerspricht meiner Erfahrung; allerdings kann ich nicht ausschließen, dass dies tatsächlich inzwischen verbessert wurde und meine Erfahrung damit überholt wäre.

Ich glaube das aber nicht, weil:

• Wenn es sich so verhielte, wie Du schreibst, gibt es ja keine Motivation mehr für eine Änderung der Voreinstellung für os-prober mehr, denn ein von os-prober angelegter Menüeintrag ohne "secure boot" würde ja bei aktiviertem "secure boot" nicht funktionieren. Es wäre also bestenfalls ein kosmetisches Problem. Davon steht aber in der Patch-Ankündigung nichts.