La semaine dernière, le compte @FFmpeg a commencé à narguer les chercheurs en sécurité. Une initiative malheureuse, car elle ignore l'asymétrie de leur surface d'attaque par rapport à la nôtre. À titre d'exercice, j'ai trouvé un dépassement de tampon basé sur la pile dans un logiciel qu'il a écrit. Ça m'a pris environ 20 minutes. Sujet 🧵(1/5)
J'ai d'abord remarqué que le compte FFMpeg n'est pas géré par un développeur actif de FFMpeg, mais apparemment par plusieurs personnes, dont un certain Keiran. Étrange, mais sans importance. L'utilisateur keirank sur GitHub a très peu de contributions, et aucune sur FFMPEG, mais sur Upipe, un logiciel de traitement vidéo de sa société. Examinons donc son commit le plus récent : « Validate num_delta_pocs to avoid a stack smash ». (2/5)
@FFmpeg En effet, @FFmpeg a écrit une validation, mais elle ne vérifie qu'un seul index malgré le fait qu'elle fonctionne avec des tableaux bidimensionnels de dimensions variables. Cela ne peut pas être correct. N'ayant pas eu le temps de le vérifier, j'ai demandé à un LLM de « trouver les bogues critiques dans le code ». GLM 4.6 a trouvé de nombreux résultats (3/5).
À chaque calcul d'une image prédictive, le tableau d'images de référence est incrémenté, mais cela n'est pas pris en compte lors des validations. Dépassement (surlecture). Nous avons donc un moyen de lire jusqu'à 64 octets supplémentaires dans la pile (64 étant le nombre maximal de cadres de référence). Mais peut-on écrire dans la pile ? J’ai demandé au LLM d’écrire un fuzzer de framer h265 ; c’est très complexe, mais il y parvient du premier coup (4/5).
@FFmpeg Nous avons donc maintenant un dépassement de tampon basé sur la pile en lecture/écriture. C'est la fin. Le fuzzer et une explgithub.com/ortegaalfredo/…isponibles sur mon GitHub : https://t.co/7m0i6Dmvud
