Thema: Intels BIOS-Nachfolger auf dem Weg zum Standard

[SiLæncer]

Ein Konsortium, dem neben Intel auch AMD, Dell, Hewlett-Packard, IBM, Microsoft, American Megatrends und Phoenix angehören, soll eine Spezifikation für den von Intel ins Leben gerufenen BIOS-Nachfolger Extensible Firmware Interface (EFI) entwickeln. Dazu wurde das Unified EFI Forum (UEFI) gegründet. Die erste Version einer UEFI-Spezifikation soll noch bis Ende diesen Jahres auf den Weg gebracht werden.

Bei EFI handelt es sich um ein recht umfangreiches Minibetriebssystem, das künftig das BIOS von (Server-)Mainboards komplett ersetzen soll. Es ist flexibler als das in die Jahre gekommene BIOS heutiger PCs und soll den Boot-Vorgang erheblich beschleunigen. Intel feilt bereits seit einiger Zeit an EFI und hat im Rahmen des TianoCore-Projekts einen Teil der Entwicklungsplattform als Open Source freigegeben. Microsoft plant, in sämtliche XP-Nachfolger ab Windows Vista Unterstützung für EFI-konforme Systeme einzubauen.

Quelle und Links : http://www.heise.de/newsticker/meldung/62137

[ritschibie]

Windows 8 wird die neue Funktion UEFI Secure Boot erzwingen, die auf PC-Mainboards und Notebooks mit den jüngsten UEFI-Versionen ab 2.3.1 den Start unsignierter Bootloader blockiert. Ist Secure Boot aktiv, lässt sich kein Betriebssystem starten, das nicht mit einem im BIOS hinterlegten Schlüssel signiert ist. Matthew Garrett, bei Red Hat angestellter Kernelentwickler, hatte im vergangenen Jahr bereits darauf hingewiesen, dass es problematisch sein könnte, auf solcher Hardware beliebige Linux-Distributionen zu installieren, und damit eine größere Diskussion losgetreten.

Jetzt hat Garrett in seinem Blog erklärt, wie die kommende Fedora-Version 18 die UEFI-Funktion Secure Boot unterstützen soll. Ein erstes Problem ist dabei der Schlüssel, der im BIOS hinterlegt sein muss. Fedora könne natürlich einen eigenen Schlüssel erstellen und den Bootloader der Distribution damit signieren. Dank der Verbindungen von Fedora-Sponsor Red Hat könne man wohl auch viele Hardwarehersteller dazu bewegen, den Fedora-Schlüssel zusätzlich zu Microsofts Windows-Schlüssel ins BIOS ihrer Rechner zu integrieren. Allerdings sei das ein Weg, der vor allem kleineren Linux-Distributionen mangels Kontakten nicht offen steht.

Die Alternative – ein generischer Schlüssel für alle Linux-Distributionen – würde hingegen die Einrichtung einer aufwendigen und teuren Zertifizierungsinfrastruktur für Linux-Distributionen erzwingen. Garretts pragmatische Lösung: Microsoft bietet an, einen Bootloader für 99 US-Dollar zu signieren – billiger und einfacher, so der Kernelentwickler, sei die Signierung wohl nicht zu haben. Fedora 18 werde daher wohl einen von Microsoft signierten Boot-Loader enthalten.

Das wird jedoch nicht Grub sein: Um die Signierung nicht bei jedem Grub-Update erneut durchlaufen zu müssen, soll ein minimaler, offiziell signierter Bootloader vorgeschaltet werden. Der prüft dann selbst die Integrität von Grub 2 und startet den Standard-Bootloader von Linux. Um eine sichere Boot-Kette zu erhalten, wird Grub 2 in Fedora 18 keine Module nachladen können, die Kommandozeile überprüfen, die dem Kernel übergeben wird, und die Integrität des Kernels prüfen.

Alle Kernelmodule müssen ebenfalls signiert sein, und der Kernel muss das Laden unsignierter Module verweigern. Außerdem müssen einige Kernelfunktionen deaktiviert werden: Die Grundidee hinter UEFI Secure Boot ist, dass nur vertrauenswürdiger – sprich: signierter – Code auf die Hardware zugreifen darf. Jede Möglichkeit, aus dem Userspace auf Hardware zuzugreifen, wie das beispielsweise der X-Server tut, muss daher unterbunden werden.

Garrett hält diesen Ansatz selbst nicht für eine besonders attraktive Lösung: So stellt der Signierungszwang für Treiber ein – noch ungelöstes – Problem für alle Treiber dar, die nicht in der Distribution enthalten sind; und auch das Kompilieren eines eigenen Kernels wird aufwendiger. Allerdings, so Garrett, sei das zumindest ein gangbarer Weg, um UEFI Secure Boot und Linux zusammenzubringen.

