(http://www.golem.de/1301/sp_96971-51619-i.jpg)
Linux muss in Secure-Boot-Umgebungen
noch weiter abgesichert werden.
(Bild: Anniolek/CC BY 3.0)
Damit die Linux-Bootloader nicht auf Microsofts schwarzer Liste landen, müssen spezielle Funktionen des Linux-Kernels besonders abgesichert werden, darunter Kexec. Das wollen Entwickler mit signierten ELF-Dateien umsetzen.
Ausführbare ELF-Dateien sollen künftig signiert werden können. Damit soll beispielsweise verhindert werden, dass über die Kernel-Funktion Kexec weitere Kernel in einer ungesicherten Umgebung gestartet werden und damit UEFIs Secure Boot aushebeln. Entwickler Vivek Goyal hat signierte ELF-Dateien vorgeschlagen und bereits entsprechende Patches und ein Werkzeug bereitgestellt. Noch handelt es sich aber um ein RFC.
Entwickler und Secure-Boot-Experte Matthew Garrett hatte auf mögliche Schlupflöcher in dem mit UEFI umgesetzten Sicherheitssystem hingewiesen. Gegenwärtig müssten zahlreiche Funktionen im Linux-Kernel abgestellt werden, denn sie könnten dazu genutzt werden, Secure Boot auszuhebeln.
Schlupfloch Kexec
Eine davon ist der Aufruf Kexec, mit dem ein laufender Kernel einen weiteren - auch unsicheren - Kernel starten kann. Wird in einer solchen Situation mit Kexec ein Windows-Kernel gestartet, wähnt sich dieser in einer sicheren Umgebung. Bleibt Kexec unsicher, könnte das Microsoft dazu veranlassen, sämtliche Bootloader, die einen Kernel mit Kexec starten, auf die schwarze Liste zu setzen und damit die Installation von Linux auf von Microsoft zertifizierter Hardware erschweren.
Kexec zu deaktivieren, kommt für die meisten Kernel-Entwickler aber nicht infrage. Deshalb schlägt Goyal vor, binäre ELF-Dateien zu signieren. Erst wenn die Signatur vom laufenden Kernel bestätigt worden ist, kann eine ELF-Binärdatei die Funktion Kexec nutzen. Ist die Datei unsigniert, soll die Funktion Kexec gesperrt werden. Die Binärdatei kann aber weiterhin gefahrlose Funktionen aufrufen. Erst wenn die Signatur nicht verifiziert werden kann, verweigert der Kernel die Arbeit der Binärdatei gänzlich.
Eingeschränkte Funktionen
Erkennt der Kernel über seine Funktion binfmt_elf eine signierte Binärdatei, werden seine Speicherseiten solange blockiert, bis die Signatur verifiziert worden ist. Damit soll verhindert werden, dass die Datei nach der Verifizierung noch ausgetauscht werden kann.
Jede ausführbare Datei im Executable and Linking Format (ELF) besitzt einen entsprechenden Header. Darin soll die kryptographische Signatur untergebracht werden, und nicht am Ende der Binärdatei wie mit den jüngst eingeführten Signaturwerkzeugen des Kernels. Die Signatur soll aus dem Hash-Wert des Inhalts der PT_LOAD-ELF-Segmente der Datei bestehen und mit einem privaten Schlüssel signiert werden. Gegenwärtig soll das aber nur mit statisch gelinkten Dateien funktionieren, denn gemeinsam genutzten Bibliotheken kann ebenfalls nicht getraut werden.
Entwicklungsbedürftig
Noch ist Goyals Vorschlag nicht ausgereift. Denn seine Patches verhindern gegenwärtig nicht die Nutzung des Aufrufs dlopen, mit dem dynamische Bibliotheken geladen werden können, oder ptrace, mit dem nach wie vor Binärdateien manipuliert werden könnten.
Zwar besitzt Linux seit Kernel 3.7 mit der Integrity Measurement Architecture (IMA) bereits einen ähnlichen Mechanismus. Allerdings enthalte Goyals Vorschlag sinnvolle Funktionen, die es dort nicht gebe, schreibt Kernel-Entwickler Johnathen Corbet, etwa die Möglichkeit, Funktionen nur einzuschränken, wenn die Binärdatei nicht signiert ist, oder das Sperren der Speicherseite, das eine zusätzliche Sicherheitsfunktion darstellt.
Bis es eine endgültige Lösung gibt, müssten Linux-Distributionen Kexec aber deaktivieren, wenn sie nicht auf Microsofts Blacklist laden wollen.
Quelle: www.golem.de
Linus Torvalds hat einen Patch des Red Hat-Entwicklers David Howells abgelehnt, der einem Kernel, der unter dem UEFI Secure Boot-Modus läuft, die Möglichkeit gibt, neue Schlüssel hinzuzufügen.
Red Hat und die Linux Foundation hatten in der Vergangenheit immer wieder betont, dass UEFI Secure Boot durchaus nützlich sei, auch wenn es einige Schwierigkeiten bereite, beispielsweise die, dass von Microsoft signierter Code der einzige ist, der die Chance hat, von allen Systemen ohne weitere Einstellungen akzeptiert zu werden, und das Verfahren, nach dem Microsoft solche Signaturen ausstellt, komplex ist.
Dass die maßgeblichen Kernel-Entwickler dies ganz anders sehen, wurde noch einmal klar, als David Howells von Red Hat einen Patch vorstellte, der einem Kernel, der unter dem UEFI Secure Boot-Modus läuft, die Möglichkeit gibt, neue Schlüssel hinzuzufügen. Wie Howells schreibt, darf in diesem Modus ein Schlüssel nur hinzugefügt werden, wenn er mit einem bereits bekannten signiert ist. Dies funktioniert bereits mit X.509-Zertifikaten, doch Microsoft signiert nur unter EFI ausführbare Dateien im PE-Format. Daher kamen die Entwickler auf die Idee, einen X.509-Schlüssel in einer PE-Datei unterzubringen und diese signieren zu lassen. Der Patch befasst sich größtenteils damit, den Schlüssel wieder aus der PE-Datei zu extrahieren.
Torvalds lehnte den Patch ab, solange er nicht ausgiebig diskutiert worden sei. Die Schnittstellen, die er erzeugt, seien dumm und übermäßig komplex, und das alles aus völlig schwachsinnigen Gründen. Auf den Einwurf von Matthew Garrett, dass es anders als mit PE-Dateien nicht zu machen sei, antwortete Torvalds: »Das ist hier kein Schwanzlutsch-Wettbewerb«. Torvalds akzeptiert auch Dinge, die ihn selbst nicht interessieren, so hat er auch grundsätzlich nichts gegen das Parsen von PE-Dateien. Nur könne das in einem normalen Anwenderprogramm durchgeführt werden und habe daher nichts im Kernel zu suchen. Im Kernel gebe es bereits X.509, und das sei der Standard für Signaturen.
Torvalds vertrat weiter die Ansicht, dass Red Hat sowieso die proprietären Treiber von AMD und Nvidia signieren werde, was alles mit dem Kernel nichts zu tun habe. Daraufhin stellte Peter Jones von Red Hat klar, dass Red Hat keine Signaturen durchführen werde.
In der weiteren Diskussion wurde klar, dass auch weitere Entwickler UEFI Secure Boot kritisch sehen. Theodore Ts'o bezeichnete das komplette System als geisteskrank. Andere sehen noch zahlreiche technische Probleme, beispielsweise bei der Frage, wie das Zurückziehen von Signaturen korrekt gehandhabt werden kann. Auch besteht noch keine Einigkeit darüber, wie strikt der Kernel den Secure Boot-Modus durchsetzen soll. Die Spannweite reicht dabei von Red Hats Ansicht, dass der Kernel keinerlei unsignierte Module nachladen dürfe, bis zu der Meinung, dass der Systemverwalter nach dem Booten des Kernels freie Hand haben solle. Die Ansicht von Red Hat, vertreten von Garrett, wird dabei von der Befürchtung getrieben, dass Microsoft die Signatur für den Bootloader zurückziehen könnte, sobald über diesen eine infizierte Version von Windows in Umlauf gelangt. Torvalds und andere sehen dies als unrealistisch an.
Die resultierende Diskussion, die von Greg Kroah-Hartman angestoßen wurde, resultierte in einem weiteren Ausbruch von Torvalds in Richtung Garrett: »Hör auf, darüber zu diskutieren, was MS will. Das ist uns egal. Wir kümmern uns um die Anwender. [...] Das einzige, was zählt, ist, was unsere Benutzer von uns wollen, und ihre Rechte zu schützen.«
Quelle: www.pro-linux.de
Für die vor Monaten entdeckte Sicherheitslücke in UEFI-Firmware stellen nun mehr PC- und Mainboard-Hersteller Patches bereit, andere geben Entwarnung - und manche forschen noch.
(http://2.f.ix.de/imgs/18/1/3/7/3/0/9/9/AldiPC-UEFI-SecBoot1-5a8166515abb830c.png)
Vor mehr als zwei Wochen berichtete heise Security über eine Sicherheitslücke in mancher UEFI-Firmware, mit der sich Schadcode ins System schleusen lassen könnte. Mittlerweile stellen nach Intel, HP und Lenovo weitere Hardware-Hersteller BIOS-Updates für verletzbare Systeme bereit. Andere geben Entwarnung: Ihre Systeme seien nicht betroffen.
Die Extreme Privilege Escalation geht auf Referenz-Code von Intel zurück, der in UEFI-Code der BIOS-Entwickler AMI und Phoenix eingeflossen ist. Deren Entwicklungsumgebungen für (UEFI-)BIOS verwenden wiederum Hersteller von Servern, Desktop-PCs, Notebooks, Mainboards und Embedded Systems mit x86-Prozessoren. Bei der Programmierung der jeweils passenden Firmware können sie aber in den modularen BIOS-"Baukästen" von AMI und Phoenix ganz unterschiedliche Komponenten auswählen – und UEFI-BIOS-Versionen, in denen der fehlerhafte Intel-Referenzcode nicht steckt, sind von dem Problem auch nicht betroffen. Es besteht auch kein Risiko, wenn ein System mit fehlerhafter UEFI-Firmware dank Compatibility Support Module (CSM) im BIOS-Modus bootet.
Der ganze Artikel (http://www.heise.de/newsticker/meldung/Mehr-Updates-gegen-die-UEFI-Sicherheitsluecke-2442775.html)
Quelle : www.heise.de