Zur Problematik von UEFI Secure Boot

Feb 21, 2017
UEFITrusted Computing

Wo auf Personal Computern und Laptops vor einigen Jahren direkt nach dem Einschalten das BIOS (Basic Input-Output System) wie etwa vom Hersteller American Megatrends, Inc. (AMI) für die Initialisierung von Systemkomponenten am Beginn des Bootvorganges zuständig gewesen ist¹, findet sich dort heute gemeinhin ausgewachsene PC-Firmware nach dem UEFI-Standard. Beim Unified Extensible Firmware Interface² handelt es sich um eine Weiterentwicklung von EFI, das Intel bereits Ende der 90er Jahre für 64 Bit-Server eingesetzt hatte, und das sich mit modernen Rechnern, die mit Microsoft Windows verkauft werden, endgültig im PC-Bereich durchgesetzt hat. Für den Praktiker zeichnet sich UEFI unter anderem durch den Einsatz von GUID-Partitionstabellen aus, die gegenüber dem herkömmlichen MBR (Master Boot Record) den Einsatz von Laufwerken mit mehr als 2 TB und mehr als 4 Devices möglich machen³. Die verbreiteten Linux-Distributionen arbeiten heutzutage gemeinhin einwandfrei mit UEFI zusammen und können bei der Installation EFI-Systempartitionen (ESP) mit dem benötigten Bootcode automatisch anlegen⁴. Und der von der UEFI-Spezifikation weiterhin vorgesehene “Legacy”-Modus CSM (Compatibility Support Module)⁵ kann zum Beispiel gar nicht mehr eingesetzt werden, wenn Dualboot-Systeme zusammen mit Windows aufgesetzt werden sollen – was im Privatanwender-Bereich eventuell doch noch eine Rolle spielt. Das Werkzeug efibootmgr kann unter Linux zur Abfrage und Konfiguration des UEFI-Bootmanagers benutzt werden.

Probleme mit UEFI im Zusammenspiel mit Linux gab es in den vergangenen Jahren vor allem auf einigen bestimmten Laptop-Modellen. Der “Samsung-UEFI-Bug” bzw. “Phoenix-UEFI-Bug” hat auf einigen Samsung-Geräten aus den Modelljahren 2013/14 zu viel Frust bei Computerkäufern geführt. Betroffen waren dabei einige flache Notebooks und Ultrabooks mit Windows 7 und 8 wie zum Beispiel die Modelle 300E5C und 900X4C⁶. Es traten Berichte auf, dass diese Rechner sich bei der Installation von Ubuntu 12.04 und 12.10 unter UEFI dauerhaft aufgehängt hatten, so dass auch ein Neustart nicht mehr möglich gewesen ist, und schließlich sogar das Mainboard komplett ausgetauscht werden musste – nicht so prickelnd. Dieser Fehler kam hingegen nicht vor, wenn diese Linux-Distrbutionen im CSM-Modus gebootet wurden. Als Auslöser dieses Crashs war schnell der Kernel-eigene Treiber samsung-laptop ausgemacht worden, und es gab dann zeitnah Schutzfunktionen in den Kernel-Versionen 3.7.6 und 3.8~rc6, sowie einen speziellen Workaround in Ubuntu 12.04.2 und 13.04. Bei der Analyse der Vorkommnisse stellte sich heraus⁷, dass es wahrscheinlich auch zum Teil wegen ungenauer UEFI-Spezifikation ständig zu einem Treiberabsturz gekommen war, wobei eine Machine Check Exception aufgetreten ist (MCE). Und der daraufhin von der Firmware als UEFI-Variable fehlerhaft im nichtflüchtigen Speicher (NVRAM) abgelegte Crashdump (Speicherbereiche sind überschrieben worden) hat die betroffenen Geräte dann zu teuren Briefbeschwerern gemacht. Es handelt sich dabei wahrscheinlich um einen Fehler im UEFI-Firmware-Kern “SecureCore Tiano (SCT)” der Firma Phoenix, denn Linux-Probleme gab es auch mit einem damit bestückten Fujitsu Lifebook AH532/G52. Folgerichtig konnte der Fehler auch von Windows aus mit einem kleinen C-Programm reproduziert werden. Ähnliche Probleme gab es später auch auf Haswell-Thinkpads von Lenovo wie dem T540p, L540 und W540 mit bestimmten BIOS-Versionen (u.a. 1.08 und 1.11)⁸ – Linux ist bei allen diesen Vorkommnissen unglücklicher Weise aber immer nur der Auslöser, nicht aber der Verursacher gewesen.

