themalwareguardian/cve-2025-70330Ein Dateiparsing-Fehler in Easy Grade Pro 4.1 wird als lehrreiches Beispiel genutzt, um zu zeigen, wie Anfänger durch Reverse Engineering mit der Schwachstellenforschung beginnen können.
Ein Lehrbeispiel, das Anfängern zeigen soll, dass Schwachstellenforschung durch Reverse Engineering von Anfang an möglich ist.
Dieses Repository entstand aus dem Bedürfnis, ein einfaches Beispiel zu haben, das beim Unterrichten von Anfängern verwendet werden kann, die mit der Schwachstellenforschung beginnen, insbesondere von denen, die sich für Reverse Engineering interessieren.
Nach Abschluss eines Kurses, einer Schulung oder eines Masterstudiengangs im Bereich Binary Exploitation oder Binary-Analyse haben viele Studenten das Gefühl, dass echte Schwachstellenforschung weit über ihrem Niveau liegt. Sie verbinden Reverse Engineering normalerweise mit sehr fortgeschrittenen Themen wie Kernel-Schwachstellen, Browser-Exploitation, Firmware-Forschung oder komplexen modernen Zielen, und deshalb glauben sie, noch nicht bereit zu sein. In der Praxis liegt das Problem nicht im Mangel an Wissen, sondern im Fehlen eines realistischen Ausgangspunkts.
Ich wollte ein Beispiel, das zeigt, dass es mit den in einem Grundkurs erlernten Fähigkeiten bereits möglich ist, ein reales Programm zu nehmen, zu verstehen, wie es funktioniert, einen Absturz auszulösen und einen echten Fehler zu identifizieren.
Dieses Repository ist genau diese Art von Beispiel. Es geht nicht darum, eine komplexe Schwachstelle zu finden. Es geht darum zu zeigen, dass Anfänger mit etwas Kleinem, Reproduzierbarem und Verständlichem beginnen und trotzdem echte Schwachstellenforschung betreiben können.
Dieses Repository steht in direktem Zusammenhang mit meinem Vortrag "Der Weg, der zu Ihrer ersten CVE führt", in dem ich erkläre, dass es mehrere Wege gibt, in die Welt der Schwachstellenforschung einzusteigen, und dass jeder Mensch je nach seinen Interessen normalerweise einem anderen Weg folgt.
Manche beginnen mit Quellcode-Auditing, andere mit Reverse Engineering, wieder andere mit Websicherheit und andere mit Technologieforschung. Alle diese Wege sind gültig, aber der wichtige Teil ist zu verstehen, dass jeder Bereich auch anfängerfreundliche Einstiegspunkte hat.
Beispiele für Anfängerpfade sind:
Diese Arten von Zielen mögen einfach aussehen, aber sie vermitteln dieselben Kernfähigkeiten, die später bei der Arbeit mit komplexen Systemen benötigt werden.
Dieses Repository repräsentiert einen dieser Anfängerpfade im Bereich Reverse Engineering.
Die hier dokumentierte Schwachstelle wurde gefunden, indem eine alte Anwendung analysiert, verstanden wurde, wie ihr Dateiformat geparst wird, und ein Programmierfehler identifiziert wurde, der zu einem Absturz führt. Die Auswirkung selbst ist nicht komplex, aber der Prozess ist real, reproduzierbar und nützlich, um zu lernen, wie Schwachstellenforschung tatsächlich funktioniert.
Dies ist die Art von Beispiel, das ich verwende, wenn ich "Der Weg, der zu Ihrer ersten CVE führt" erkläre, um zu zeigen, dass Reverse Engineering von Anfang an ein gültiger Weg ist und dass es nicht nur akzeptabel, sondern oft der beste Weg ist, mit einfachen Zielen zu beginnen.
Wenn man anfängt, sind moderne Anwendungen oft zu komplex. Sie verwenden Schutzmaßnahmen, Sicherheitsvorkehrungen und Codebasen, die ohne viel Erfahrung schwer zu verstehen sind. Alte Software ist anders.
Legacy-Anwendungen wurden nicht mit modernen Sicherheitspraktiken entwickelt. Sie enthalten oft einfache Parsing-Fehler, unsichere Speicheroperationen und Logikfehler, die mit grundlegenden Reverse-Engineering-Fähigkeiten verstanden werden können. Das macht sie ideal zum Lernen.
Mit einem alten Programm kann man: die Binärdatei zurückentwickeln, das Dateiformat verstehen, einen Absturz auslösen, den Absturz analysieren, den Fehler lokalisieren, das Problem dokumentieren und die Schwachstelle melden. Mit anderen Worten: Man lernt die grundlegenden Fähigkeiten, die jeder Schwachstellenforscher braucht.
Genau darum geht es in diesem Beispiel.
Dieses Beispiel ist wichtig, weil es etwas sehr Einfaches zeigt:
Wenn Sie Reverse Engineering mögen, können Sie diesen Weg von Anfang an gehen. Es mag Jahre dauern, es zu meistern, aber Sie müssen nicht Jahre warten, um mit echter Arbeit zu beginnen.
Die Schwachstelle (CVE-2025-70330)) betrifft die Dateiparsing-Logik von Easy Grade Pro 4.1 beim Laden proprietärer .EGP-Notenbuchdateien.
Die Anwendung rekonstruiert interne Notenbuchstrukturen, indem sie Felder an festen Positionen aus der Datei liest und diese Werte als Offsets innerhalb des geladenen Dateipuffers verwendet. Diese Offsets werden später verwendet, um Speichergrößen zu berechnen und Daten in dynamisch zugewiesene Puffer zu kopieren.
Unter normalen Bedingungen durchläuft die Datei mehrere strukturelle Prüfungen, bevor das Parsen fortgesetzt wird. Sobald diese Prüfungen jedoch erfolgreich sind, vertraut der Parser den in der Datei gespeicherten Offset-Werten, ohne zu validieren, dass sie innerhalb der Grenzen des geladenen Puffers bleiben.
Durch das Ändern bestimmter Bytes innerhalb einer ansonsten gültigen .EGP-Datei ist es möglich, diese internen Offset-Berechnungen zu korrumpieren. Wenn der Parser diese Werte später verwendet, versucht er, Speicher außerhalb des gültigen Dateibereichs zu lesen, was zu einer Zugriffsverletzung und einem Anwendungsabsturz führt.
Dieser Zustand entspricht einem Out-of-Bounds-Read (CWE-125), der zu einem lokalen Denial-of-Service führt, wenn die präparierte Datei geöffnet wird.
Das .EGP-Dateiformat wird mit einem offset-basierten Ansatz geparst. Anstatt die Datei sequentiell zu verarbeiten, liest der Parser interne Strukturen, die Start- und End-Offsets enthalten, die beschreiben, wo sich bestimmte Datenblöcke innerhalb der Datei befinden sollten.
Diese Offsets werden verwendet, um die Größe eines Speicherbereichs zu berechnen und Daten aus dem geladenen Dateipuffer in neu zugewiesenen Speicher zu kopieren.
Die anfällige Logik kann wie folgt zusammengefasst werden:
size = offset_end - offset_start + 1
buffer = calloc(1, size)
memcpy(buffer, file_buffer[offset_start - base_offset], size)
Sobald die Datei die anfänglichen Validierungsprüfungen besteht, nimmt der Parser an, dass die in der Datei gespeicherten Offsets gültig sind. Es wird keine Überprüfung durchgeführt, um sicherzustellen, dass der berechnete Quellzeiger innerhalb des geladenen Dateipuffers bleibt.
Wenn die Offsets auf kontrollierte Weise manipuliert werden, kann der Parser versuchen, Speicher außerhalb des gültigen Bereichs zu lesen, was während der memcpy()-Operation zu einer Zugriffsverletzung führt.
Nicht jede fehlerhafte .EGP-Datei löst den Absturz aus.
Der Parser führt mehrere Konsistenzprüfungen durch, bevor er den anfälligen Codepfad erreicht. Wenn die Dateistruktur zu stark beschädigt ist, stoppt die Anwendung das Parsen frühzeitig und meldet, dass das Notenbuch beschädigt ist.
Einige Modifikationen halten die internen Strukturen jedoch kohärent genug, um die anfänglichen Prüfungen zu bestehen, während sie später im Parsing-Prozess dennoch falsche Offset-Werte erzeugen.
Wenn dies passiert, erreicht der Parser tiefere Routinen, in denen diese Offsets als vertrauenswürdig angesehen und in Speicherkopieroperationen verwendet werden, was schließlich zu einem Out-of-Bounds-Read führt.
Der Absturz kann ausgelöst werden, indem eine gültige .EGP-Datei modifiziert und an einem bestimmten Offset kontrollierte Daten eingefügt werden.
Der Proof of Concept funktioniert wie folgt:
Beispielparameter, die im PoC verwendet werden:
Diese Modifikation hält die Datei strukturell gültig genug, um die anfänglichen Prüfungen zu bestehen, korrumpiert jedoch die später vom Parser verwendeten internen Offset-Berechnungen, was schließlich zum Anwendungsabsturz führt.
Wenn die fehlerhafte Datei unter einem Debugger geöffnet wird, stürzt die Anwendung während einer Speicherkopieroperation ab.
Die beobachtete Ausnahme ist eine Zugriffsverletzung, die durch einen ungültigen Speicherzugriff verursacht wird.
Während des Debuggens stammt der ungültige Zeiger, der von memcpy() verwendet wird, von Offset-Berechnungen, die aus den geparsten Dateistrukturen abgeleitet wurden. Wenn diese Offsets auf Speicher außerhalb des geladenen Dateipuffers verweisen, zeigt der Quellzeiger auf eine nicht zugeordnete Adresse, was den Absturz verursacht.
Dies bestätigt, dass die Schwachstelle durch fehlende Grenzvalidierung während des Dateiparsings verursacht wird.
Diese Schwachstelle betrifft ein Produkt, das das Ende seines Lebenszyklus erreicht hat und vom Hersteller nicht mehr gewartet wird.
Das Problem wird zu Bildungs- und Forschungszwecken dokumentiert, um Anfängern ein konkretes Beispiel zu geben, wie Software Schritt für Schritt analysiert werden kann, um zu verstehen, wie Fehler entstehen und wie echte Schwachstellen gefunden werden.