Dies sind Denial-of-Service-/Ressourcenverbrauchs-Testfälle, keine nachgewiesenen Code-Execution-Exploits. Führen Sie sie nur in einer isolierten, begrenzten Testumgebung aus.

BLARE2 Binärinstrumentierung

media-gen ist die Reproduzierbarkeitsschicht, nicht der Weg, auf dem diese Fälle entdeckt wurden. Der schwierige Teil bestand darin, das Verhalten in einer großen nativen Discord-Executable und ihren gebündelten Medienbibliotheken zu finden und zu beweisen. blare2 machte dies praktikabel, indem es eine isolierte Kopie der exakten Laufzeitumgebung umschrieb und enge Sonden ermöglichte, die Ausführung zu beobachten, ohne die installierte Anwendung zu verändern.

Für den WebM-Fall stoppte blare2s semantische Sonde exakt am AudioDiscardHelper::ProcessBuffers-Check und zeichnete den fehlerhaften Zustand auf: discarded_frames = 129 und decoder_delay = 128. Ohne diese Beobachtung würde ein Renderer-Exit mit STATUS_BREAKPOINT nur eine generische Release-Assertion identifizieren; es würde nicht feststellen, welche Medieninvariante verletzt wurde oder ob das präparierte Padding sie tatsächlich erreicht hat.

Für den M4A-Fall sind die großen Allokationen vorübergehend und können verschwinden, bevor eine normale Prozess-Stichprobe genommen wird. blare2s Exact-Runtime-Coverage und gezielte Instrumentierung, kombiniert mit hochfrequentem Prozess-Sampling und Disassembly, zeigten, dass die winzige Datei den MOV-Sample-Table-Builder erreichte und dass der deklarierte Zähler AVIndexEntry- und Timing-Table-Allokationen skalierte. Dies trennte das Problem von einem gewöhnlichen AAC-Dekodierungsfehler oder einer irreführenden Dateigrößen-/OOM-Korrelation. Breite Function-Entry-Coverage allein war nicht ausreichend: Die Dateien mit niedrigem und hohem Zähler durchliefen dieselben Funktionen, während ihre Allokationsgrößen radikal unterschiedlich waren.

blare2 ersetzte weder Container-Analyse noch Quellcode-Review oder Kontrollen, und es bewies nicht, dass Discords Produktions-Upload-/CDN-Pfad diese Bytes bewahrt. Sein Wert lag in der Laufzeit-Attribution: Es verwandelte verdächtiges Parser-Verhalten in einen reproduzierbaren, versionsgepinnten Befund mit einem exakten Fehlerzustand und einer belastbaren Allokationserklärung. Ohne Binärinstrumentierung dieser Art wäre das Finden dieser beiden Fälle erheblich langsamer und viel schwieriger zu validieren gewesen.

Build

Vom Repository-Stammverzeichnis aus:

Die Binärdatei ist target/release/media-gen (media-gen.exe unter Windows). Der Generator selbst benötigt nur Rust und die Abhängigkeiten in Cargo.toml.

WebM/Vorbis Dual-Version-Discard-Crash

Was ihn verursacht

Matroska-negatives DiscardPadding wird zu einem Vorbis-Front-Skip. Chromiums älterer Vorbis-Pfad verzögert diese Metadaten um ein kodiertes Paket; aktuelles Chromium wendet sie auf die aktuelle dekodierte Ausgabe an und verwirft die Metadaten von Paket 0, wenn dieses Priming-Paket kein PCM ausgibt. Das Wiederholen eines großen Skips über die Pakete 0 und 1 hinweg überbrückt die beiden Verhaltensweisen:

Der Track hat eine CodecDelay von 128 Frames. Im älteren verzögerten Modus wird der 577-Frame-Skip von Paket 0 auf Paket 1 angewendet. Im aktuellen Modus wird der Skip von Paket 0 verworfen und der identische Skip von Paket 1 direkt angewendet. In beiden Fällen können nach dem Decoder-Delay-Offset nur 448 Frames entfernt werden, sodass 129 Frames in Paket 2 übertragen werden. Sein positiver Front-Skip erreicht Chromiums Release-Check, nachdem diese 129 Frames bereits entfernt wurden. Die erforderliche Invariante ist discarded_frames <= decoder_delay; 129 <= 128 schlägt fehl und beendet den Renderer.

Der Generator parst die Vorbis-Setup-Header, berechnet die dekodierten Größen der Pakete 1 und 2 und schlägt fehl (fail closed), es sei denn, die Bridge ist tragfähig. Er führt dann Folgendes aus:

• konvertiert die ersten drei Audio-SimpleBlock-Elemente in BlockGroup-Elemente;
• schreibt gemeinsames negatives DiscardPadding auf die Pakete 0 und 1 und einen positiven Ein-Frame-Trigger auf Paket 2;
• bewahrt die kodierten Audio- und Video-Payloads; und
• ersetzt veraltete SeekHead-, Cues- und betroffene Cluster-CRC-Elemente, damit der umgeschriebene Container parsebar bleibt.

