Das SANCTUARY-Team hat einen Stack-basierten Buffer-Overflow in der Funktion wolfTPM2_RsaKey_TpmToWolf von wolfTPM entdeckt, der auftritt, wenn RSA-Schlüssel, die größer als die Standardkonfiguration von 2048 Bit sind, ohne ausreichende Grenzwertprüfung exportiert werden, wie in CVE-2025-7844 dokumentiert. Diese Schwachstelle tritt insbesondere dann auf, wenn übergroße Schlüssel über Public-Key-Pfade importiert und nicht durch compile-time Konfigurationen eingeschränkt werden, was zu einer potenziellen Stack-Korruption führen kann. Zur Behebung dieses Problems muss entweder ein Upgrade auf die gepatchte Version (3.9.2 oder höher) durchgeführt oder die RSA-Bit-Grenzen zur Kompilierungszeit an die erwarteten Schlüsselgrößen angepasst werden.
wolfTPM ist ein portabler, C-basierter TPM 2.0-Stack und eine Wrapper-Schicht von wolfSSL, die für den Einsatz in eingebetteten Systemen entwickelt wurde. wolfTPM implementiert den TPM 2.0-Befehlssatz, bietet eine Hardware-Abstraktion für gängige Busse und stellt eine hochrangige Wrapper-API bereit, die Aufgaben wie Schlüsselgenerierung, Speicherung, Beglaubigung, Versiegelung und TLS-Integrationen vereinfacht. Die Bibliothek kann über die Linux-Kernel-Schnittstelle oder direkt über SPI und I²C mit Hardware-TPMs kommunizieren und wird mit umfangreichen Beispielen und Dokumentationen für typische Arbeitsabläufe ausgeliefert.
Dieser Beitrag dokumentiert einen Stack-basierten Buffer Overflow im RSA-Export-Wrapper wolfTPM2_RsaKey_TpmToWolf. Das Problem wird getrackt als CVE-2025-7844 und wurde behoben in wolfTPM v3.9.2. Die Sicherheitslücke ermöglicht es einem Angreifer, einen Stack-Bufferfester Größe zu überlaufen, wenn ein im TPM gespeicherter öffentlicher RSA-Schlüssel in einen wolfCrypt RsaKey konvertiert wird, sofern während der Laufzeit Schlüsselmaterial, das größer als erwartet ist, den Wrapper erreicht.
Ursache der Schwachstelle
Die Wrapper-Schicht deklariert die Konvertierungsfunktion wie folgt:
WOLFTPM_API int wolfTPM2_RsaKey_TpmToWolf( OLFTPM2_DEV* dev, WOLFTPM2_KEY* tpmKey, RsaKey* wolfKey);
Der Zweck der Funktion besteht darin, den öffentlichen RSA-Modul und den Exponenten aus einem öffentlichen Bereich von TPM 2.0 zu lesen und sie in wolfCrypt einzuspeisen. RsaKey. Diese API ist Teil der dokumentierten Schnittstelle „wolfTPM2 Wrappers“ und umfasst Hilfsfunktionen zum Importieren und Exportieren von Schlüsseln, darunter wolfTPM2_ImportPublicKeyBuffer.
Die TPM-Strukturdefinitionen von wolfTPM folgen den TPM 2.0-Konventionen. Die öffentliche RSA-Komponente wird dargestellt als TPM2B_PUBLIC_KEY_RSA, der eine Länge von zwei Bytes und einen Modulus-Buffer der Größe MAX_RSA_KEY_BYTES enthält.
Der Fehler ist auf eine Diskrepanz zwischen zwei Annahmen zur Größe während der Erstellungsphase und einer Größe während der Laufzeit zurückzuführen. wolfTPM verwendet eine Konstante zur Kompilierungszeit für die Größe des temporären Puffers des Wrappers. Standardmäßig leitet der Wrapper WOLFTPM2_WRAP_RSA_KEY_BITS von MAX_RSA_KEY_BITS ab, was standardmäßig auf 2048 gesetzt wird, sodass ein lokaler Stack Buffer n der Größe 2048/8 Bits, also 256 Bytes allokiert wird:
byte n[WOLFTPM2_WRAP_RSA_KEY_BITS / 8]; /* 256 bytes if 2048-bit default */
/* load public key */
nSz = tpmKey->pub.publicArea.unique.rsa.size;
XMEMCPY(n, tpmKey->pub.publicArea.unique.rsa.buffer, nSz);
Wenn ein 3072-Bit- oder 4096-Bit-RSA-Schlüssel diesen Pfad in einem Build erreicht, der mit dem standardmäßigen 2048-Bit-Wrapper-Puffer kompiliert wurde, überläuft XMEMCPY den 256-Byte-Stack-Puffer und löst eine klassische CWE-121-Bedingung aus. Die öffentliche RSA-Struktur selbst ist groß genug, um größere Schlüssel aufzunehmen, da MAX_RSA_KEY_BYTES größere Bitgrößen berücksichtigt, sodass der Quellpuffer den Zielpuffer rechtmäßig überschreiten kann.
wolfSSL hat das Problem bestätigt und die CVE-2025-7844 zugewiesen. wolfTPM 3.9.2 behebt diesen Pufferüberlauf und fügt außerdem im gesamten Projekt Bereichsprüfungen hinzu.
Die Schwachstelle scheint ausnutzbar
ie Wrapper-API enthält Hilfsprogramme, die öffentliche Schlüssel aus externen Puffern und Dateien importieren. Insbesondere kann wolfTPM2_ImportPublicKeyBuffer einen öffentlichen DER- oder PEM-RSA-Schlüssel ohne Berücksichtigung der Schlüsselgenerierungsbeschränkungen des TPM einlesen, was bedeutet, dass eine Anwendung TPM2B_PUBLIC -Daten im Arbeitsspeicher mit einem Modulus erstellen kann, der größer ist als die Standarderwartung des Wrappers. Schlüssel, die über die Hardware als TPM-Keyblobs geladen werden, unterliegen in der Regel den Einschränkungen des TPM, aber extern importierte öffentliche Schlüssel profitieren nicht von dieser Hardware-Sicherheitsvorrichtung. Wenn ein solcher Schlüssel anschließend in wolfTPM2_RsaKey_TpmToWolffließt, kann die ungeprüfte Kopie den Stack-Puffer mit fester Größe überlaufen. Beachten Sie, dass je nach konkretem Szenario der bösartige öffentliche Schlüssel von einem anderen Prozess erstellt und vom Opferprozess geladen werden kann, auch ohne physische Präsenz. Je nach Kompilierungsflags und umgebendem Frame-Layout reichen die Folgen von Programmabbrüchen mit Stack-Canaries oder Sanitisern bis hin zu potenziellen Kontrollfluss-Hijacks in nicht gehärteten Builds.
Patch- und Konfigurationsempfehlungen
wolfSSL hat das Problem in Version 3.9.2 behoben, indem die Puffergrößenprüfungen im RSA-Exportpfad und in verwandten Bereichen verschärft wurden. Benutzer sollten auf wolfTPM v3.9.2 oder höher aktualisieren. In den Versionshinweisen wird angegeben, dass ein Stapelüberlauf auch vermieden wird, wenn das Build-Zeit-Makro MAX_RSA_KEY_BITS korrekt eingestellt ist, um der maximalen RSA-Größe zu entsprechen, die vom Ziel-TPM und der Anwendung unterstützt wird. Eine korrekte Konfiguration mindert zwar das Risiko, aber sich ausschließlich auf die Konfiguration zu verlassen, ist riskant, da übergeordnete Importpfade immer noch größere öffentliche Schlüssel in den Speicher einbringen können, wenn der Codepfad diese nicht einschränkt.
Wir möchten dem wolfSSL-Team für den reibungslosen und schnellen Ablauf danken und Richard Mitev, Giannis Mouzenidis und Patrick Jauernig zu ihren Erkenntnissen gratulieren. Diese Schwachstelle wurde im Rahmen unserer laufenden ESA-Aktivität zur Nutzung eines TPM "as a Service" auf einem Satelliten entdeckt..