Bei PC-Firmware und auch der Firmware von Komponenten handelt es sich um äußerst attraktive Angriffsziele in der Absicht, sich unbefugten Zugriff auf fremde Computersysteme zu verschaffen. Eine in diesem Bereich von PCs, so hardwarenah wie möglich eingebrachte Schad- oder Schnüffelsoftware genießt viele Vorteile, sie kann sich dort sehr unauffällig verstecken, läuft an der Spitze des Software-Stacks völlig unabhängig vom Betriebssystem, und übersteht sogar auch eine Neuinstallation davon und einen Austausch der Festplatte. Sehr hochentwickelte Tools auf Geheimdienst-Niveau wie zum Beispiel aus der von Kaspersky aufgespürte Spionagesoftware der berüchtigten “Equation Group” können sich auch sogar in die Firmware von Festplatten einnisten, so dass nur die physikalische Zerstörung der Geräte die einzige Möglichkeit ist, die Malware unschädlich zu machen⁹ – wenn man überhaupt mitbekommen konnte, dass sie vorhanden ist. Ein UEFI-Rootkit war zum Beispiel beim Überwachungssoftware-Hersteller Hacking Team in Mailand im Einsatz¹⁰, von dem in 2015 ein umfangreicher Datensatz geleakt worden ist, welcher tiefe Einblicke die gegenwärtigen technischen Möglichkeiten des Auspionierens von Computern und Smartphones, und die dahinter stehenden Machenschaften eröffnet hat¹¹. Bei UEFI handelt es sich um eine komplexe Maschinerie, die zum Beispiel auch über einen eigenen Interpreter für EFI-Bytecode verfügt, einen integrierten Netzwerk-Stack zur Fernwartung und für PXE, und vieles mehr. Mit der Komplexität steigt aber natürlich auch das Risiko, dass Angriffsvektoren ausfindig gemacht werden. Eine Methode dafür ist zum Beispiel in einem Vortrag auf dem 31C3 in 2014 vorgestellt worden¹²: als Hebel dienen dabei unter anderem Schwachstellen im System Management Modus (SMM), unter Ausnutzung derer sich die Firmware auf dem SPI-Flashspeicher überschreiben lässt¹³. Im Zuge dessen wurde wenige Wochen später das als Studie geschriebene UEFI-Rootkit “Lighteater” veröffentlicht¹⁴, das auch aus der Ferne, etwa mittels eines Exploit-Kits über den Browser aufgebracht werden kann, und mit dem etwa GPG-Schlüssel aus dem Speicher ausgelesen und im NVRAM für spätere Abfragen abgelegt, oder aber direkt auch über Intels Active Management-Technologie (AMT) über das Netz rausgeschickt werden können. Dabei spielt es absolut keine Rolle, welche Betriebssystem auf dem Rechner installiert ist, und das Rootkit stibitzt auf erschreckende Weise genauso frech von ausgesprochenen Security-Distributionen wie Tails¹⁵. UEFI, wie es sich hier einsetzen lässt, präsentiert sich nicht gerade als eine Bastion der Computersicherheit.