Quelle: www.heise.de

[SiLæncer]

Linus Torvalds äußert sich im US-Online-Magazin ZDNet zum Thema »Secure Boot« und sieht nicht nur in der Sache selbst kein Problem, sondern zeigt auch Verständnis für den pragmatischen Vorschlag von Red Hat, z.B. für Fedora 18 einen von Microsoft signierten Bootloader verwenden zu wollen. Er könne zudem die große Aufregung bzw. die Kritik an dem Vorschlag nicht nachvollziehen.

Red-Hat-Entwickler Matthew Garrett hatte als Lösung für das Problem, dass sich Linux in Zukunft nicht mehr ohne Weiteres auf neuen Mainboards mit UEFI samt von Microsoft initiierter Secure-Boot-Funktion installieren lässt, pragmatisch vorgeschlagen, für die dazu erforderliche Schlüsselsignierung auf das Angebot von Microsoft zurückzugreifen. Die dazu aufzubringenden 99 US-Dollar führe die Entwicklung eigener, aufwendiger Lösungen ad absurdum. Zudem ginge der Betrag ja nicht an Microsoft, sondern an Versign, das den Schlüssel bereitstellt.

Billiger und einfacher sei ein für Secure Boot signierter Bootloader nicht zu bekommen. Red Hats Vorschlag zum Umgang mit der Secure-Boot-Problematik hatte in den letzten Wochen heftige Debatten ausgelöst. Linus Torvalds schließt sich der zum Teil heftigen Kritik an Red Hat offenbar nicht an, sondern teilt in einem ZDnet-Interview Garrets pragmatische Ansicht. Er könne sich sogar vorstellen, Secure Boot künftig selbst zu verwenden, sofern seine Hardware dies unterstütze.

Torvalds' pragmatische Einstellung zieht sich wie ein roter Faden durch seine gesamte Karriere und offenbart sich in vielen Debatten der letzten Jahre. Auch beim Thema UEFI analysiert Torvalds die Lage pragmatisch. »Oh ja, der Himmel wird uns bald auf den Kopf fallen und ich sollte wegen signierter Schlüssel wahrscheinlich wie ein kopfloses Huhn verzweifelt herumrennen«, gab er zu Protokoll. Solange es problemlos möglich sei, die Schlüsselüberprüfung etwa bei der Kernel-Entwicklung abzuschalten, könne Secure Boot sogar zur Systemsicherheit beitragen. Er habe sich zwar noch nicht im vollem Umfang mit möglichen Gefahren eines Missbrauchs von Secure Boot auseinandergesetzt, er könne aber die derzeit zu verzeichnende Hysterie in dieser Frage nicht nachvollziehen. Dennoch weist auch Torvalds darauf hin, dass sich möglicherweise »clevere Hacker« in den Besitz der privaten Schlüssel bringen und damit Schadcode signieren könnten. Zudem ließen sich seiner Meinung nach auch Sicherheitslücken von signierten Anwendungen ausnutzen.

Quelle : http://www.pro-linux.de/

[SiLæncer]

Canonical-Gründer Mark Shuttleworth hat seine Ideen präsentiert, wie Ubuntu auf den mit Windows 8 anstehenden Computern mit UEFI Secure Boot starten soll. Die Lösung von Fedora, den eigenen Bootloader von Microsoft signieren zu lassen, lehnt er ab; das Ökosystem freier Software dürfe nicht von Microsofts gutem Willen abhängen, wenn die Software auf moderner Hardware laufen soll.

Shuttleworth sieht UEFI Secure Boot als ein massives Problem für freie Software. Canonical suche daher nach einer Lösung, der auf breitere Akzeptanz stößt als der Ansatz von Fedora-Sponsor Red Hat. Eine konkrete Antwort gibt Shuttleworth nicht; offenbar arbeitet Ubuntu darauf hin, dass zumindest einige Hardwarehersteller Geräte mit einem Schlüssel von Canonical in der Firmware ausliefern. Auf denen würde dann allerdings nur Ubuntu laufen – es sei denn, Ubuntu bietet wie Microsoft an, die Bootloader anderer Betriebssysteme zu signieren. Auf eine entsprechende Frage des Fedora-Entwicklers Matt Garrett hat Shuttleworth bislang nicht geantwortet.

Quelle : www.heise.de

[SiLæncer]

