Le 0day de WebP

• Google a récemment publié une mise à jour stable de Chrome, incluant un correctif de sécurité pour un débordement de tampon sur le tas dans la bibliothèque d’images WebP, signalé par l’équipe SEAR d’Apple
• La vulnérabilité connue sous le nom de CVE-2023-4863 est activement exploitée dans la nature, ce qui signifie que quelqu’un utilisait déjà un exploit tirant parti de cette faille
• Le billet fournit une analyse technique de CVE-2023-4863 ainsi qu’un déclencheur de preuve de concept, également connu sous le nom de « WebP 0day »
• La vulnérabilité se situe dans la prise en charge de la « compression sans perte » de WebP, un format d’image sans perte capable de stocker et de restaurer les pixels avec une précision de 100 %
• Compte tenu de la complexité des codes de Huffman et des conditions spécifiques nécessaires pour déclencher le bug, il est probable que la vulnérabilité ait été découverte via une revue de code manuelle
• Le bug constitue une faille sérieuse dans une bibliothèque open source largement utilisée, et son caractère difficile à fuzzing en fait un problème de sécurité important
• Il est très probable que ce bug soit la même vulnérabilité que celle utilisée dans l’attaque BLASTPASS, liée au déploiement du spyware Pegasus du groupe NSO via un exploit « zero-click » contre iMessage
• Le billet suggère que retenir certains détails techniques de base sur le fonctionnement de ces attaques profite davantage aux défenseurs qu’aux attaquants, ce qui crée une asymétrie de l’information
• L’auteur appelle à investir davantage dans la revue proactive du code source et à mettre l’accent sur le cloisonnement adéquat des parseurs afin d’améliorer la sécurité

[GN⁺]

Réactions sur Hacker News

• Un article sur un bug du format d’image WebP, comparé au bug de Timsort de 2015
• Le bug provient d’un décalage entre la plus grande taille de table officiellement démontrée et celle saisie dans le code source
• Mise en avant de la nécessité d’une vérification formelle et de l’importance des langages à sûreté mémoire ; il est inadéquat de s’appuyer uniquement sur la relecture humaine
• Mention de la difficulté à reproduire la preuve de concept (POC) de l’exploitation, même si l’emplacement et la méthode de correction sont connus
• Question sur le fait de savoir si d’autres navigateurs basés sur Chromium, comme Brave, ont été affectés, et si le problème était limité au mobile
• Interrogation sur le rôle du code source dans la découverte du bug par NSO, avec l’hypothèse que des décompilateurs modernes auraient peut-être suffi si le code n’avait été disponible qu’en blob binaire
• Inquiétude face au fait que le simple affichage d’une image puisse poser un problème de sécurité
• Surprise de voir un bug dans la compression Huffman, une technique vieille de plusieurs décennies utilisée dans le JPEG
• Critique du manque de clarté de la spécification WebP sur la manière dont le code doit être structuré
• Éloges pour la réaction rapide d’Apple et de Chrome, mais critiques envers la gestion du problème par Google en ce qui concerne les distributions Linux
• Affirmation qu’une bibliothèque utilisée par des centaines de millions de personnes dans le monde ne devrait pas être écrite en C à cause d’un niveau de risque aussi élevé
• Critique du fait que le résumé de l’article s’appuie trop sur le fuzzing et propose la revue de code et le sandboxing comme solutions, sans plaider pour l’usage de langages à sûreté mémoire