Secure Boot ist ein UEFI-Modul für die digitale Signaturprüfung, welches mit der UEFI-Spezifikation 2.3.1 eingeführt worden ist, und das die Sicherheit bei UEFI entscheidend verbessert. Dafür enthält die Firmware einen Satz asymmetrischer kryptografischer Schlüssel, mit denen ein zweistufiges Vertrauensverhältnis zwischen Hardwarehersteller, Firmware und Betriebssystem etabliert wird¹⁶. Der öffentliche Teil des “platform key” (PK) des Hardwareherstellers ist im NVRAM abgelegt, und mit dessen Hilfe kann nur vertrauenswürdige Firmware, die vom Hersteller signiert worden ist, auf dem Rechner gestartet werden. Betriebssystemhersteller können darüber hinaus “key exchange keys” (KEK) einspielen lassen, die wiederum mit dem PK signiert worden sind, und mit denen als vertrauenswürdig angesehene Bootloader – zunächst einmal den eigenen – von der Firmware gestartet werden können. So lässt sich wirkungsvoll verhindern, dass beim Systemstart auf Firmware-Ebene oder auf Boot-Ebene unautorisierter Code ausgeführt wird, und die Vertrauenskette lässt sich auch vom Betriebssystem aufnehmen und etwa zum Kernel, seinen Modulen und den Treibern weiterführen¹⁷. Secure Boot ist seit Windows 8 bei Auslieferung standardmäßig auf PCs mit Windows-Logo aktiviert, lässt sich aber gemeinhin im BIOS-Setup deaktivieren (auch wenn das meistens nicht so offensichtlich ist, wie genau), so dass UEFI-Booten auch ohne Secure Boot möglich ist, wenn das gewünschte Betriebssystem Secure Boot nicht unterstützt.

Dem Anbieter Microsoft kommt bei UEFI Secure Boot eine besondere Rolle zu: da kein anderer Betriebssystem-Anbieter einen KEK-Schlüssel pflegt, und Institutionen wie die Free Software Foundation den damit verbundenen, auch gerade finanziellen Aufwand kaum bewältigen können findet sich in der Regel nur der Microsoft-Schlüssel auf PC-Mainboards installiert, und Secure Boot verweigert das Starten eines nicht über den Microsoft-Dienst Verisign, zugegeben kostengünstig signierten Bootloaders. Und bereits signierte Bootloader können von dem Softwarehersteller jederzeit nach eigenem Ermessen auf eine schwarze Liste gesetzt werden, die per Windows-Update verteilt und automatisch mit der Firmware abgeglichen wird. Die Forbidden Signatures Database (DBX) in der Firmware nimmt dabei die Signatur von nicht mehr als vertrauenswürdig eingestuften Bootloadern und den damit verbundenen Betriebsystemen auf, wenn diese sich als schädlich herausgestellt haben sollten. Selbstverständlich gibt es ein großes kommerzielles Interesse an einer solchen Markt kontrollierenden Stellung, und man muss nicht besonders misstrauisch sein um zu vermuten, dass langfristig zunächst der Legacy-Bootmodus CSM für Windows-Alternativen, und dann die Möglichkeit Secure Boot zu deaktivieren immer häufiger aus den Setup-Menüs von neuer mit Windows verkaufter Hardware verschwinden werden. Letztere Möglichkeit war schon in 2013 für Tablet-Computer mit Windows RT ausgeschlossen worden, und ist als nächste Stufe neuerdings im Zuge des Verkaufs von Windows 10 den Herstellern von PC-Hardware freigestellt überhaupt noch anzubieten.