Nachdem sich Mark Shuttleworth am vergangenen Mittwoch gegen Fedoras Pläne zum Booten von Linux auf Rechnern mit aktiviertem UEFI Secure Boot ausgesprochen hat, veröffentlichte Canonical Details zur Technik.

Ein Einsatz von Grub 2, wie ihn das Fedora-Projekt plant, kommt für Ubuntu aufgrund der Verbreitungslizenz GPLv3 nicht in Frage, da Canonical gezwungen wäre, auch den Signaturschlüssel zu veröffentlichen. Deshalb soll es künftig ein zweistufiges Bootkonzept geben, bei dem der Rechner zunächst einen einfachen, von Microsoft signierten Loader startet. Dieser prüft dann, ob der eigentliche Bootloader, efilinux von Intel, vom Ubuntu-Projekt signiert ist und startet ihn. Hier soll die Signaturkette dann auch enden, signierte Kernel-Images und -Module solles bei Ubuntu auch zukünftig nicht geben.

Hersteller, die ihre Rechner für Ubuntu zertifizieren wollen, werden den Ubuntu-Signaturschlüssel direkt in der UEFI-Firmware zusätzlich zum Microsoft-Key einspeichern müssen: Da Bootmedien nach der Ubuntu-Spezifikation lediglich mit einem Schlüssel signiert sein können, stellt Canonical so sicher, dass auch Ubuntu-zertifizierte Rechner weiterhin von den Ubuntu-Installationsmedien booten können.

Quelle : www.heise.de

[SiLæncer]

Die Red-Hat-Entwickler Kay Sievers und Harald Hoyer haben mit »Gummiboot« einen Mini-Bootloader geschrieben, der Linux auf UEFI-Mainboards starten kann. Dabei handelt es sich allerdings nicht um den von Red Hat angekündigten unkonfigurierbaren Bootloader Shim.

Laut Harald Hoyer ist Gummiboot lediglich eine Referenzimplementierung für ein neues Konfigurationsdatei-Layout. Dessen Ziel ist es, ein gemeinsames Verzeichnis für die Bootkonfigurationen aller Linux-Systeme zu entwickeln, damit sich mehrere parallel installierte Distributionen beim Booten nicht in die Quere kommen. Dabei soll Gummiboot installierte Kernel automatisch finden und in der Lage sein, einen anderen Bootloader nachzuladen, wobei Gummiboot gefundene Kernel, bzw. einen gegebenenfalls installierten Grub in einem einfachen Menü zur Auswahl anbietet und die weitergehende Konfiguration mithilfe einfacher Textdateien vornimmt. Diese müssen zusammen mit Kernel und Initrd-Dateien in der EFI System Partition installiert sein, die der Kernel mit der Option CONFIG_EFI_STUB übersetzt.

In diesem Lichte gibt es also vorerst nicht viel Neues in Sachen Linux, UEFI und Secure Boot. Fedora hatte als Antwort auf die durch Matthew Garret losgetretene Diskussion beschlossen, dessen Vorschlag mit einem von Microsoft signierten Bootloader umzusetzen. Garrets Mini-Bootloader Shim soll mit einem Schlüssel von Microsoft signiert sein und vor allem dafür sorgen, dass nicht jede kleine Änderung an Grub eine erneute Signierung durch Microsoft notwendig macht.

Canonical plant für Ubuntu ein ähnliches Verfahren, das allerdings im Gegensatz zur Fedora Methode nicht Grub, sondern den von Intel entwickelten Bootloader »efilinux« nachlädt. Darüber hinaus will Canonical im Gegensatz zu Fedora nicht die gesamte Bootkette mit eigenen Signaturen absichern. Nur efilinux wird mit einem Ubuntu-eigenen Schlüssel signiert sein, nicht aber der Kernel. Allerdings hatte sich Mark Shuttleworth unmittelbar vor Veröffentlichung dieses Ansatzes noch gegen eine Inanspruchnahme von Microsofts Signaturdienst ausgesprochen.

Quelle : http://www.pro-linux.de/

[SiLæncer]

Die Linux Foundation und ihr Technical Advisory Board (TAB) haben einen Plan vorgestellt, wie Linux leicht auf Systemen starten soll, bei denen UEFI Secure Boot aktiv ist. Der Plan umfasst den sehr einfach gehaltenen und zeitgleich veröffentlichten Pre-Bootloader "Loader", den die Linux-Foundation mit dem Microsoft-Key signieren lassen will. Typische Secure-Boot-PCs werden den zugehörigen öffentlichen Schlüssel zur Verifikation mitbringen, damit sie Windows 8 per Secure Boot starten können – daher sollten sie auch den Mini-Loader für Linux bei aktivem Secure Boot starten, sofern der nicht auf der DBX genannten Blacklist steht, die die UEFI-Firmware verwaltet.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Linux-Entwickler Matthew Garrett hat eine Version seines Secure-Boot-Loaders Shim veröffentlicht, mit dem sich alle Linux-Distributionen auf Secure-Boot-Systemen starten lassen, ohne dass UEFI Secure Boot deaktiviert werden muss. Garretts Shim-Binary ist von Microsoft signiert, sodass jede nahezu jede UEFI-Firmware den Secure-Boot-Loader ausführt.

