← Networkit Tutos
Bug de division par zéro dans FFmpeg : le fuzzer "vibecoded" fait mouche

Bug de division par zéro dans FFmpeg : le fuzzer "vibecoded" fait mouche

Un chercheur a identifié une faille critique dans le cœur du traitement vidéo open source grâce à un outil de fuzzing généré par IA, illustrant la convergence entre développement automatisé et cybersécurité.

En bref

Contexte

FFmpeg est le socle invisible de l'infrastructure médiatique mondiale. Que ce soit pour le streaming vidéo, l'encodage dans les applications mobiles ou le traitement média côté serveur (transcoding), cette bibliothèque C est omniprésente. Sa complexité, héritée de décennies de développement et d'une multitude de formats supportés (depuis les codecs propriétaires obsolètes jusqu'aux standards modernes comme H.265/HEVC ou AV1), en fait une cible privilégiée pour les chasseurs de bugs.

Traditionnellement, la découverte de vulnérabilités dans ce type de code repose sur deux piliers : l'audit manuel par des experts en sécurité (comme ceux d'Aqua Security ou de Rapid7) et le fuzzing massif automatisé (via AFL++, libFuzzer ou Magma). Ces méthodes sont efficaces mais coûteuses en temps de calcul et en expertise pour configurer les oracles de test.

L'épisode rapporté ici marque un tournant méthodologique. Un contributeur a utilisé la technique dite du "vibecoding" — terme émergent désignant le développement assisté par IA où l'humain guide la logique et l'IA génère le code concret — pour construire un fuzzer spécifique à FFmpeg. Contrairement aux fuzzers génériques qui bombardent des entrées aléatoires, ce fuzzer "vibecoded" a été conçu pour comprendre la structure sémantique des paquets média et générer des séquences de données valides mais malformées, ciblant précisément les chemins d'exécution fragiles.

Ce n'est pas une première absolue en matière d'IA appliquée à la sécurité (des projets comme FuzzGPT ou l'utilisation de LLMs pour générer des PoC existent), mais c'est la démonstration concrète, validée par un bug réel dans un projet majeur, que cette approche réduit drastiquement la barrière à l'entrée pour la découverte de vulnérabilités complexes. Le ticket référencé (code.ffmpeg.org/FFmpeg/FFmpeg/issues/24290) sert de preuve d'existence : le bug est réel, il a été reproduit, et il est désormais dans le radar des mainteneurs.

Détails techniques

La faille identifiée est une division par zéro (Division by Zero). Dans le contexte du traitement vidéo, ce type d'erreur survient généralement lors du calcul de paramètres géométriques ou temporels :

Bien qu'une simple division par zéro entraîne souvent un crash propre (Signal SIGFPE en Linux), elle peut devenir critique si :

  1. Le résultat de la division est utilisé comme index de tableau sans vérification préalable.
  2. Le crash permet d'atteindre un état mémoire incohérent exploitable par un attaquant (ex: corruption de pointeur suite à une exception non gérée).

L'approche "Vibecoded Fuzzer"

Le processus décrit implique l'utilisation d'un LLM pour générer le squelette du fuzzer. Voici un schéma mental de ce que cela implique techniquement :

  1. Analyse Statique Assistée : L'IA analyse les signatures des fonctions de décodage (ex: ff_decode_frame) et identifie les variables potentiellement nulles ou non initialisées avant une opération arithmétique.
  2. Génération du Fuzzer : Au lieu d'écrire manuellement des règles de mutation complexes, le développeur demande à l'IA de générer un fuzzer basé sur libFuzzer qui construit des paquets valides (en respectant les headers RFC ou spécifications AVI/MKV) mais injecte des valeurs extrêmes dans les champs numériques.
  3. Boucle de Rétroaction : L'exécution du fuzzer génère des crashs. Les logs sont renvoyés à l'IA qui ajuste la stratégie de mutation pour cibler davantage le chemin d'exécution problématique.

Exemple conceptuel de code généré (pseudocode illustratif)


// Fuzzer généré via assistance LLM pour tester les divisions dans le décodeur
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // 1. Validation minimale de la structure du conteneur (générée par IA)
    if (size < MIN_HEADER_SIZE) return 0;
    
    // 2. Extraction des champs critiques potentiellement divisants
    // L'IA a identifié que 'width', 'height' et 'stride' sont utilisés dans des divisions
    uint32_t width = read_uint32(data, OFFSET_WIDTH);
    uint32_t height = read_uint32(data, OFFSET_HEIGHT);
    
    // 3. Injection de valeurs dangereuses (0 ou très grandes) pour forcer le crash
    // C'est ici que la "vibe" du fuzzer cible spécifiquement les divisions par zéro
    if (width == 0 || height == 0) {
        // On force l'appel au décodeur avec ces valeurs invalides mais syntaxiquement plausibles
        // pour tester la robustesse des checks internes de FFmpeg
        AVCodecContext *ctx = avcodec_alloc_context3(codec);
        ctx->width = width;
        ctx->height = height;
        
        // Appel direct à la fonction suspecte (hypothétique)
        int ret = ff_decode_frame_internal(ctx, data, size); 
        
        // 4. Vérification du crash ou comportement anormal
        if (ret < 0 && ret != AVERROR_INVALIDDATA) {
            // Log pour analyse post-mortem
            fprintf(stderr, "Potential division by zero path triggered\n");
        }
        
        avcodec_free_context(&ctx);
    }
    
    return 0;
}

