🔍 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 :

  • Réécrire une copie isolée du runtime Discord natif
  • Poser des sondes sémantiques ciblées sur AudioDiscardHelper::ProcessBuffers
  • Mesurer les allocations transitoires à haute fréquence pour le cas M4A
  • Attribuer précisément les comportements à des états d’exécution reproductibles

📋 Classification

Ces deux cas sont explicitement qualifiés de denial-of-service / consommation de ressources, sans démonstration d’exécution de code arbitraire. L’article est une publication de recherche / PoC technique visant à documenter des comportements reproductibles et versionnés dans Discord Desktop.

🧠 TTPs et IOCs détectés

TTP

  • T1499.003 — Endpoint Denial of Service: Application Exhaustion Flood (Impact)

IOC

  • SHA256 : a0ab9e146c629f037b86612addc1ab6fff9200711d45aa5f5edbb9576cc206ac — VT · MalwareBazaar
  • Fichiers : media-gen
  • Fichiers : media-gen.exe
  • Fichiers : short-vorbis-dual-control.webm
  • Fichiers : short-vorbis-dual-crash.webm
  • Fichiers : short-vorbis-dual-crash.json
  • Fichiers : constant-stsz.m4a

⚠️ À propos de ces IOC — ils sont extraits automatiquement de l’article original le 20 septembre 2026 et n’ont pas fait l’objet d’une vérification externe. Un indicateur peut avoir été réattribué depuis : une IP de C2 peut redevenir un service légitime, un domaine sinkholé peut changer de propriétaire. Aucune garantie d’exactitude ni d’actualité — contrôlez leur validité avant tout usage opérationnel, en particulier avant de les injecter dans une blocklist ou un SIEM.

Malware / Outils

  • media-gen (tool)
  • blare2 (tool)

🟡 Indice de vérification factuelle : 38/100 (moyenne)

  • ⬜ github.com — source non référencée (0pts)
  • ✅ 9370 chars — texte complet (fulltext extrait) (15pts)
  • ✅ 7 IOCs dont des hashes (15pts)
  • ⬜ 0/1 IOCs confirmés externellement (0pts)
  • ✅ 1 TTP(s) MITRE (8pts)
  • ⬜ date RSS ou approximée (0pts)
  • ⬜ aucun acteur de menace nommé (0pts)
  • ⬜ pas de CVE à vérifier (0pts)

🔗 Source originale : https://github.com/aftermathlabs/discord-crasher