Der ganze Artikel

Quelle : www.heise.de

[ritschibie]

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

[SiLæncer]

Diverse Samsung-Notebooks werden durch das einmalige Booten einer Linux-Distribution per UEFI so beschädigt, dass die Geräte fortan nicht mehr funktionieren. Das geht aus mehreren Berichten im Bug-Tracker von Ubuntu hervor. Das Problem dürfte aber auch bei anderen Linux-Distributionen auftreten, denn allem Anschein nach verursacht ein für Samsung-Notebooks zuständiger Treiber im Linux-Kernel das Problem. Die Kernel-Entwickler diskutieren derzeit eine Änderung, die den Treiber beim Booten via UEFI lahmlegt.

Bereits im letzten Jahr hat ein Anwender die Ubuntu-Entwickler über die Problematik informiert, nachdem er Ubuntu 12.04 oder 12.04.1 im Live-Betrieb auf einem Samsung 530U3C starten wollte; der Start erfolgte per UEFI von einem USB-Stick. Ubuntu hängte sich kurz nach dem Start des Kernels auf, woraufhin der Besitzer das Notebook durch längeres Betätigen des Ein/Austasters ausschaltete. Anschließend startete das Notebook nicht mehr – nicht einmal die Firmware zeigte sich noch. Samsung hat das Gerät im Rahmen der Gewährleistung repariert und dazu das Mainboard getauscht. Als das Ganze dann mit dem reparierten Gerät erneut passierte, informierte der Anwender die Ubuntu-Entwickler über das Problem.

Der ganze Artikel

Quelle : www.heise.de

[ritschibie]

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

[SiLæncer]

Hispalinux, die größte spanische Vereinigung von Linux- und Open-Source-Anwendern, hat Microsoft bei der Europäischen Kommission wegen Wettbewerbsbehinderung verklagt. Wie der Nachrichtendienst Reuters berichtet, bezieht sich die Klage auf UEFI Secure Boot, das Microsoft für Windows-8-Rechner vorschreibt. Bei aktiviertem UEFI Secure Boot starten PCs standardmäßig lediglich Betriebssysteme, deren Bootloader von Microsoft signiert ist.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Mit einem Update für Windows 8, Server 2012, 8.1 und Server 2012 R2 installiert Microsoft neue Schlüssel-Datenbanken, die den Start einiger UEFI-Module blockieren.

UEFI Secure Boot arbeitet mit kryptografischen Signaturen, Schlüsseln und Prüfungen, um den Start unerwünschter Software zu verhindern. Mit dem Update Rollup 2920189 nutzt Microsoft nun zum zweiten Mal die Möglichkeit, nachträglich die Schlüsseldatenbanken von Secure Boot zu verändern. Startet ein Windows-System im UEFI-Modus mit aktivierter Secure-Boot-Funktion, wird so das Laden von vier bestimmten UEFI-Modulen verhindert, die Microsoft dummerweise nicht konkret benennt.

Das Update steht für die 32- und 64-Bit-Versionen von Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 bereit, aber nicht für die Windows-RT-Versionen für Tablets mit ARM-SoCs.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Forscher entdeckten Lücken in Intels UEFI-Implementierung, durch die sich Rootkits einschleusen lassen. HP hat daraufhin Firmware-Updates für über 1500 Varianten von PCs, Notebooks, Server etc. veröffentlicht. Das ganze Ausmaß ist noch nicht absehbar.

Mitre-Forscher entdeckten zwei fatale Sicherheitslücken in Intels UEFI-Referenzimplementierung, die zahlreichen PC-Herstellern als Blaupause für ihre UEFI-Firmware dient. UEFI-Firmware läuft als BIOS auf Desktop-PCs, Notebooks, Servern, Mainboards und Embedded Systems. Durch die Schwachstellen CVE-2014-4859 und CVE-2014-4860 kann ein Angreifer die Firmware dauerhaft manipulieren, etwa um ein für das Betriebssystem unsichtbares Rootkit zu installieren. Auch das US-CERT warnt vor der Gefahr.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

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.

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

Quelle : www.heise.de