Das SANCTUARY-Team deckte einen stapelbasierten Pufferüberlauf in der wolfTPM2_RsaKey_TpmToWolf-Funktion von wolfTPM auf, der auftritt, wenn RSA-Schlüssel größer als die Standardkonfiguration von 2048 Bit ohne ausreichende Grenzwertprüfung exportiert werden, wie in CVE‑2025‑7844 dokumentiert. Diese Schwachstelle tritt insbesondere auf, wenn überdimensionierte Schlüssel über Pfade für öffentliche Schlüssel importiert und nicht durch die Kompilierzeitkonfiguration begrenzt werden, was eine potenzielle Stapelbeschädigung ermöglicht. Die Gegenmaßnahme besteht im Upgrade auf die gepatchte Version (3.9.2 oder höher) oder in der Anpassung der RSA-Bitgrenzen zur Kompilierzeit, um die erwarteten Schlüsselgrößen abzubilden.
wolfTPM ist ein portabler, auf C basierender TPM-2.0-Stack und Wrapper-Layer, der von wolfSSL für den Embedded-Einsatz entwickelt wurde. Er implementsiert den TPM-2.0-Befehlssatz, stellt eine Hardwareabstraktion für gängige Buses bereit und bietet eine Wrapper-API auf hoher Abstraktionsebene, die Aufgaben wie Schlüsselerzeugung, Speicherung, Attestierung, Sealing 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 ausgiebigen Beispielen und Dokumentation für typische Workflows geliefert.
Dieser Beitrag dokumentiert einen stapelbasierten Pufferüberlauf im RSA-Export-Wrapper wolfTPM2_RsaKey_TpmToWolf. Das Problem wird öffentlich als CVE-2025-7844 und wurde in wolfTPM v3.9.2 behoben. Die Schwachstelle ermöglicht es einem Angreifer, einen Stapelpuffer fester Größe zu überschreiben, wenn ein in einem TPM residierender RSA-öffentlicher Schlüssel in einen wolfCrypt-RsaKey konvertiert wird und größer als erwartetes Schlüsselmaterial zur Laufzeit den Wrapper erreicht.
Wo der Bug sitzt
Die Wrapper-Schicht deklariert die Konvertierungsfunktion wie folgt:
WOLFTPM_API int wolfTPM2_RsaKey_TpmToWolf(OLFTPM2_DEV* dev, WOLFTPM2_KEY* tpmKey, RsaKey* wolfKey);
Zweck der Funktion ist es, den RSA-öffentlichen Modulus und Exponenten aus einem öffentlichen TPM-2.0-Bereich zu lesen und in einen wolfCrypt-RsaKey einzuspeisen. Diese API ist Teil der dokumentierten „wolfTPM2 Wrappers"-Schnittstelle, zusammen mit Hilfsfunktionen zum Import und Export von Schlüsseln, einschließlich wolfTPM2_ImportPublicKeyBuffer.
Die TPM-Strukturdefinitionen von wolfTPM folgen den TPM-2.0-Konventionen. Die RSA-öffentliche Komponente wird als TPM2B_PUBLIC_KEY_RSA dargestellt, die eine zwei Byte lange Längenangabe und einen nach dem Makro MAX_RSA_KEY_BYTES dimensionierten Modulus-Puffer enthält.
Der Bug resultiert aus einer Diskrepanz zwischen zwei Größenannahmen zur Buildzeit und einer Laufzeitgröße. wolfTPM verwendet eine Kompilierzeitkonstante 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, das standardmäßig auf 2048 festgelegt ist, sodass ein lokaler Stapelpuffer n zum Speichern von 2048/8 Bit, d. h. 256 Bytes, zugewiesen wird:
byte n[WOLFTPM2_WRAP_RSA_KEY_BITS / 8]; /* 256 bytes if 2048-bit default */
Zur Laufzeit weist der Code nSz dem Größenfeld des öffentlichen TPM-Modulus zu und kopiert dann diese Anzahl an Bytes in n, ohne zu validieren, dass nSz kleiner oder gleich sizeof(n) ist:
/* load public key */nSz = tpmKey->pub.publicArea.unique.rsa.size;XMEMCPY(n, tpmKey->pub.publicArea.unique.rsa.buffer, nSz);
Wenn ein RSA-Schlüssel mit 3072 oder 4096 Bit diesen Pfad in einem Build erreicht, der mit dem Standard-Wrapper-Puffer von 2048 Bit kompiliert wurde, überschreitet XMEMCPY den 256-Byte-Stapelpuffer und löst eine klassische CWE-121-Bedingung aus. Die RSA-öffentliche Struktur selbst ist groß genug, um größere Schlüssel zu speichern, da MAX_RSA_KEY_BYTES größere Bitgrößen berücksichtigt, sodass der Quellpuffer den Zielpuffer legitimerweise überschreiten kann.
wolfSSL hat das Problem anerkannt und CVE-2025-7844 zugewiesen. wolfTPM 3.9.2 behebt diesen Pufferüberlauf, fügt aber auch Grenzwertprüfungen im gesamten Projekt hinzu.
Warum eine Ausnutzung plausibel ist
Die Wrapper-API enthält Hilfsfunktionen, die öffentliche Schlüssel aus externen Puffern und Dateien importieren. Insbesondere kann wolfTPM2_ImportPublicKeyBuffer einen RSA-öffentlichen Schlüssel im DER- oder PEM-Format aufnehmen, ohne die TPM-Schlüsselerstellungsgrenzen einzubeziehen, was bedeutet, dass eine Anwendung TPM2B_PUBLIC-Daten im Speicher mit einem Modulus erstellen kann, der größer ist als die Standard-Erwartung des Wrappers. Über die Hardware als TPM-Keyblobs geladene Schlüssel würden typischerweise durch die TPM-Fähigkeiten begrenzt, aber extern importierte öffentliche Schlüssel profitieren nicht von dieser Hardware-Grenze. Wenn ein solcher Schlüssel anschließend in wolfTPM2_RsaKey_TpmToWolf fließt, kann die ungeprüfte Kopie den Stapelpuffer fester Größe überschreiben. Zu beachten ist, dass je nach konkretem Szenario der bösartige öffentliche Schlüssel von einem anderen Prozess erstellt und vom Opferprozess geladen werden kann, selbst ohne physische Präsenz. Je nach Kompilierflags und umgebender Frame-Struktur reichen die Konsequenzen von Programabbrüchen durch Stack-Canaries oder Sanitizers bis hin zur potenziellen Kontrolle des Programmflusses in nicht gehärteten Builds.
Patch- und Konfigurationshinweise
wolfSSL hat das Problem in v3.9.2 behoben, indem die Puffergrößenprüfungen im RSA-Export-Pfad und verwandten Bereichen verstärkt wurden. Benutzer sollten auf wolfTPM v3.9.2 oder höher upgraden. Die Release-Notizen legen fest, dass ein Stapelüberschreiben ebenfalls vermieden wird, wenn das Buildzeit-Makro MAX_RSA_KEY_BITS korrekt auf die maximal von Ziel-TPM und Anwendung unterstützte RSA-Größe gesetzt ist. Während eine korrekte Konfiguration das Risiko mindert, ist eine alleinige Abhängigkeit von der Konfiguration fragil, da Importpfade auf höherer Ebene dennoch größere öffentliche Schlüssel in den Speicher einführen können, wenn der Code-Pfad sie nicht begrenzt.
Wir möchten das wolfSSL-Team für den unkomplizierten und schnellen Prozess bedanken und Richard Mitev, Giannis Mouzenidis sowie Patrick Jauernig zu den Entdeckungen gratulieren. Diese Schwachstelle wurde während unserer laufenden ESA-Aktivität zur Nutzung eines TPM als Dienst auf einem Satelliten.
von Patrick