Note : Le code ci-dessus est une illustration pédagogique du type de logique qu'un fuzzer ciblé peut implémenter. La faille réelle dans FFmpeg (Issue #24290) concerne un chemin spécifique non détaillé dans l'extrait, mais le mécanisme de découverte reste identique.

La puissance de cette méthode réside dans la capacité de l'IA à naviguer dans l'immensité du codebase d'FFmpeg (plusieurs centaines de milliers de lignes de C) pour identifier les "hotspots" arithmétiques sans avoir besoin d'une compréhension humaine exhaustive de chaque module.

Implications pour les consultants IT

Pour les architectes, administrateurs systèmes et consultants en sécurité, cette évolution change trois paramètres fondamentaux :

1. La surface d'attaque se rétrécit, mais la vitesse de découverte augmente.

Les entreprises qui dépendent d'FFmpeg (via des paquets comme libavcodec, ffmpeg CLI, ou des frameworks web intégrant le transcoding) doivent accélérer leur cycle de patching. Si les vulnérabilités sont découvertes plus rapidement par des outils moins coûteux en main-d'œuvre experte, la fenêtre d'exposition entre la découverte et l'exploitation devient critique. Les SLA de sécurité interne doivent refléter cette accélération.

2. Le "Security by Obscurity" est mort.

Pendant longtemps, la complexité du code C d'FFmpeg offrait une certaine protection par obscurité aux attaquants non experts. L'émergence de fuzzers assistés par IA démocratise l'accès à la découverte de bugs profonds. Un consultant en audit ne peut plus se contenter de vérifier les configurations ; il doit exiger des preuves de robustesse (tests de charge, validation d'entrées) pour tout composant média critique dans la chaîne applicative.

3. Nouvelle compétence requise : le "Prompt Engineering" pour la sécurité.

Les profils techniques doivent commencer à intégrer l'utilisation des LLMs non seulement pour le développement, mais aussi pour la génération de tests et de fuzzers. Savoir guider un modèle IA pour qu'il génère des cas de test adversariaux contre une bibliothèque spécifique devient un avantage compétitif majeur. Cela réduit le temps nécessaire pour auditer des dépendances tierces complexes.

4. Vigilance sur les chaînes d'approvisionnement.

Beaucoup d'applications SaaS et PaaS intègrent FFmpeg en arrière-plan sans que l'utilisateur final ne le sache (ex: services de transcription, plateformes de streaming). En tant que consultant, vous devez identifier ces dépendances invisibles dans vos architectures clients. Un bug dans FFmpeg peut impacter des applications qui n'ont "rien à voir" avec la vidéo en surface, mais utilisent le moteur sous-jacent pour le traitement audio ou les métadonnées.

Pour aller plus loin

Partager LinkedIn X E-mail