Was ist SBAT, und warum interessiert sich plötzlich jeder dafür?

Definition von SBAT (Secure Boot Advanced Targeting)

• Als UEFI Secure Boot ursprünglich festgelegt wurde, waren alle Beteiligten etwas naiv.
• Das grundlegende Sicherheitsmodell von Secure Boot besagt, dass jeder Code, der in einer Umgebung mit Kernel-Rechten ausgeführt wird, vor der Ausführung verifiziert werden muss.
• Es enthält einen Mechanismus, um signierte Komponenten zurückzuziehen, in denen Schwachstellen gefunden wurden.
• Da jedoch alle Linux-Distributionen, die im Secure-Boot-Ökosystem funktionieren, ihre eigenen Bootloader-Binärdateien erzeugen, gibt es bei einer identifizierten Schwachstelle viele Binärdateien, die zurückgezogen werden müssen.
• Da der Speicherplatz für Hashes begrenzt ist, wurde SBAT entwickelt.

Wie SBAT funktioniert

• Alle wichtigen Komponenten der Boot-Kette deklarieren eine Sicherheitsgeneration, die in der signierten Binärdatei enthalten ist.
• Wird eine Schwachstelle identifiziert und behoben, wird diese Generation erhöht.
• Durch Updates kann eine Mindestgeneration festgelegt werden.
• Eine Boot-Komponente betrachtet den nächsten Eintrag in der Kette, vergleicht Name und Generationsnummer mit den in einer Firmware-Variablen gespeicherten Werten und entscheidet dann, ob sie ausgeführt wird.
• Statt viele einzelne Hashes zurückzuziehen, kann ein einzelnes Update verteilt werden, das besagt, dass grub-Versionen mit einer Sicherheitsgeneration unterhalb einer bestimmten Nummer nicht vertrauenswürdig sind.

Ursache des jüngsten Problems

• Microsoft hat per Windows Update eine Regel ausgeliefert, nach der grub-Versionen unterhalb eines bestimmten Niveaus der Sicherheitsgeneration nicht vertrauenswürdig sind.
• Grund dafür ist, dass diese grub-Versionen tatsächlich Sicherheitslücken enthalten, mit denen die Windows-Secure-Boot-Kette kompromittiert werden könnte.
• Das Problem ist, dass einige Linux-Distributionen noch keine grub-Version mit der neuen Sicherheitsversion bereitgestellt hatten.
• Microsofts Absicht war es, das SBAT-Update nur auf Systeme anzuwenden, auf denen ausschließlich Windows installiert ist, doch das funktionierte nicht wie beabsichtigt.

Zusammenfassung

• Microsoft hat ein Windows Update ausgerollt, um Angriffe auf Windows über verwundbare grub-Versionen zu verhindern.
• Dieses Update sollte nicht auf Dual-Boot-Systeme angewendet werden, wurde dort aber dennoch wirksam.
• Einige Linux-Distributionen haben weder den grub-Code noch die SBAT-Sicherheitsgeneration aktualisiert.
• Infolgedessen konnten manche Nutzer ihre Systeme nicht mehr booten.

Wer trägt die Schuld?

• Microsoft hätte mehr testen müssen, um Dual-Boot-Konfigurationen korrekt zu identifizieren.
• Gleichzeitig müssen Distributionen, die signierte Bootloader bereitstellen, diese auch aktualisieren und die Sicherheitsgeneration anheben.
• Andernfalls entsteht ein Angriffsvektor, der gegen andere Betriebssysteme genutzt werden kann.

Fazit

• Es ist bedauerlich, dass am Ende die Endnutzer betroffen sind und plötzlich das gewünschte Betriebssystem nicht mehr booten können.
• Das hätte niemals passieren dürfen.
• Auch wenn sich UEFI Secure Boot für die meisten Endnutzer nicht unmittelbar vorteilhaft anfühlt, ist es etwas, dessen Nutzen man oft erst im Nachhinein erkennt; deshalb ist Microsofts Entscheidung nachvollziehbar, es standardmäßig zu aktivieren.
• Abgesehen von dem gescheiterten Versuch, das Update auf Dual-Boot-Systemen zu vermeiden, ist Microsofts Entscheidung nachvollziehbar.

Meinung von GN⁺

