CleanPress

Schlagwort: GRUB2

  • GRUB 2.0.6 deaktiviert os_prober

    GRUB2 verfügt über eine Funktion zur Einbindung des externen Programms os-prober, um andere, auf demselben Rechner installierte Betriebssysteme zu erkennen und entsprechende Menüeinträge für diese zu erzeugen. Diese Funktion wurde seit dem Frühjahr mit dem Einzug von GRUB 2.0.6 bei vielen Distributionen standardmäßig deaktiviert, da die automatische Ausführung von os-prober und die Erstellung von Booteinträgen auf der Grundlage dieser Daten ein potenzieller Angriffsvektor ist, sofern Secure Boot genutzt wird.

    Das Sicherheitsproblem besteht, weil os_prober mit Root-Rechten per grub-mount alle Partitionen booted, um nach anderen Betriebssystemen zu suchen. Dieses Szenario könnte ausgenutzt werden, um dem System etwa einen modifizierten Kernel unterzuschieben oder Lücken im Dateisystem auszunutzen. Die GRUB-Entwickler bezeichnen die Situation als borderline attack vector.

    Abschaltung bei Ubuntu 22.04

    Zuletzt wurde os_prober in Debian Sid deaktiviert, Anwender von Debian Stable erreicht diese Änderung erst mit Debian 12 »Bookworm«. Für Ubuntu-Anwender kommt die Änderung bereits mit Ubuntu 22.04, wie omg!ubuntu! berichtet. Anwender können aber im Jahr 2022 erwarten, dass bei Dual- oder Multi-Boot-Systemen die weiteren Betriebssysteme automatisch erkannt und in GRUB eingebunden werden. Das wird aber durch die Deaktivierung von os_prober verhindert. Die Maßnahme betrifft Anwender von UEFI und herkömmlichem BIOS unterschiedlich. UEFI-Nutzer können ein anderes Betriebssystem (aber kein 2. Ubuntu) aus dem UEFI-Bootloader heraus starten, was beim herkömmlichen BIOS nicht funktioniert.

    Die Ubuntu-Entwickler überlegen nun, wie sie der Situation begegnen können, ohne os_prober wieder einzuschalten. Es wird überlegt, os_prober nur einmal bei der Installation laufen zu lassen oder die Optionen des UEFI-Bootloaders im GRUB-Menü einzublenden.

    Alternative für Anwender

    Falls es bei der Abschaltung ohne Alternative bleiben sollte, können Anwender os_prober selbst wieder einschalten, indem sie in /etc/default/grub die Zeile GRUB_DISABLE_OS_PROBER=false einfügen oder von true auf false abändern. Anschließend ist der Befehl update-grub notwendig, um die Änderung einzulesen. Bei Arch und seinen Derivaten lautet der Befehl grub-mkconfig -o /boot/grub/grub.cfg, bei Fedora und Red Hat kommt bei BIOS grub2-mkconfig -o "$(readlink -e /etc/grub2.cfg)" zum Einsatz, bei UEFI ist es grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg. Eine weitere Möglichkeit steht erfahreneren Anwendern offen. Sie können weitere Betriebssystem manuell in /etc/grub.d/40_custom eintragen.

  • GRUB 2.06 endlich mit LUKS2-Unterstützung

    Der Release-Plan der Entwickler des Bootmanagers GRUB aka Grand Unified Bootloader sieht jährliche Veröffentlichungen vor. Somit stand GRUB 2.06 für 2020 an und der Plan war, das Update bis zur Jahresmitte zu veröffentlichen. Mit rund einem Jahr Verspätung wurde GRUB 2.0.6 nach einem RC im März aber erst jetzt freigegeben.

    Aus Gründen…

    Der hauptsächliche Grund für die Verspätung sind die Patches für die Sicherheitslücken BootHole/BootHole2, die bisher nicht in einer stabilen GRUB-Version enthalten waren. Das hatte zur Folge, dass Entwickler die Patches auch auf ältere, nicht mehr unterstützte Versionen von GRUB angewandt haben, was zu schwerwiegenden Problemen führen konnte.

    Acht weitere Lücken

    Weiter zur Verspätung beigetragen haben acht Sicherheitslücken, die in der Folge von Boothole im März 2021 entdeckt wurden. Die als GRUB2 Secure Boot Bypass 2021 bezeichneten Lücken waren in der Lage, UEFI Secure Boot auszuhebeln. Um kompromittierte Komponenten zeitnah per UEFI Revocation sperren zu können, wurde von Microsoft und der Linux Community das UEFI Secure Boot Advanced Targeting-Modell (SBAT) entwickelt, dass nun in GRUB 2.0.6 integriert ist. Die ursprünglichen Boothole-Patches ebenso integriert wie die überfällige Unterstützung für GCC 10 und Clang/LLVM 10.

    LUKS2-Volumes unterstützt

    Was die neuen Entwicklungen für GRUB 2.0.6 betrifft, so sticht die Unterstützung für verschlüsselte LUKS2-Volumes heraus. Des Weiteren wurde Unterstützung für die Xen-Sicherheitsmodule XSM und FLASK eingebaut sowie ein Backup/Restore-Tool. Die externe Anwendung os-prober, die dazu dient andere auf demselben Rechner installierte Betriebssysteme zu erkennen und entsprechende Menüeinträge für diese zu erzeugen, ist mit GRUB 2.0.6 aus Sicherheitsgründen deaktiviert, da die automatische und stille Ausführung einen Angriffsvektor darstellt. Der Quellcode von Grub 2.06 ist auf der Projekt-Website verfügbar, wo auch die Dokumentation zu GRUB 2.0.6 zu finden ist.

  • Schwierige Reparatur von BootHole

    Screenshot von AWS auf Launchpad von Jeff Turner

    Bei dem Versuch, mit einer neuen Grub-Version die Sicherheitslücke BootHole zu stopfen, melden Anwender verschiedener Distributionen Systeme, die nach dem Update nicht mehr hochfahren. Dabei spielen, wie es aussieht, unterschiedliche Umstände eine Rolle. Zu den betroffenen Distributionen zählen Ubuntu, Debian, Linux Mint, Red Hat und CentOS. Fedora dagegen scheint nicht betroffen.

    Red Hat, aber nicht Fedora

    Bei Red Hat wurde ein Update für GRUB und den Kernel angeboten, was bei aktualisierten Systemen gleich nach den POST-Meldungen und noch vor GRUB zum Hängen der Systeme führte. Manchmal half das Ausschalten von Secure Boot, um den Rechner hochfahren zu lassen. Wenn das nicht funktioniert, muss in einer Chroot GRUB wieder de-aktualisiert werden. Der Fehler wurde zunächst in grub2-efi-x64 vermutet, was sich aber als falsch herausstellte. Schuld war in Wirklichkeit das Paket shimx64.efi.

    Debian Testing noch verwundbar

    Debian hat ein ausführliches Statement zu BootHole veröffentlicht, aus dem bereits hervorging, dass erwartet wird, dass Systeme nach den nötigen Updates nicht mehr starten könnten. Davon seien älterer Systeme bei Verwendung von BIOS anstatt UEFI sowie Dual-Boots mit Windows und Linux betroffen. Bei letzteren kann Linux den Systemstart verweigern.

    Noch gestern Abend wurde für Debian Stable das GRUB2-Paket 2.02+dfsg1-20+deb10u2 freigegeben, dass das Problem behebt. Demnach sind Buster und Sid abgesichert, Bullseye, also der derzeitige Testing-Zweig dagegen nicht.

    Ubuntu und Mint

    Bei Ubuntu gibt es im Launchpad einen Bug-Report der dort derzeit 25 Rechner betrifft, die mit BIOS installiert wurden. Diese verweigern den Start mit der Meldung error: symbol `grub_calloc' not found und werfen den Nutzer in eine GRUB-Shell. Weitere Betroffene wendeten sich an die Plattform Ask Ubuntu, um das Problem zu lösen. Dort wurde untrer anderem Boot-Repair zur Behebung des Problems vorgeschlagen.

    Offensichtlich war sich der Paketmanager dpkg im unklaren, wohin GRUB2 beim Update zu installieren sei. Als Lösung wurde in einer Chroot der Befehl dpkg-reconfigure grub-pc empfohlen, dem dann das korrekte Device zur Installation von GRUB2 mitgegeben werden muss.

    Ubuntu auf allen Ebenen betroffen

    Der Fehler betrifft zumindest Ubuntu 18.04 und 20.04. Auch von Azure, AWS EC2 und Ubuntu Server gab es gleichlautende Meldungen. Bei Linux Mint 20 machten Anwender die gleiche Erfahrung. Canonical hat Problem und derzeitige Lösung ausführlich im Wiki beschrieben.

    Auch SUSE hatte ausführlich über BootHole berichtet, hier sind mir allerdings bisher keine Meldungen über nicht startende Rechner bekannt.

  • Es ist ein Loch im Schuh…

    Foto: Gia Oris on Unsplash

    In den letzten Tagen geisterte eine Sicherheitslücke durch die Medien, die auf den Namen BootHole getauft wurde und die Katalognummer CVE-2020-10713 erhielt. Dort hieß es beispielsweise, es seien Millionen (potenziell sogar Milliarden) Geräte betroffen und das unter Linux wie unter Windows und auch dann, wenn Secure Boot eingeschaltet sei.

    Wenn das Kind erstmal im Brunnen ist…

    Das ist so weit alles richtig. Was dann aber im Text nur beiläufig erwähnt wird, ist, dass zur Ausnutzung der Lücke Root-Rechte benötigt werden. Hat ein Angreifer aber bereits Root-Rechte, kann er machen, was er möchte.

    GRUB2-Konfiguration manipuliert

    Was war passiert? Die Sicherheitsfirma Eclypsium hatte im April 2020 eine Lücke entdeckt, die über die Manipulation der Konfigurationsdatei grub.cfg des Bootloaders GRUB2 oder generell bei Maschinen mit aktiviertem Secure Boot das Einschleusen von Schadcode ermöglicht. Die technischen Hintergründe vermittelt der Artikel There’S A Hole In The Boot.

    Zwei Hacks notwendig

    Schadcode im Bootprozess ist sehr gefährlich, da sind wir uns einig. Dort installierte Malware wie etwa ein Bootkit kann unter Umständen lange unentdeckt bleiben und ermöglicht uneingeschränkte Kontrolle der befallenen Geräte. Aber wie bereits erwähnt, muss man zur Manipulation der Datei grub.cfg Root-Rechte besitzen, die normalerweise nur durch einen vorausgehenden Hack zu erhalten sind.

    GRUB2 ist meist signiert

    Der Zusammenhang mit Secure Boot entsteht dadurch, dass GRUB2 bei allen großen Distributionen mit Secure Boot signiert ist. Dazu verwenden Distributionen eine kleine Datei, die als Shim bezeichnet wird. Dieser enthält den Code, um den Bootloader zu verifizieren. Dieser Shim wird beim Start gegen die UEFI-CA von Microsoft verifiziert, bevor der Shim den GRUB2-Bootloader lädt und verifiziert.

    Heap-Overflow

    Ist die grub.cfg entsprechend manipuliert, kann per BootHole Code eingeschleust werden, da der Parser in GRUB2 nicht ordnungsgemäß beendet wird, wenn ein Fehler entdeckt wird,
    was zum erzeugen von Pufferüberläufen im Heap-Datenbereich genutzt werden kann. Ein Angreifer kann dadurch bereits vor dem eigentlichen Start des Systems Code ausführen. auf diesem Weg kann beispielsweise Ransomware untergeschoben werden.

    8,2 von 10

    Das ist zweifelsohne eine gefährliche Lücke, die deshalb auch mit 8.2 von 10 möglichen Punkten beim CVSS-Index bewertet wurde. Die Angaben zur tatsächlichen Gefährdung sind aber nach meinem Dafürhalten mal wieder weit übertrieben und kommen mit markigen Überschriften dem Marketing von Eclypsium zugute.

    Weitere Lücken entdeckt

    Aber die Beschäftigung von allen großen Distributoren mit dem Problem förderte weitere sieben Sicherheitsprobleme bei GRUB2 ans Licht, die gleich mit beseitigt werden konnten. Angepasste Versionen von GRUB2 sind teilweise bereits erstellt und in Kürze einspielbar.

    Lücke gefährlich – Gefährdung gering

    Wir müssen uns wegen BootHole um unsere privaten Rechner wohl kaum Sorgen machen, denn zwei notwendige Attacken erscheinen hier nicht lohnenswert. Cyber-Gangster kennen weniger aufwendige Wege, unsere Rechner in ihre Botnetze zu integrieren. Rechner mit sensiblen Informationen im Enterprise-Umfeld sollten über geeignete Maßnahmen wie TPM oder PureBoot den Bootprozess absichern. Oder seht ihr das anders?