Das Manifest meldet den Immediate- und den Delayed-Pfad getrennt. Für das eingecheckte Beispiel benennen beide Pfade Paket 2 als Check-Paket und melden expected_carry_frames: 129 und expected_check_fails: true.

Einen Kandidaten generieren

Das Repository enthält ein 43 ms, 4.185 Byte großes Kontroll-WebM:

Die Eingabe muss enthalten:

• einen A_VORBIS-Track;
• eine positive CodecDelay (normalerweise aus dem Track gelesen); und
• mindestens drei Audio-Pakete, deren Vorbis-Modi dekodiert werden können;
• Paket-1-Ausgabe größer als die Codec-Verzögerung; und
• Paket-2-Ausgabe größer als der berechnete Carry.

Nützliche Optionen sind --trigger-skip, --codec-delay und --sample-rate. --second-skip bleibt ein Alias für die umbenannte Option --trigger-skip. Die Standardwerte sind die für den bekannten Fehlerzustand erforderlichen Werte. Der Befehl gibt den JSON-Bericht auf stdout aus und schreibt denselben Bericht nach --manifest, wenn diese Option angegeben wird.

Der eingecheckte Kandidat ist 43 ms und 4.206 Byte groß. Sein SHA-256 ist:

Es wird erwartet, dass sich der Ausgabe-Hash ändert, wenn sich die Eingabe, das Paketfenster oder die Optionen ändern.

M4A-Allokation mit konstanter Sample-Anzahl

Was sie verursacht

Der M4A-Fall missbraucht eine gültige MP4-Sample-Table-Form statt der kodierten AAC-Payload. Der Generator ändert einen Seed wie folgt:

1. Er ersetzt das explizite stsz-Sample-Size-Array durch sample_size = 1.
2. Er setzt den deklarierten Sample-Zähler in stsz, den ersten stsc-Run und den ersten stts-Run auf denselben großen Wert.
3. Er entfernt die alten expliziten Size-Einträge und repariert die Größen der Vorfahren-Boxen.
4. Er repariert den absoluten stco-Offset, sodass die Ein-Byte-AAC-Payload weiterhin in mdat zeigt.

Der gepinnte FFmpeg-Demuxer behandelt den deklarierten Zähler als maßgeblich, während er seine Index- und Timing-Tabellen aufbaut. Die relevanten Strukturen verwenden ungefähr 24 Byte pro deklariertem Sample für AVIndexEntry und 12 Byte pro Sample für Timing-Daten: insgesamt 36 Byte pro Zähler-Eintrag. Der maximal akzeptierte Zähler im getesteten Build ist 178.956.969 (0x0AAAAAA9), was Folgendes projiziert:

Der exakte Discord-Renderer erreichte einen privaten Speicher-Peak von 6.614.761.472 Byte beim Laden der Metadaten. Der benachbarte Zähler 178.956.970 wird von der gepinnten FFmpeg-Grenze abgelehnt und blieb nahe am normalen Speicher. Dies ist unkontrollierter Ressourcenverbrauch (CWE-400), kein beobachteter Integer-Wrap, keine Negative-Size-Allokation und kein Out-of-Bounds-Write. Die tatsächliche AAC-Payload kann abgeschnitten werden; erfolgreiche Wiedergabe ist nicht erforderlich, um die große Allokation zu erreichen.

Einen Kandidaten generieren

Der Generator akzeptiert absichtlich einen Seed, anstatt einen AAC-Encoder einzubetten. Verwenden Sie eine Fast-Start-AAC/M4A-Datei mit einer expliziten stsz-Tabelle, einem stsc-Run, einem oder mehreren stts-Einträgen und stco-Chunk-Offsets. Er schlägt fehl (fail closed), wenn die erforderliche Struktur fehlt.

Der Standardwert für --sample-count ist 178956969, der maximal akzeptierte Wert im gepinnten Build. Verwenden Sie einen kleineren Wert für einen Low-Memory-Smoke-Test, zum Beispiel:

--sample-count 178956970 ist eine nützliche benachbarte Rejection-Kontrolle, nicht der auslösende Wert. Das optionale Flag --moov-at-end verschiebt moov hinter mdat und aktualisiert stco/co64; es ist nützlich beim Testen einer Datei, deren physische AAC-Bytes vor ihren Metadaten auftreten, aber es ist nicht erforderlich für den Allokationsmechanismus.

Um dieses Layout explizit zu erzeugen:

Die passenden Artefakte sind samples/short-vorbis-dual-control.webm, samples/short-vorbis-dual-crash.webm, und samples/short-vorbis-dual-crash.json.