Das Gespenst UEFI Secure Boot

In den letzten Tagen hatte ich etwas Gelegenheit, mich mit UEFI Secure Boot näher zu beschäftigen: Ich erstelle bekanntlich die Notfall-CDs für einige Computerzeitschriften oder arbeite intensiv daran mit (von Computer Bild bis desinfec’t gibt es einige). Ziel war, alle aktuellen, von Microsoft signierten EFI-Loader unter die Lupe zu nehmen und auf ihre Praktikabilität abzuklopfen. Die gute Nachricht vorweg: Wer Ubuntu oder Fedora verwendet und keine Kernel selbst kompiliert, muss sich nicht mit dem Schlüsselmanagement herumärgern. Beide Distributionen verwenden einen von Microsoft signierten Loader (auf Basis von Shim), der wenigstens sicherstellt, dass GRUB2 und der anschließend geladene Kernel “vertrauenswürdig” ist. Zu Funktionsweise, Unterschieden und Restriktionen der verwendeten gepatchten GRUB2-Varianten hat sich Thorsten Leemhuis in der c’t 5/2013 zur Genüge ausgelassen. Wirklich spannend ist die Thematik aber für den Start selbst kompilierter Kernel, für kleine Distributionen, die verteilt und schnell entwickelt werden und für Administratoren, die Linux basierte Deployment- und Notfall-Systeme per Netz oder vom Wechseldatenträger starten wollen.

In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk.

Microsoft als Gatekeeper?

Ein großer – nicht von der Hand zu weisender – Kritikpunkt war Microsofts Rolle als Gatekeeper für den gesamten Bootprozess. Zwar war von vorneherein klar, dass UEFI mit Secure Boot (zunächst) abschaltbar und prinzipiell (immer) offen für alle Betriebssystemhersteller sein sollte. Wie dies in der Praxis aussehen sollte, war aber bis Herbst 2012 unklar. Eine totale Kontrolle der Hardware durch Microsoft wäre schon an kartellrechtlichen Bedenken gescheitert, so dass früh klar war, dass die Kontrolle der Schlüssel letztlich beim Eigentümer der Hardware verbleiben sollte. Das hätte in der Praxis aber auch ein striktes “entweder oder” bedeuten können: Ohne Microsofts Kooperation hätten Linux-Distributoren selbst Plattform-Schlüssel bereitstellen müssen. Der Anwender hätte seinen Rechner zur Installation in den “Setup Mode” versetzt und dann recht umständlich die Plattformschlüssel ausgetauscht. Der PC wäre mit allen Vorteilen des UEFI Secure Boot unter Linux gelaufen. Nur ein Dual Boot wäre unmöglich geworden – ein Szenario, mit dem Firmen, die Linux auf Thinclients oder Servern betreiben, durchaus leben können, das jedoch für den ambitionierten Anwender zuhause enorme Restriktionen bedeutet hätte. Der Einsatz von Live-CDs hätte hier immer vorausgesetzt, Secure Boot temporär zu deaktivieren – was keinesfalls standardisiert ist und möglicherweise irgendwann wegfällt.

Kritik erntet auch Microsofts Ansatz, Schlüssel und Hashwerte von Bootdateien auf eine schwarze Liste setzen zu können. Doch um diese schwarze Liste aktualisieren zu können, muss Windows laufen und Verbindungen ins Internet aufbauen können. Mittelfristig ist auch denkbar, dass Linux-Distributoren nach Absprache mit Microsoft Listen mit zurückgezogenen Schlüsseln und Hashes verteilen. Ich sehe hier durchaus Vorteile, beispielsweise wenn eine bestimmte Kernel- oder Bootloaderversion anfällig fürs Einschleußen von Rootkits ist. Unterm Strich bleibt aber die Freiheit, sowohl um Microsoft als auch um die großen Distributoren einen Bogen machen zu können und dennoch mit Microsofts Schlüsseln im NVRAM ein komfortables und (relativ sicheres) System nutzen zu können.

