yousif-iq/cve-2026-39259CVE-2026-39259
Projekt: https://github.com/alexfru/SmallerC
Die scanf-Implementierung von SmallerC erzwingt keine Obergrenze für String-Lesevorgänge, wenn %s oder %[ ohne explizite Feldbreite im Formatstring verwendet wird. Die Laufzeitumgebung schreibt weiterhin in den Zielpuffer, bis sie ein Leerzeichen oder EOF erreicht – unabhängig von der tatsächlichen Größe des Puffers. Alle Bytes, die über die Grenze hinausgehen, landen direkt auf dem Stack und überschreiben, was der Compiler oberhalb des Puffers platziert hat: lokale Variablen, gespeicherte Register, die Rücksprungadresse.
Es handelt sich hierbei nicht um eine neue Schwachstellenklasse. Unbegrenzte scanf-String-Lesevorgänge sind seit den Anfängen von C dokumentiert, und jedes kompetente statische Analysewerkzeug wird sie erkennen. Was diesen Bericht im Kontext von SmallerC dennoch relevant macht, ist die Zielumgebung. SmallerC ist für DOS und Bare-Metal-Eingebettetensysteme konzipiert – Plattformen, die per Definition keine Stack Canaries, ASLR, NX-Bits oder sonstige Gegenmaßnahmen bieten, die eine Ausnutzung auf modernen Systemen erschweren. Dasselbe Primitiv, das auf einem gehärteten Linux-Binary einen erheblichen Forschungsaufwand erfordern würde, um daraus einen funktionierenden Exploit zu machen, wird auf einem DOS-Programm mit flachem, vorhersagbarem Stack deutlich handhabbarer.
Der Puffer ist 16 Bytes groß. Die Eingabe besteht aus 20 Nicht-Leerzeichen-Bytes. Die %s-Konvertierung hat keinen Breitenspezifizierer, daher liest sscanf alle 20 Bytes plus einen Nullterminator – insgesamt 21 Bytes – in eine 16-Byte-Allokation. Die 5 Bytes jenseits der Grenze korrumpieren den benachbarten Stack-Speicher. Was genau korrumpiert wird, hängt von der Stack-Layout-Entscheidung des Compilers für diese bestimmte Funktion ab, aber die Überschreibung selbst ist deterministisch und bedingungslos, sobald dieser Codepfad mit dieser Eingabe durchlaufen wird.
Proof of Concept
#include <stdioh>
#include <stringh>
/*
* Build with SmallerC targeting DOS or bare-metal
* Demonstrates unbounded %s write past a fixed stack buffer
*
* buffer is 16 bytes payload is 20 non-whitespace bytes
* sscanf writes 21 bytes (20 + null terminator) into buffer
* corrupting 5 bytes of adjacent stack memory
*
* To observe the corruption inspect stack memory after the call:
* the 5 bytes immediately above buffer will contain 'A' (0x41)
*/
int main() {
char buffer[16];
char canary[8];
memset(buffer 0x00 sizeof(buffer));
memset(canary 0xCC sizeof(canary)); /* marker to detect overwrite */
printf("[*] canary before: ");
for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
printf("\n");
sscanf("AAAAAAAAAAAAAAAAAAAA" "%s" buffer); /* 20 bytes into 16-byte buffer */
printf("[*] canary after: ");
for (int i = 0; i < 8; i++) printf("%02x " (unsigned char)canary[i]);
printf("\n");
if (memcmp(canary "\xCC\xCC\xCC\xCC\xCC\xCC\xCC\xCC" 8) != 0)
printf("[!] stack corruption confirmed canary overwritten\n");
else
printf("[-] canary intact (stack layout placed it elsewhere)\n");
return 0;
}
Erwartete Ausgabe bei einem betroffenen Build:
[*] canary before: cc cc cc cc cc cc cc cc
[*] canary after: 41 41 41 41 41 cc cc cc
[!] stack corruption confirmed canary overwritten
Die Platzierung des Canary relativ zum Puffer hängt vom Stack-Layout des Compilers ab. Wenn die Ausgabe zeigt, dass der Canary intakt ist, findet die Überschreibung trotzdem statt – sie landet dann auf etwas anderem oberhalb des Puffers. Passen Sie den Reproducer an, indem Sie den tatsächlichen Stack-Frame mit einem Debugger untersuchen, um zu lokalisieren, wo die 5 korrumpierenden Bytes landen.
Eine Korrektur, die explizit erwähnt werden sollte: Einige Berichte dieser Schwachstellenklasse versuchen, die Kontrolle über die Rücksprungadresse zu demonstrieren, indem sie nach einem Null-Byte im Payload eine Zieladresse anhängen, wie "AAAAAAAAAAAAAAAAAAA\x00\x90\x04\x08". Das funktioniert nicht. Die %s-Konvertierung in sscanf behandelt \x00 als String-Terminator und stoppt das Lesen sofort, wenn sie darauf trifft. Die Bytes nach dem Null-Byte werden nie verarbeitet. Um eine tatsächliche Kontrolle über die Rücksprungadresse zu demonstrieren, muss die Überschreibung ohne Null-Byte im kritischen Teil des Payloads erfolgen, was wiederum die genaue Kenntnis des Stack-Layouts des Ziel-Binaries erfordert – den Abstand vom Puffer zur gespeicherten Rücksprungadresse, ob der Compiler Padding eingefügt hat und welche Ausrichtungsbeschränkungen gelten. Nichts davon ergibt sich automatisch aus diesem Reproducer.
Was der Reproducer jedoch sauber nachweist, ist das Korruptionsprimitiv selbst. Der Schreibzugriff außerhalb der Grenzen ist real, reproduzierbar und hängt von keiner Race Condition oder Zeitsteuerung ab. Auf einem DOS- oder Embedded-Zielsystem, bei dem das Stack-Layout über Builds hinweg statisch und vorhersagbar ist, ist der Schritt von diesem Primitiv zu einem funktionierenden Exploit ein realistischer Forschungsaufwand und keine theoretische Übung.
Das betroffene Szenario ist eng, aber nicht konstruiert. Ein Programm muss mit SmallerC gebaut werden, scanf-artiges Parsing mit einem unbegrenzten %s- oder %[-Spezifizierer verwenden, in einen Stack-Puffer fester Größe schreiben und Eingaben aus einer Quelle akzeptieren, die der Angreifer beeinflussen kann. Alle vier Bedingungen müssen gleichzeitig erfüllt sein. Programme, die korrekte Feldbreiten verwenden – %15s für ein char[16] – sind nicht betroffen. Programme, die keine angreiferkontrollierte Eingabe parsen, sind nicht betroffen. Das Problem ist ein Defekt in der Art und Weise, wie die SmallerC-Laufzeitumgebung die fehlende Breitenbeschränkung behandelt – aber es wird nur dann zu einem Sicherheitsproblem, wenn der Anwendungscode diesen Defekt unvertrauenswürdigen Eingaben aussetzt.
Auf Anwendungsseite ist die Lösung einfach: Geben Sie eine Feldbreite an, die Platz für den Nullterminator lässt – %15s für einen 16-Byte-Puffer, %63s für einen 64-Byte-Puffer. Dies ist gängige C-Praxis und wird von der Formatstring-Syntax vollständig unterstützt. Auf Seiten des SmallerC-Projekts besteht die nachhaltigere Arbeit darin, Regressionstests hinzuzufügen, die sowohl begrenztes als auch unbegrenztes %s- und %[-Verhalten in scanf, sscanf und fscanf abdecken, um zu überprüfen, dass explizite Feldbreiten in der Implementierung tatsächlich eingehalten werden, und das unsichere Muster prominent zu dokumentieren. Eine Compiler-Diagnose, die warnt, wenn %s oder %[ ohne Feldbreite in einem Formatstring-Literal erscheint, würde diese Art von Fehler proaktiv verhindern und wäre eine sinnvolle Erweiterung der Toolchain.
Der Schweregrad ist Mittel, wenn externe Eingaben den verwundbaren Codepfad erreichen. Er sinkt auf Niedrig, wenn die Eingabe lokal oder nicht privilegiert ist. Die Zielumgebung – insbesondere das Fehlen moderner Exploit-Gegenmaßnahmen auf SmallerCs vorgesehenen Plattformen – ist das, was diesen Bericht von einer allgemeinen „Nicht unbegrenztes scanf verwenden“-Empfehlung unterscheidet und es wert macht, auf Projektebene gemeldet zu werden, anstatt es ausschließlich als Anwendungsfehlgebrauch zu behandeln.
Credit: Yousif Wazni