Willkommen zurück zu Sherlocks Schwachstellen-Spotlight, wo wir eine bedeutende Schwachstelle hervorheben, die während eines Sherlock-Audits entdeckt wurde. In dieser Woche untersuchen wir eine Denial-of-Service-Schwachstelle, die im @GMX_IO-Wettbewerb von @0xdeadbeef____ und @IllIllI000 gefunden wurde. Danke an @int0x1catedCode für die Analyse.

Zusammenfassung der Schwachstelle: Die Schwachstelle ermöglicht es einem Angreifer, den Ablauf der Auftragsausführung zu manipulieren, indem er gefälschte Längen von Rückgabereason angibt, die nicht mit den tatsächlichen Daten übereinstimmen. Dies führt dazu, dass die Fehlerbehandlung des Protokolls falsche Speicherbereiche liest, was potenziell den Ausführungsprozess stören oder unerwartetes Verhalten beim Verarbeiten fehlgeschlagener Aufträge verursachen kann.

Angriffsabläufe: 1. Einrichtungsphase Setzen Sie einen bösartigen Vertrag ein, der ein benutzerdefiniertes Rückgabeverhalten implementiert. Der bösartige Vertrag sollte vom Zielprotokoll aufrufbar sein (z. B. als Callback-Handler). 2. Bösartige Rückgabedaten erstellen Strukturieren Sie die Rückgabedaten mit einem gefälschten Längenparameter. 3. Auftrag über das Protokoll ausführen Erstellen Sie einen Auftrag, der die Interaktion mit dem bösartigen Vertrag auslöst. Wenn das Protokoll den Auftrag verarbeitet und den bösartigen Vertrag aufruft, wird es mit den erstellten Daten zurückgegeben. Die Fehlerbehandlung des Protokolls versucht, den Rückgabegrund mit der gefälschten Länge zu dekodieren. 4. Auslösen eines Speicherüberlaufes Das Protokoll liest den Speicher basierend auf dem gefälschten Längenparameter. Dies führt dazu, dass es über die tatsächlichen Grenzen der Rückgabedaten hinaus liest.

Was ist die Auswirkung? Denial of Service: Bestellungen können nicht ordnungsgemäß ausgeführt werden, was legitime Protokolloperationen wie die Liquidation von schlechten Positionen blockiert. Störung der Auftragsausführung: Die Batch-Auftragsverarbeitung kann gestoppt werden, was mehrere Benutzer betrifft. Gas-Griefing: Die Verarbeitung von fehlerhaften Rückgabedaten kann übermäßiges Gas verbrauchen.

Die Hauptursache: 1. Ungeprüfte Längenparameter: Das Protokoll vertraut dem in den Rückgabedaten angegebenen Längenwert ohne Validierung. 2. Fehlende Grenzprüfungen: Keine Überprüfung, ob die angegebene Länge mit der tatsächlichen Datengröße übereinstimmt.

Die Minderung: 1. Überprüfen Sie immer die Länge der Rückgabedaten 2. Implementieren Sie maximale Längenbeschränkungen

Wir sind stolz darauf, @GMX_IO durch diese Entdeckung abgesichert zu haben. Wenn es absolut sicher sein muss, ist Sherlock die richtige Wahl.