PoC : deux vulnérabilités DoS dans Discord via parsing WebM/Vorbis et M4A (Chromium/FFmpeg)
🔍 Contexte Publié le 15/09/2026 sur GitHub (aftermathlabs/discord-crasher), ce dépôt présente media-gen, 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 Discord Desktop 1.0.9257 (Electron 42.11.1 / Chromium 148.0.7778.280) et Chrome 153.0.8010.48. 🎯 Cas 1 : WebM/Vorbis — Crash du renderer (STATUS_BREAKPOINT) Mécanisme : Un fichier WebM avec une piste A_VORBIS est modifié pour exploiter un DiscardPadding négatif Matroska converti en saut avant Vorbis. Un « bridge » est construit pour couvrir à la fois l’ancien chemin Vorbis à délai d’un buffer et le chemin actuel à rejet immédiat. Impact : Le renderer se termine avec 0x80000003 (STATUS_BREAKPOINT) dans AudioDiscardHelper::ProcessBuffers de Chromium, car l’invariant discarded_frames <= decoder_delay (129 <= 128) échoue. Déclencheur : Lecture/décodage du fichier média (le simple chargement des métadonnées ne suffit pas). SHA-256 du fichier généré : a0ab9e146c629f037b86612addc1ab6fff9200711d45aa5f5edbb9576cc206ac 🎯 Cas 2 : M4A — Allocation mémoire excessive (~6,6 Go) Mécanisme : Un fichier M4A est modifié pour déclarer un nombre de samples constant (sample_count = 178,956,969) dans les tables stsz, stsc et stts. Le démuxeur FFmpeg intégré à Discord traite ce compteur comme autoritaire et alloue ~36 octets par entrée (AVIndexEntry + tables de timing). Impact : Le renderer Discord atteint un pic de mémoire privée de 6,614,761,472 octets (~6,6 Go) lors du chargement des métadonnées. Classé CWE-400 (consommation de ressources non contrôlée). Déclencheur : Chargement des métadonnées après passage de preload="none" à metadata sur l’élément audio. Valeur limite : 178,956,970 est rejetée par FFmpeg et ne déclenche pas l’allocation. 🛠️ Méthode de découverte : BLARE2 L’outil blare2 (instrumentation binaire) a été utilisé pour : ...