GRUB als Sicherheitsrisiko?

Derzeit existieren zwei Ansätze, einen komfortablen Linux-Start mit Secure Boot gewährleisten zu können: Bei beiden handelt es sich um kleine, vorgeschaltete Bootloader, die erst in der zweiten Stufe den eigentlichen Bootloader starten, der dann wiederum Kernel und Initramfs lädt, sowie Parameter übergibt. Aus Gründen der Konsistenz verwende ich derzeit einen selbst gebauten GRUB2 als zweite Stufe, der selbst keinerlei Prüfung durchführt, demnach theoretisch auch einen modifizierten Windows-Kernel mit darunter geschobenem Hypervisor-Rootkit starten kann. Das macht die Anwesenheit eines solchen GRUB und die Hinterlegung seines Hashes zu einem gewissen Sicherheitsrisiko.

Der Ansatz der Linux Foundation

Die Linux-Foundation bietet mit PreLoader.efi und HashTool.efi einen Bootloader und ein kleines Werkzeug zum Verwalten von Hashes. Die Kombination ist recht nutzerfreundlich umgesetzt: Der Anwender bootet Stick oder CD und startet damit den von Microsoft signierten PreLoader.efi. Findet der keinen Eintrag in der Liste erlaubter Hashes, startet er das ebenfalls signierte HashTool.efi. Mit diesem wählt der Anwender ein Binary, dessen Hash zur Liste erlaubter hinzugefügt werden soll – die beispielsweise die nach loader.efi umbenannte GRUB-Version, die beliebige Kernel booten kann. Nach einem Neustart startet PreLoader.efi den nun auf der weissen Liste stehenden Bootloader ohne weitere Nachfrage. PreLoader.efi ist recht simpel umgesetzt und wie bereits erklärt ziemlich nutzerfreundlich: Programmierer müssen Bootloader der zweiten Stufe nicht mit Zertifikaten versehen, stattdessen erklärt der Anwender beim Start, dass er einem bestimmten Binary vertraut. Ein großer Nachteil dieser Lösung ist, dass bei Änderungen am Bootloader der zweiten Stufe eine lokale Bestätigung des Hashes notwendig ist. Für Administratoren in großen Unternehmen mit weit verzweigten Standorten kann dies äußerst unpraktisch sein…

Signaturen statt Hashes: Shim mit MOKs

Shim ist ein etwas aufwendigerer Loader, der derzeit sowohl von Fedora als auch von Ubuntu genutzt wird und in seiner freien Variante auf MOKs – Machine Owner Keys – aufsetzt. Shim 0.2 wird mit einem ebenfalls von Microsoft signierten Binary MokManager.efi ausgeliefert, der es es erlaubt, eigene Signaturschlüssel für vertrauenswürdige Binaries ins NVRAM zu laden. Mit diesen signierte Bootloader führt Shim aus. Im Falle eines Bootloader-Updates muss lediglich der neue Bootloader mit dem gleichen Schlüssel wie der alte signiert werden. Der Vorteil dieses Ansatzes liegt ganz klar in der leichteren Remote-Administration und vereinfachten Updates.

Ein denkbares Szenario für die Vorteile des Shim-Einsatzes ist ein per PXE gebootetes Linux, das als Deployment- und Notfall-System dient: Um aus dem PXE-Boot kein Einfallstor für Schad- und Spionagesoftware zu machen, ist es möglich, die gesamte Boot-Kette vom Bootloader der zweiten Stufe, der nur signierte Kernel und Initrds lädt, über eine prüfende Initrd, die wiederum die Signatur des Root-Images checkt, zu booten. Ein derartiges System könnte für jeden Kunden mit einem eigenen “Machine Owner Key” signiert werden. Der Administrator muss vor dem Deployment eines PCs lediglich den MOK ins NVRAM aufnehmen. So ist auch ein sicherer Start von Thin-Client-Systemen möglich – vor Secure Boot konnte beim PXE-Boot niemand sicherstellen, dass kein korrupter Bootserver Systeme mit integriertem Keylogger ausliefert.

