Dell, HP, Lenovo nutzen veraltete OpenSSL-Versionen im UEFI

[English]Eine Firmware-Analyse durch die Sicherheitsfirma Binarly hat aufgedeckt, dass Geräte von Dell, HP und Lenovo veraltete Versionen der OpenSSL-Verschlüsselungsbibliothek in ihren UEFI-Implementierungen  verwenden. Das stellt ein Risiko dar, da die Verschlüsselung aufgebrochen und die Lieferkette für Updates kompromittiert werden könnte. Die veralteten OpenSSL-Versionen kommt durch ein EFI Development Kit (EDK) auf diese Maschinen. Aktuell scheint es aber keine Lösung zu geben, wie die Gerätehersteller das Problem in den Griff bekommen, dass selbst in aktualisierter UEFI-Firmware bis zu drei veraltete (teilweise aus 2014 stammende) OpenSSL-Versionen verwendet werden.

OpenSSL und die Schwachstellen

OpenSSL ist eine weit verbreitete Code-Bibliothek, die eine sichere Kommunikation über das Internet ermöglicht. OpenSSL umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen sowie das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten (siehe). Anfang November 2022 gab es eine Sicherheitswarnung zu zwei Schwachstellen in dieser Bibliothek und ein Sicherheitsupdate zum OpenSSL 3.0.7 (siehe OpenSSL 3.0.7 mit Sicherheitsfix verfügbar).

Es sei aber angemerkt, dass diese Schwachstellen nur OpenSSL 3.0.0 betrafen, ältere Versionen wie OpenSSL 1.0.2 und 1.1.1 sind von der obigen Sicherheitsproblematik nicht betroffen.

Nutzen Geräte OpenSSL?

Die spannende Frage ist nun, wo OpenSSL in Geräten eingesetzt wird und ob es da ggf. ein Problem mit veralteten Bibliotheksversionen geben könnte. Denn es gibt ein EFI Development Kit (EDK) als Open-Source-Implementierung des Unified Extensible Firmware Interface (UEFI. Dieses wird von Geräteherstellern eingesetzt, um als Schnittstelle zwischen dem Betriebssystem und der in der Gerätehardware eingebetteten Firmware zu fungieren. Nun ist bekannt, dass die Version 2 (EDK II) des EFI Development Kit die OpenSSL-Bibliothek im Verschlüsselungspaket CryptoPkg verwendet.

Das war der Punkt, an dem sich die Sicherheitsfirma Binarly die Frage stellte, ob die UEFI-Implementierungen gängiger Gerätehersteller wie Dell, HP und Lenovo möglicherweise veraltete OpenSSL-Bibliotheken in der Firmware verwenden. Das Sicherheitsteam wollte wissen, wie die Update-Situation bei der UEFI-Firmware ausschaut, und wie weit verbreitet die Verwendung von OpenSSL-Versionen im Firmware-Kontext ist. Denn Microsoft hat im Defense Report 2022 ausgeführt, dass 32% der analysierten Firmware Images mindestens zehn kritische Schwachstellen aufweisen.

Alte OpenSSL-Versionen gefunden

Eine Analyse von Firmware-Images für Geräte von Dell, HP und Lenovo hat das Vorhandensein veralteter Versionen der OpenSSL-Verschlüsselungsbibliothek aufgedeckt, was ein Risiko in der Lieferkette darstellt. In diesem Dokument gibt an, dass Lenovo Thinkpad Enterprise-Geräte in demselben Firmware-Binärpaket mindestens drei verschiedene Versionen von OpenSSL verwenden.

OpenSSL-Versionen in Lenovo Firmware

Obige Tabelle zeigt die verwendeten OpenSSL-Versionen 1.0.0a (2014), 1.0.2j (2018) und  0.9.8zb (2014), die in diversen UEFI-Modulen gefunden wurden. Die jüngste OpenSSL-Version 1.0.2j wurde 2018 veröffentlicht und ist damit vier Jahre alt. Die im Infinion TPM-Update-Modul (für die Installation von Updates im TPM-Chip) benutzte OpenSSL-Version stammt sogar aus dem Jahr 2014 und weist bekannte Schwachstellen auf.

Die Entdeckung zeigte bereits zweierlei: Einmal hat die Firmware dieser untersuchten Lenovo-Geräte seit vielen Jahren keine Updates der OpenSSL-Bibliotheken durch den Hersteller erfahren. Und in der Firmware schlummern große Risiken für die Lieferkette, wenn die Update-Module für das TPM-Modul seit acht Jahren bekannte Schwachstellen aufweisen. Die aktuellste Version von OpenSSL, die auf Lenovo-Unternehmensgeräten verwendet wird, stammt von Sommer 2021.

OpenSSL-Versions benutzt von Lenovo, Dell, HP

Die Sicherheitsforscher haben dann auch Geräte von Dell und HP im Hinblick auf deren UEFI-Firmware und die verwendeten OpenSSL-Versionen analysiert. Die in diesem Artikel veröffentlichte, obige Tabelle zeigt, dass auch dort veraltete OpenSSL-Bibliotheken zum Einsatz kommen.

Aus der Binarly OpenSSL-Datenstudie geht hervor, dass Firmware häufig mehrere Versionen von OpenSSL verwendet. Der Grund dafür ist laut Binarly, dass die Lieferkette für den Code von Drittanbietern von deren eigener Codebasis abhängt. Diese Codebasis steht den Entwicklern von Geräte-Firmware oft nicht zur Verfügung. Dies führt zu einer zusätzlichen Ebene der Komplexität der Lieferkette. Die meisten OpenSSL-Abhängigkeiten sind statisch als Bibliotheken mit bestimmten Firmware-Modulen verknüpft, die zur Kompilierzeit Abhängigkeiten schaffen. Diese sind ohne tiefgreifende Code-Analyse-Fähigkeiten nur schwer zu erkennen. Das Problem der Abhängigkeiten von Drittanbieter-Code auf der Ebene des kompilierten Codes ist unter diesem Blickwinkel nicht einfach zu lösen.

Binarly beschreibt in diesem Artikel zwar den derzeitigen Industrieansatz Hashes für die einzelnen Module zu generieren, um sie mit den jeweiligen Versionsnummern zu verbinden und so die Liste der Abhängigkeiten auf SBOM-Ebene zu erstellen. Die Feststellung ist aber, dass dieser Ansatz zwar bei Open-Source-Projekten funktioniert (dort ist der Code ja einsehbar). Aber bei Closed-Source-Ökosystemen wird der Ansatz immer scheitern. Der Hash liefert Integritätsinformationen, aber er garantiert nicht den Inhalt und die Vollständigkeit der SBOM für Closed-Source-Projekte.

Binarly sieht einen dringenden Bedarf für eine zusätzliche Schicht der SBOM-Validierung wenn es um kompilierten Code geht, um auf der Binärebene die Liste der Abhängigkeitsinformationen von Drittanbietern zu validieren, die mit der vom Hersteller bereitgestellten SBOM übereinstimmen. (via)

Ähnliche Artikel:
Hinweis: Patch für OpenSSL Schwachstelle zum 1. Nov. 2022
nginx for Windows von OpenSSL Privilegien-Schwachstelle betroffen
OpenSSL 3.0.7 mit Sicherheitsfix verfügbar