https://cyberveille.ch/tags/webm/ Recent content in WebM on CyberVeille Hugo -- 0.146.0 fr-fr Cyberveille CC BY-NC-SA 4.0 Sun, 20 Sep 2026 00:00:00 +0200 https://cyberveille.ch/posts/2026-09-20-poc-deux-vulnerabilites-dos-dans-discord-via-parsing-webm-vorbis-et-m4a-chromium-ffmpeg/ Sun, 20 Sep 2026 00:00:00 +0200 https://cyberveille.ch/posts/2026-09-20-poc-deux-vulnerabilites-dos-dans-discord-via-parsing-webm-vorbis-et-m4a-chromium-ffmpeg/ <h2 id="-contexte">🔍 Contexte</h2> <p>Publié le 15/09/2026 sur GitHub (aftermathlabs/discord-crasher), ce dépôt présente <code>media-gen</code>, un outil en ligne de commande Rust permettant de générer deux cas de test de vulnérabilités de parsing média affectant <strong>Discord Desktop 1.0.9257</strong> (Electron 42.11.1 / Chromium 148.0.7778.280) et <strong>Chrome 153.0.8010.48</strong>.</p> <h2 id="-cas-1--webmvorbis--crash-du-renderer-status_breakpoint">🎯 Cas 1 : WebM/Vorbis — Crash du renderer (STATUS_BREAKPOINT)</h2> <ul> <li><strong>Mécanisme</strong> : Un fichier WebM avec une piste <code>A_VORBIS</code> est modifié pour exploiter un <code>DiscardPadding</code> négatif Matroska converti en saut avant Vorbis. Un « bridge » est construit pour couvrir à la fois l&rsquo;ancien chemin Vorbis à délai d&rsquo;un buffer et le chemin actuel à rejet immédiat.</li> <li><strong>Impact</strong> : Le renderer se termine avec <strong><code>0x80000003</code> (STATUS_BREAKPOINT)</strong> dans <code>AudioDiscardHelper::ProcessBuffers</code> de Chromium, car l&rsquo;invariant <code>discarded_frames &lt;= decoder_delay</code> (<code>129 &lt;= 128</code>) échoue.</li> <li><strong>Déclencheur</strong> : Lecture/décodage du fichier média (le simple chargement des métadonnées ne suffit pas).</li> <li><strong>SHA-256 du fichier généré</strong> : <code>a0ab9e146c629f037b86612addc1ab6fff9200711d45aa5f5edbb9576cc206ac</code></li> </ul> <h2 id="-cas-2--m4a--allocation-mémoire-excessive-66-go">🎯 Cas 2 : M4A — Allocation mémoire excessive (~6,6 Go)</h2> <ul> <li><strong>Mécanisme</strong> : Un fichier M4A est modifié pour déclarer un nombre de samples constant (<code>sample_count = 178,956,969</code>) dans les tables <code>stsz</code>, <code>stsc</code> et <code>stts</code>. Le démuxeur FFmpeg intégré à Discord traite ce compteur comme autoritaire et alloue ~36 octets par entrée (<code>AVIndexEntry</code> + tables de timing).</li> <li><strong>Impact</strong> : Le renderer Discord atteint un <strong>pic de mémoire privée de 6,614,761,472 octets</strong> (~6,6 Go) lors du chargement des métadonnées. Classé <strong>CWE-400</strong> (consommation de ressources non contrôlée).</li> <li><strong>Déclencheur</strong> : Chargement des métadonnées après passage de <code>preload=&quot;none&quot;</code> à <code>metadata</code> sur l&rsquo;élément audio.</li> <li><strong>Valeur limite</strong> : <code>178,956,970</code> est rejetée par FFmpeg et ne déclenche pas l&rsquo;allocation.</li> </ul> <h2 id="-méthode-de-découverte--blare2">🛠️ Méthode de découverte : BLARE2</h2> <p>L&rsquo;outil <strong>blare2</strong> (instrumentation binaire) a été utilisé pour :</p>