Einigung in Sicht

Ein Kritikpunkt an Shim war die hier implementierte Duplikation von Funktionalität: Shim implementiert ein eigenes Schlüsselmanagement und eigene Prüfungen. Dennoch bietet das Prinzip der Machine Owner Keys wie oben dargelegt viele Vorteile, insbesondere erlaubt es die Nutzung einer kompletten Secure Boot Kette, ohne dass eigene Binaries von Microsoft signiert werden müssen, stattdessen reicht es, auf jeder Machine einmal einen öffentlichen Schlüssel als vertraulich zu importieren. Matthew Garret, der Shim entwickelt, möchte den Code der Linux Foundation deshalb in Shim übernehmen um so die Vorteile beider Loader kombinieren zu können.

Bootloader mit Verfallsdatum?

Mich stört, dass UEFI keinen Mechanismus bereitstellt, einen gewhitelisteten Hashwert oder Schlüssel verfallen zu lassen. Beim Einsatz von Live-Systemen zur Rettung wäre es von großem Vorteil, maximal fünf Mal oder maximal 24 Stunden mit einem Hash booten zu können, bevor dieser automatisch verfällt. So muss der Anwender selbst darauf achten, nicht mehr benötigte Hashes selbst zu löschen, damit ein allzu liberal agierender Bootloader (der alles lädt) nicht als Einfallstor für Schadsoftware mißbraucht werden kann.

Mein Fazit

Als normaler Anwender sollte man keine Angst vor Secure Boot haben und UEFI Secure Boot nach Möglichkeit aktiviert lassen. Beim Testen eigener Kernel oder dem Remastern von Live-Medien wird vielen Anwendern aber nichts anderes übrig bleiben als zu experimentieren: Zu klein ist die Erfahrung in der Community mit UEFI Secure Boot noch und zu klein ist das Angebot an Hardware (und UEFI-Implementierungen), um alle potentiellen Bugs zu kennen. Zudem ist Abwärtskompatibilität nun ein Thema: Gerade Live-Medien wie USB-Sticks oder CDs sollen möglichst auf UEFI- und BIOS-Systemen gleichermaßen bootfähig sein. Das ist möglich, erfordert aber gelegentlich Verrenkungen und zumeist doppelte Konfigurationsdateien: Je eine für den UEFI-Bootloader und den BIOS-Bootloader.

11 thoughts on “Das Gespenst UEFI Secure Boot

  1. Marcus

    Hi.

    Mir ist schon die Funktionsweise des UEFI Boots nicht ganz klar.

    So wie ich das sehe, hat das UEFI eine Firmware, die versucht von einer FAT32 EFI Partition einen Bootloader zu starten. Woher ‘weiss’ das BIOS denn welche Datei es starten soll? Im efi Verzeichnis auf der FAT32 Partition finde ich Unterverzeichnise für die jeweigen Vendors (z.B. microsoft oder ubuntu), mit allerlei efi Dateien drin.

    So weit ich das beobachtet habe gibt es auch eine bootx64.efi Datei in einem efi Unterverzeichnis. Ob die jeweils der ‘letzte’ überschreibt habe ich bisher noch nicht herausgefunden.

    Beim Versuch Ubuntu 12.10 auf einem UEFI System zu installieren, das bereits Windows 8 drauf hatte, konnte ich nachher zwar (mittels Grub2?) Ubuntu starten, Windows 8 wurde dort aber nicht aufgeführt.

    Als ich danach Secure Boot eingeschaltet habe, kam dann ein Authentication Failure als er versucht hat Ubuntu zu laden. Nach einiger Zeit ist dann allerdings Windows gestartet.

    Wäre nett wenn du mir das erklären könntest.

  2. UbuntuFlo

    Huhu Mattias, ich danke Dir für diesen sehr informativen Artikel. Freue mich auf weitere Artikel aus dieser Reihe. Liebe Grüße, Flo

  3. Ralf

    Moin,

    ich habe nicht ganz verstanden, warum wir Secure Boot brauchen. Kannst Du mir da auf die Sprünge helfen? Das mit den Rootkits ist doch nur vorgeschoben oder? Ich meine, wie sollen die es denn ohne physikalischen Zugriff auf den PC und dann noch dazu am OS vorbei auf in den Bootloader schaffen. Da ist doch dann auch seitens des OS einiges schief gelaufen im OS.
    Meine persönliche Einstellung dazu ist, dass ich bis lang UEFI secure boot immer ausschalten würde, da sich mir der Sinn nicht erschließt. Anmerken sollte ich vielleicht, dass ich seit geraumer Zeit ausschließlich Linux nutze.

    lG
    Ralf

  4. Mattias

    @Marcus, #1: UEFI kann einige Dateisysteme lesen (FAT, ISO9660) und benötigt daher keinen Bootrecord, der geladen und ausgeführt wird (wie die 446 Bytes bei BIOS/MBR), stattdessen liest UEFI das Dateisystem und such den Bootloader unter “EFI/BOOT/BOOTX64.EFI” (beziehungsweise auf extrem seltenen 32 Bit EFI-Systemen BOOTIA32.EFI) oder “EFI/BOOT/os-vendor/BOOTX64.EFI”. Im NVRAM können mehrere Bootloader hinterlegt werden, beispielsweise “EFI/BOOT/ubuntu/BOOTX64.EFI”, “EFI/BOOT/microsoft/BOOTX64.EFI” und “EFI/BOOT/yoyodyne/BOOTX64.EFI”, dazu eine Reihenfolge und Aktionen im Fall des Bootfehlschlages. In Deinem Fall war wohl Ubuntus BOOTX64.EFI als erste eingetragen, verwies aber auf GRUB ohne den vorgeschalteten Secure Boot Shim, daher startete beim Fehlschlag das Windows. Die Auswahl zwischen Windows und Linux erfolgt in diesem Fall über den EFI-eigenen Bootmanager (dort wo man auch USB- oder CD-Boot anwählen kann).

    @Ralf, #3: Klar, wenn eine Schwachstelle die Manipulation des Bootloaders erlaubt, ist einiges fehlgeschlagen im OS. Nur sind im Falle von sauber umgesetztem Secure Boot die Auswirkungen deutlich schwächer, weil das kompromittierte System eben nicht mehr startet. Im derzeitigen Stadium hat Secure Boot tatsächlich kaum oder keine Vorteile für den Anwender. Mittelfristig sehe ich aber große Vorteile für die Systemintegrität in Firmenumgebungen, gerade den Einsatz individuell zugeschnittener Thinclient-, Fatclient- oder Servercluster-Linux-Systeme, bei denen die ganze Kette von Bootloader bis zum Root-Dateisystem (im Haus) signiert werden kann, ist attraktiv (siehe mein Beispiel). Für den Endanwender befürchtete ich bis vor kurzem tatsächlich Gängelung durch Microsoft, so wäre mittelfristig denkbar, dass Windows nur noch signierte Binaries startet und damit zum Windows Store zwingt. Diese Befürchtung ist mittlerweile schwächer, Gründe sind die sinkende Marktmacht, der kritische Blick der Kartellbehörden und der Wunsch von Firmenkunden nach der Flexibilität, Eigenentwicklungen schnell ausrollen zu können. So müsste eine komplette Secure-Boot-Kette vom Bootloader bis zur letzten EXE die Möglichkeit beinhalten, eigene Schlüssel (ähnlich dem MOK-Prinzip) freizuschalten. Auch hier wären wir an dem Punkt zu sagen: Firmen profitieren mittelfristig enorm von Secure Boot, für Privatanwender bedeutet es unter Umständen Frust und Mehraufwand bei einem nur geringem Sicherheitsplus.

  5. Marcus

    @Matthias ok. Danke für die Erklärung. Bei mir gibt es EFI/BOOT/BOOTX64.EFI sowie die os-vendor Verzeichnisse. mit eigenen .efi files. Wer die EFI/BOOT/BOOTX64.EFI geschrieben hat, habe ich noch nicht herausgefunden.

    Wird das grub, dass ubuntu installiert hat, denn wohl das EFI grub aus EFI/BOOT/ubuntu sein? Oder hat ubuntu wohl trotzdem noch einen MBR geschrieben. So wie ich das gelesen habe, scheint das ja auch mit GTP immer noch möglich zu sein:

    http://en.wikipedia.org/wiki/GUID_Partition_Table#Legacy_MBR_.28LBA_0.29

    Zu shim habe ich auch noch eine Frage: Selbst wenn SecureBoot nicht aktiv ist, sollte sich ein System doch über shim starten lassen, oder? D.h. es wäre wohl die bessere Herangehensweise shim immer als EFI Loader zu verwenden, um SecureBoot an- und abschaltbar zu machen.

  6. Administrator Post author

    @Marcus, #5: Ob der EFI/BOOT/BOOTX64.EFI von Microsoft, Ubuntu oder dem Hardwarehersteller stammt, ist letztlich egal – lässt sich aber wahrscheinlich anhand Größe, Änderungsdatum und “strings” leicht beantworten. So können Hardwarehersteller eigene Loader fürs Recovery-System hinterlegen und diesen dann im NVRAM des EFI (nachrangig) eintragen. Mit Shim hast Du vollkommen recht, der kann beides: UEFI Boot mal sicher, mal nicht. Zu bedenken ist, dass bei Erscheinen von Ubuntu 12.10 recht wenig Hardware mit UEFI Secure Boot auf dem Markt war und demnach wohl recht wenige Tester solche Fälle wie Deinen (spätere Aktivierung von Secure Boot) durchgespielt haben. Ich vermute mal, dass Du derzeit mit deaktiviertem Secure Boot unterwegs bist?

  7. Marcus

    Ja, momentan habe ich SecureBoot deaktiviert. Ich werde aber nochmal mit aktivem SecureBoot neu installieren.

    Kannst du noch was zu der GPT MBR Theorie sagen?

  8. Administrator Post author

    @Marcus, #7: Ein ordentliches GPT-Partitionierungstool legt immer einen sogenannten “Protective MBR” an. Dieser “Schutz-MBR” dient primär dazu, ältere Partitionierungstools darauf hinzuweisen, dass der Rest der Platte belegt ist. Er kann aber auf BIOS-Systemen auch einen Bootloader aufnehmen, der dann seine zweite Stufe in einer BIOS-Boot-Partition (ich glaube EF02) sucht. GRUB kann das ganz gut, siehe: http://blog.rootserverexperiment.de/2012/08/05/ubuntu-12-04-auf-gpt-debootstrappen/ Ich glaube aber, dass es Ubuntu beim “leeren” Protective MBR belassen hat, weil es recht aufwendig wäre, beide GRUB (für GPT-MBR-Boot und GPT-UEFI-Boot) synchron zu halten.

  9. Marcus

    Danke, es wird mir so langsam etwas klarer ;)

    Wenn die OS Auswahl, wie du es beschreibst immer mit dem UEFI Chooser erfolgt, ist es dann überhaupt noch möglich z.B. aus dem EFI Grub einen anderen EFI Loader (z.B. den von Windows) zu starten? Sozusagen EFI-Chainloading?

  10. Mattias

    @Marcus, #9: Mein Gefühl sagt mir, dass es zumindest aus der Kombination PreLoader/Gummiboot möglich sein sollte, Microsofts EFI Loader zu starten. Bei GRUB bin ich skeptisch, weil GRUB andere Loader im Speicher ersetzt. Letztlich kommt es natürlich auf einen Test an. Werde ich mal ausprobieren, aber zunächst kommt der sichere UEFI-Boot von 32-Bit-Kerneln, der sichere UEFI-Boot von optischen Medien und per PXE, erst dann gehe ich auf die Feinheiten des Starts von Platte ein.

Comments are closed.