• Dieser Vorfall zeigt, wie schwierig es ist, ein Gleichgewicht zwischen Sicherheit und Nutzererlebnis zu finden.
• Sowohl Microsoft als auch die Linux-Distributionen tun ihr Bestes, um Nutzer zu schützen, doch dabei kann das Nutzererlebnis leiden.
• Bei Nutzern von Dual-Boot-Systemen ist die Wahrscheinlichkeit höher, mit solchen Problemen konfrontiert zu werden.
• Deshalb ist es für Nutzer von Dual Boot wichtig, beide Betriebssysteme aktuell zu halten und regelmäßig zu aktualisieren.
• Langfristig scheint eine bessere Zusammenarbeit und Abstimmung zwischen der Linux- und der Windows-Community notwendig zu sein.

[GN⁺]

Hacker-News-Kommentare

• In einer aktuellen Folge von Linux Unplugged wurde behandelt, wie man mit TPM eine Vertrauenskette für den Linux-Boot-Prozess aufbaut; mit Clevis war das sehr interessant
• Microsofts Absicht war, dass Windows Update das SBAT-Update nur auf reine Windows-Systeme anwendet und Dual-Boot-Setups verwundbar bleiben, bis die installierte Distribution grub aktualisiert und das SBAT-Update selbst ausliefert
  • Wenn man die EFI-Boot-Reihenfolge ausliest, müsste doch klar erkennbar sein, dass zuerst shim gebootet werden soll; ich frage mich, was schiefgelaufen ist
  • Ich frage mich, ob es um den Fall ging, dass Nutzer in einem Dual-Boot-Setup über das Firmware-Menü Linux oder Windows auswählen
  • Das scheint ein legitimer Fix von Microsoft zu sein, aber die Kommunikation war schlecht
• Ich hasse die Fehlermeldungen bei allgemeinen Sicherheitsprüfungsfehlern von shim oder Secure Boot; ich wünschte, sie würden genau sagen, was fehlgeschlagen ist und wie man es behebt
• Ich denke, ein Grund dafür, dass MS TPM2.0 erzwingt und SBAT-Updates durchsetzt, ist die Existenz weit verbreiteter Malware auf Rootkit-Ebene
• Zur Realität von Dual Boot: Vor 10 Jahren gab es unter Win7/8/10 viele Probleme mit suspend-to-hiberfile.sys und mit Updates, die grub kaputt machten
  • Ich habe mich vor 10 Jahren entschieden, nur noch Linux zu verwenden und bei Bedarf eine VM oder einen separaten Reserve-Rechner zu nutzen
  • Seitdem habe ich gelernt, Secure Boot in Distributionen erfolgreich einzurichten, die QEMU-Performance und das Passthrough zu optimieren und sogar eine QEMU-macOS-VM zum Laufen zu bringen
  • Es ist lästig, alle paar Monate zu aktualisieren, nur um XCode aktuell zu halten, aber insgesamt bin ich zufrieden
• Ist es nicht ohnehin der erste Schritt bei der Installation von Linux, Secure Boot zu deaktivieren?
• Die entscheidende Frage ist, ob das abgelehnte grub überhaupt nicht vollständig gepatcht war oder ob die Distribution es gepatcht hat, ohne die „Sicherheitsgeneration“ zu aktualisieren
  • Ich bin sehr neugierig, wie MS versucht hat, Dual Boot zu erkennen, und hoffe, dass jemand Kompetenteres diesen Teil des Updates per Reverse Engineering untersucht
• Der Grund, warum Microsoft Dual-Boot-Systeme kaputtgemacht hat, ist, keinen Angriffsvektor auf andere Betriebssysteme bereitzustellen, und das ist ein Bruch des gesellschaftlichen Vertrags
• Ich frage mich, ob das die Entfernung von Windows und die Installation von Linux auf dem System behindert oder ob die Installation von Windows das TPM-Modul dauerhaft verunreinigt
• Ich frage mich, ob man grub von Windows aus aktualisieren kann oder ob es reicht, Secure Boot zu deaktivieren, Linux zu booten, das Upgrade durchzuführen und es dann wieder zu aktivieren
• Die Haltung von MS, alte verwundbare grub-Installationen zu blockieren, wirkt vernünftig, aber ich nutze Windows nur für Spiele und eine einzelne Legacy-Software und ohne Netzwerkzugang
  • In dem Moment, in dem man Windows Update zulässt, ist alles dem Zufall überlassen
  • Dass MS Registry-Schlüssel verschiebt und Nutzern Streiche spielt, um „Telemetrie“ (ML zum Scannen von Werbe- und Verhaltensdaten) zu erzwingen, sagt schon alles
  • Das passiert sogar unter Windows Pro; ich nutze Win 10