Daran, wie die – im Grunde gar nicht schlechte – Secure Boot-Technik positioniert wird, wie Microsoft mit seiner besonderen Rolle umgeht, und an der Richtung der Entwicklung von UEFI Secure Boot setzt mittlerweile auf breiter Front entschiedene Kritik an, und das nicht nur aus Kreisen der Verfechtern von freier Software. Secure Boot fällt dabei unter das Stichwort “Trusted Computing”, und eine zusätzliche Brisanz gewinnt die Sache zusätzlich dadurch, dass diese Technik mit TMP 2.0 (trusted computing module)-Hardware verbunden wird. Es entsteht dadurch eine geschlossene Sicherheits-Infrastruktur, die dem Benutzer die Kontrolle über eingesetzte Hardware und Software entzieht ohne das die Wahlmöglichkeit gegeben gewesen wäre, sich in diese Struktur einschließen lassen zu wollen, oder nicht. Trusted Computing-Schlüssel sind nicht austauschbar, es kann also nicht in eine andere Architektur gewechselt werden, oder alternative Sicherheitsarchitekturen angeboten werden¹⁸. Der von Intel entwickelte Boot Guard verschärft das “lock-in” zusätzlich, indem der komplette Austausch der PC-Firmware mit der quelloffenen Alternative Coreboot dadurch unmöglich gemacht wird¹⁹. Eine wichtige Rolle spielt dabei die bisher immer noch nicht vollständig dokumentierte Management Engine (ME)²⁰, welche verdächtigt wird, eine Hintertür für Geheimdienste bereit zu stellen²¹ – der reale Zugewinn an Sicherheit durch den weiteren Ausbau der Trutzburg bzw. des Gefängnisses Secure Boot ist also eher relativ.

Weit über die lästige Gängelung von Privatbenutzern hinaus entfaltet die mit Secure Boot verbundene Problematik ihre ganze Tragweite aber wenn es um den breiten Einsatz von Windows-Rechnern in der Wirtschaft, in der öffentlichen Verwaltung, und im Bereich der Kritischen Infrastrukturen (KRITIS) der Bundesrepublik (Transport und Verkehr, Energie, Gefahrenstoffe usw.) geht. Es ist eine Tatsache, das mit dem Einsatz dieser Trusted Computing-Hardware die Hoheit über die digitale Infrastruktur einem privatwirtschaftlichen Unternehmen in einer anderen Jurisdiktion mit ganz eigenen Interessen übergeben wird²² – wird dort zum Beispiel ein zentraler kryptografischer Schlüssel entwendet, dann kann damit ein Schaden im “Roland Emmerich”-Ausmaß angerichtet werden. Man ist damit auch unbeabsichtigten Fehlern ausgeliefert, und vergangene Patchday-Debakel mit zerschossenem Updatesystem zeigen teilweise einen insgesamt doch erschreckend laxen Umgang mit der Verantwortung in Bezug auf Endbenutzer-relevante Nachlässigkeiten (Punkte dabei auch: Schlüssellänge und -Verfallszeit)²³. Außerdem können diese Mechanismen auch ganz generell für Sabotageakte und Erpressung benutzt werden, wenn Angriffsvektoren auf diese komplexe Sicherheitsarchitektur herausgefunden bzw. bekannt werden. Die Eckpunkte des Bundes zum diesem Thema von 2012²⁴ verlangen folgerichtig, dass die vollständige Kontrolle (Steuerbarkeit und Beobachtbarkeit) des Geräte-Eigentümers möglich sein muss, und dass Geräte mit zunächst deaktivierten Trusted Computing-Sicherheitsystemen ausgeliefert werden sollen, und das die Deaktivierung keine negativen Einflüsse auf die Funktionalität von Hardware und Software haben darf. Der vom BSI entwickelte SINA-Standard für Endgeräte für die Bearbeitung von “Nur für den Dienstgebrauch”-Verschlussachen (VS-NfD) zeigt, was handfeste Sicherheitsmaßnahmen sind: auf handelsüblicher Hardware wird Coreboot als Firmware aufgespielt, und die ME wird dabei ganz bewusst isoliert. Ein speziell abgesichertes Linux bietet darauf dann mittels Virtualiserung einen streng abgesicherten Schutzraum auf dem Rechner an, in dem dann etwa Windows laufen gelassen werden kann²⁵. Ob die vom Hardwarehersteller aufgespielte UEFI-Firmware integer bleibt, spielt dabei nur eine untergeordnete Rolle – sie wird für die Erhöhung der Sicherheit gerade runtergenommen.