Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar

Eine gravierende Schwachstelle in Secure Boot hat über mehr als zehn Jahre hinweg Angreifern die Möglichkeit eröffnet, Schutzmaßnahmen auf Windows- und Linux-Systemen zu umgehen. Das Problem ist nun endlich bearbeitet worden.

Microsoft geht Probleme endlich an

Erst mit den regulären Sicherheitsupdates im Juni habe Microsoft elf veraltete, aber weiterhin als vertrauenswürdig eingestufte Komponenten gesperrt, obwohl deren Schwachstellen teils bereits seit 2013 bekannt gewesen seien. Das geht aus einem Bericht des Sicherheitsunternehmens ESET hervor.

Im Mittelpunkt standen dabei sogenannte Shims. Diese kleinen Programme wurden ursprünglich von Microsoft entwickelt, um den Secure-Boot-Mechanismus auch für Linux-Systeme und bestimmte Hilfsprogramme nutzbar zu machen. Sie dienen als zusätzliche Vertrauensinstanz beim Start eines Computers und überprüfen, welche Software während des Bootvorgangs geladen werden darf.


Nach Angaben ESETs liegt das Problem nicht in einer neu entdeckten Sicherheitslücke, sondern darin, dass Microsoft die betroffenen Shims trotz bekannter Mängel nicht rechtzeitig gesperrt habe. Dadurch könnten selbst technisch wenig versierte Angreifer ältere, weiterhin signierte Versionen einsetzen, um die Schutzfunktion von Secure Boot auszuhebeln. Anschließend ließe sich beispielsweise Firmware mit integriertem Schadcode installieren, die bereits beim Systemstart aktiv wird und auch nach einer Neuinstallation des Betriebssystems oder dem Austausch der Festplatte erhalten bleibt.

Secure Boot wurde 2012 eingeführt, um Bootkits abzuwehren. Diese Schadprogramme nisten sich tief in der Firmware eines Computers ein und gelten als besonders gefährlich, weil sie noch vor dem eigentlichen Betriebssystem ausgeführt werden. In der Vergangenheit wurden solche Angriffe unter anderem mit Malware wie LoJax, MosaicRegressor, CosmicStrand oder BlackLotus in Verbindung gebracht.

Extrem komplex

Von den elf betroffenen Shims wurden einige von Linux-Distributionen wie Red Hat, OpenSUSE und Oracle genutzt, andere stammten aus Drittanbieter-Software. Teilweise fehlten ihnen moderne Schutzmechanismen wie SBAT oder MOK-Sperrlisten, die erst nach ihrer Veröffentlichung eingeführt wurden. In anderen Fällen enthielten sie bekannte Programmierfehler.

Warum Microsoft die betroffenen Komponenten so lange nicht sperrte, ist bislang unklar. Sicherheitsforscher vermuten, dass die hohe Komplexität des Secure-Boot-Systems eine Rolle gespielt haben könnte. Mehrere Datenbanken, Zertifikate und versionsabhängige Sperrmechanismen greifen dabei ineinander, was die Verwaltung erschwert.

Windows-Nutzer, die die Sicherheitsupdates vom Juni installiert haben, gelten nach Angaben von ESET nicht mehr als gefährdet. Linux-Anwender sollten prüfen, ob ihre Distribution entsprechende Aktualisierungen bereitstellt und ob die betroffenen Shims inzwischen widerrufen wurden. Der Vorfall entfacht zugleich erneut die Debatte darüber, ob das heutige Secure-Boot-Modell angesichts seiner Komplexität langfristig noch hinreichend zuverlässig ist.


Siehe auch: