BootHole-Schwachstelle gefährdet Linux und auch Windows Secure Boot

[English]Im GRUB2-Bootloader wurden mehrere Schwachstellen entdeckt, die sowohl Linux-System, aber auch den in Windows verfügbaren Secure Boot aushebeln und so Systeme gefährden können.


Anzeige

GRBU2 erlaubt unsichtbare Malware

Sicherheitsforscher der auf Firmware- und Hardware-Schwachstellen spezialisierten Sicherheitsfirma Eclypsium sind im GRUB2-Boot-Loader auf einen Pufferüberlauf (CVE-2020-10713) gestoßen. Dieser hängt mit der Art und Weise zusammen, wie GRUB2 Inhalte aus seiner Konfigurationsdatei “grub.cfg”, die sich extern in der EFI-Systempartition befindet, analysiert. Angreifer könnten die “grub.cfg” modifizieren, weil es eine einfache Textdatei ist. Es ließe sich vom Boot-Loader beliebige Software laden. Die Änderung der Konfigurationsdatei von GRUB ermöglicht dem Angreifer die Kontrolle über den Bootvorgang. Bleeping Computer hat diesen Beitrag zum Thema verfasst und ZDNet bereitet es in nachfolgendem Tweet auf.

Dort werden auch die betroffenen Geräte thematisiert. Die Linux-Distributoren arbeiten inzwischen an Patches, die eine digitale Signatur für die Dateien einführen. Das dürfte aber ein langer Weg werden.

Ergänzung: Sophos hat diesen Blog-Beitrag veröffentlicht, wo die Situation von Sicherheitsexperten analysiert wird. Die geben auch einige Hinweise, was zu tun ist.

Ergänzung 2: RHEL, CentOS, Debian und andere Distributionen haben reagiert und Patches bereitgestellt. Die Kollegen von heise haben hier was zusammen geschrieben.

Microsoft warnt ebenfalls

Auf Twitter bin ich auf nachfolgende Information gestoßen, nach der die Schwachstelle in GRUB2 auch den Secure Boot von Windows-Systemen beeinträchtigen kann.

Microsoft hat diesen Beitrag veröffentlicht, in dem man Hinweise und Anleitungen zum Umgang mit BootHole gibt. Microsoft ist sich einer Schwachstelle im GRand Unified Boot Loader (GRUB) bewusst, der von Linux häufig verwendet wird. Diese Schwachstelle, bekannt als “There’s a Hole in the Boot”, könnte eine sichere Umgehung des Bootvorgangs ermöglichen.

Um diese Schwachstelle auszunutzen, müsste ein Angreifer über administrative Privilegien oder physischen Zugriff auf einem System verfügen, auf dem Secure Boot so konfiguriert ist, dass er der Microsoft Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA) vertraut. Der Angreifer könnte einen betroffenen GRUB installieren und beliebigen Boot-Code auf dem Zielgerät ausführen. Nach erfolgreicher Ausnutzung dieser Schwachstelle könnte der Angreifer weitere Codeintegritätsprüfungen deaktivieren und dadurch das Laden beliebiger ausführbarer Dateien und Treiber auf das Zielgerät ermöglichen.


Anzeige

Microsoft arbeitet daran, die Validierungs- und Kompatibilitätstests für ein erforderliches Windows-Update abzuschließen, das diese Schwachstelle behebt. Wer IT-Experte ist und diese Schwachstelle sofort beheben möchten, kann die von Microsoft im Abschnitt Mitigation gegebenen Maßnahmen zur Abschwächung der Schwachstelle bei der Installation eines nicht getesteten Updates umsetzen. In diesem Supportdokument benennt Microsoft konkrete Details zum Absichern des Secure Boot.

Diese Schwachstelle ist über die TPM-Bestätigung und Defender ATP nachweisbar. Für dieses Problem vergebenen CVEs sind: CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, CVE-2020-15706, CVE-2020-15707.


Anzeige


Dieser Beitrag wurde unter Linux, Sicherheit, Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

5 Antworten zu BootHole-Schwachstelle gefährdet Linux und auch Windows Secure Boot


  1. Anzeige
  2. DavidXanatos sagt:

    Also auf das Risiko hin das ich mich etwas unbeliebt mache:
    Ich finde das sehr gut!

    Secure Boot ist für gemeine Endbenutzer ein Entmündigungssystem, ja noch kann man es auf den meisten Systemen abschalten aber ich sehe schon wo das hin hingehen soll wen MSFT am Ruder ist.

    Jedes Loch in diesem vermaledeiten Murks ist mir sehr willkommen.

    Ja… für die paar Leute für die Secure Boot wirklich eine Verbesserung ist ist es jetzt erst mal blöde, aber diese Leute sollten ihr System ohne hin eher so konfiguriert haben das es nur deren eigene aber nicht 3rd Party (a.k.a. MSFT oder so keys) akzeptiert. Und die können recht einfach den Key updaten und das grub Patchen und gut ist es.

    Just my 2 ct.

  3. 1ST1 sagt:

    Wie war das noch mal? Mit Linux wäre das nicht passiert… Autsch!

    • Henry Barson sagt:

      Jede Implementierung ist nur so gut wie die zuvor getroffenen Spezifizierungen und MS als Mitglied in dem Konsortium hat es einfach ebenso verkackt, oder wie Andre Kostolany es schon so trefflich formulierte:
      “EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus.”
      Insofern ist der gehobene Zeigefinger eigentlich auch suf sich selbst zu richten.
      Abgesehen davon wurde schon häufiger kritisiert, das UEFI SecBoot eher eine trügerische “Sicherheitsoption” bzw. demnächst womöglich wirklich -obligation ist.

    • Al Cid sagt:

      Genauer gesagt ist das Problem nicht Linux oder GRUB2 sondern eine Lücke in Secure Boot…

      Die Experten schreiben, dass die Security-Lücke alle Geräte betrifft, die Secure Boot einsetzen, auch wenn sie GRUB2 nicht einsetzen… und deswegen sind auch Windows-Geräte betroffen, die Secure Boot mit Standard Microsoft Third Party UEFI Certificate Authority nutzen und somit auch ein Großteil der Server, Desktops und Laptops… und was sonst noch darauf aufsetzt

      Schönes WE
      .

  4. Anzeige

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.