Les recherches de JFrog sur la vulnérabilité de la chaîne d’approvisionnement logicielle soulignent la nécessité d’une meilleure visibilité sur les applications, y compris les SBOM.
Trouvé par des chercheurs de JFrog, le trou (CVE-2026-8461) est un tas d’écritures hors limites dans le décodeur MagicYUV qui peut faire planter toute application utilisant le framework. Il fonctionne dans tout, des lecteurs vidéo de bureau comme Kodi et mpv aux générateurs de vignettes de gestionnaire de fichiers Linux, en passant par les pipelines de transcodage dans le cloud (tels qu’AWS MediaConvert et Cloudflare Stream) et les serveurs multimédias auto-hébergés.
Le trou a été surnommé PixelSmash.
Les chercheurs ont déclaré avoir démontré l’exploit complet, réalisant l’exécution de code à distance sur deux cibles indépendantes : un serveur multimédia Jellyfin (via une analyse automatique de la bibliothèque) et une instance de la plateforme de collaboration Nextcloud (via le fournisseur de prévisualisation vidéo), dans les deux cas en téléchargeant simplement un fichier AVI contrefait de 50 Ko.
En fait, tout fichier multimédia contrefait (conteneur AVI, MKV ou MOV) fonctionnera sur une application qui utilise le libavcodec de FFmpeg. Même un dossier de fichiers contenant l’application est vulnérable, car le générateur de vignettes du gestionnaire de fichiers déclenchera le bug.
« Il suffit de traiter un seul fichier multimédia malveillant », affirment les chercheurs.
Il existe une solution de contournement : si le décodeur MagicYUV n’est pas nécessaire, il peut être désactivé par les développeurs au moment de la construction.
Quoi qu’il en soit, les utilisateurs de FFmpeg doivent mettre à niveau vers la version corrigée (8.1.2) dès que possible s’ils savent qu’elle se trouve dans leur application ou s’ils en sont informés par les fournisseurs.
Une dépendance fondamentale
JFrog note que FFmpeg est fourni ou lié à pratiquement toutes les applications de traitement multimédia sur chaque plate-forme. Il a confirmé des plantages contre Kodi, mpv, ffmpegthumbnailer (utilisé par GNOME, KDE, XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism et OBS Studio, entre autres.
La vulnérabilité est un bug unique dans le décodeur de codec dans FFmpeg, mais il s’agit d’une dépendance fondamentale intégrée dans des centaines de projets en aval qui se répercute sur chaque application reliant libavcodec, une bibliothèque open source qui fournit les principales capacités d’encodage et de décodage des flux audio et vidéo.
Aucun des projets concernés n’a introduit ce bug, notent les chercheurs. Ils en ont hérité silencieusement grâce à leur dépendance à FFmpeg. Et la plupart, ajoutent-ils, ne disposent d’aucun mécanisme pour le détecter ou l’atténuer de manière indépendante.
Ce n’est pas le premier problème de sécurité dans FFmpeg. Comme l’ont souligné les chercheurs de DepthFirst plus tôt ce mois-ci, l’équipe Big Sleep de Google a révélé 13 vulnérabilités et Anthropic, à l’aide de son modèle préliminaire Claude Mythos, a trouvé une faille vieille de 16 ans. En avril, les chercheurs de SentinelOne ont décrit une vulnérabilité de débordement de mémoire tampon, et en décembre dernier, les chercheurs de ZeroPath ont signalé avoir découvert sept vulnérabilités de mémoire.
Combattre les vulnérabilités de la chaîne d’approvisionnement
Les vulnérabilités de la chaîne d’approvisionnement logicielle dues aux faiblesses des bibliothèques tierces et des composants open source sont connues depuis longtemps comme un risque de sécurité. Le plus tristement célèbre est sans doute la compromission en 2020 du mécanisme de mise à jour de la plate-forme de gestion de l’infrastructure informatique SolarWinds Orion, dans laquelle un groupe de menace russe appelé APT20/Cozy Bear a installé une porte dérobée dans une mise à jour légitime qui a été destinée à 18 000 clients, bien qu’un groupe beaucoup plus petit ait été exploité.
Pour lutter contre les vulnérabilités de la chaîne d’approvisionnement, les experts affirment que les développeurs doivent adopter des stratégies pour examiner le code avant son déploiement. Ceux-ci incluent l’analyse de la composition logicielle, qui donne une visibilité sur les dépendances du logiciel, les tests de sécurité des applications statiques, les analyses de conteneurs et la création ou la génération d’une nomenclature logicielle (SBOM).
(Contenu associé : Qu’est-ce qu’un SBOM ?)
Les SBOM sont critiques
Les SBOM sont faciles à créer si un développeur crée sa propre application. Ils sont plus difficiles à obtenir à partir d’applications téléchargées ou commerciales.
Leçon : Gestion de la surface d’attaque
Calpouzos de Sonatype a déclaré que l’une des grandes leçons pour les entreprises de la découverte de PixelSmash est la gestion de la surface d’attaque. MagicYUV est un format vidéo sans perte de niche utilisé davantage dans les flux de travail de montage vidéo haut de gamme que dans la diffusion de vidéos Web grand public, a-t-il souligné, et FFmpeg est généralement construit avec chaque décodeur activé, ce qui signifie que la plupart des applications finissent par exposer des chemins de code dont elles n’auront peut-être jamais réellement besoin. Les équipes Infosec doivent s’assurer qu’elles activent uniquement les formats et les fonctionnalités que leur organisation utilise réellement dans les applications.
« C’est aussi exactement là que les SBOM sont importants », a-t-il ajouté. « La plupart des organisations ne comprennent pas parfaitement où FFmpeg est intégré, s’il est intégré ou lié statiquement, ni quelles fonctionnalités facultatives sont activées. Un SBOM aide les équipes de sécurité à passer du « Sommes-nous exposés? » à « Où sommes-nous exposés et à quelle vitesse pouvons-nous y remédier ? » À l’ère de l’IA, les attaquants et les chercheurs peuvent de plus en plus passer au peigne fin les projets open source matures à la recherche de vulnérabilités négligées dans des fonctionnalités obscures. Les organisations doivent donc savoir ce qu’elles livrent, minimiser ce qu’elles exposent, maintenir les contrôles de sécurité par défaut activés et appliquer rapidement les correctifs.
Recommandations pour les SBOM
L’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a publié une liste suggérée d’éléments minimaux qu’une nomenclature logicielle devrait inclure.
« Un mécanisme efficace de partage et d’utilisation des données logicielles doit être exploitable par machine et évolutif », note le document. « Le modèle SBOM réussit à la fois en capturant les données des composants logiciels dans un format exploitable par machine et en prenant en charge les opérations qui les analysent, les partagent et les gèrent. Les données SBOM peuvent être mappées à d’autres sources de données telles que des avis de sécurité ou des bases de données logicielles « approuvées/non approuvées » au niveau de l’organisation pour améliorer d’autres pratiques prioritaires (par exemple, le développement de logiciels sécurisés, la gestion des vulnérabilités). SBOM ne résoudra pas tous les problèmes de sécurité logicielle et de chaîne d’approvisionnement, mais c’est une étape nécessaire qui permet et renforce la prise de décision en matière de sécurité en tenant compte des risques. «
Par ailleurs, le mois dernier, le groupe de travail sur la cybersécurité du G7, qui comprend les États-Unis, l’Allemagne, le Canada, la France, l’Italie, le Japon, le Royaume-Uni et l’Union européenne, a publié des lignes directrices conjointes pour aider les acteurs des secteurs public et privé à améliorer la transparence de leurs systèmes d’intelligence artificielle (IA) et de leurs chaînes d’approvisionnement.
Les dirigeants de la sécurité de l’information doivent également cesser de réagir et adopter une approche proactive, a-t-il déclaré. Cela signifie déplacer l’application de la sécurité en amont afin que les risques soient bloqués à la porte, grâce à une gouvernance automatisée de chaque package, modèle et outil agent entrant dans le pipeline, associée à une détection des menaces basée sur l’IA, plutôt que d’y remédier à l’état sauvage après la chute d’un CVE.
