Comment détecter et corriger la vulnérabilité zero-day critique WebP CVE-2023-4863

Le mois dernier, deux vulnérabilités critiques (CVE-2023-4863 et CVE-2023-5129) ont été identifiées par Apple Security Engineering and Architecture (SEA), en collaboration avec The Citizen Lab de la Munk School de l’Université de Toronto. Ces vulnérabilités impliquaient des images WebP conçues de manière malveillante pour exploiter les navigateurs basés sur Chromium et la bibliothèque webmproject/libwebp fournie par Google. Pour en savoir plus sur la vulnérabilité et son historique récent, consultez notre précédent article de blog.

En particulier, la vulnérabilité de libwebp ne concerne pas seulement les navigateurs : elle affecte également les écosystèmes de développement, les systèmes d’exploitation et les conteneurs. Voici tous les écosystèmes et conteneurs que nous avons identifiés comme étant concernés par libwebp :

L’étendue de l’impact de cette vulnérabilité est considérable : elle est détectée dans divers écosystèmes de développement, comme dépendance directe ou transitive. On la trouve principalement comme dépendance transitive dans les projets Cocoapods, Swift et Python, ce qui peut compliquer la prise de conscience de son impact par les développeurs. Cependant, Snyk Container et Snyk Open Source peuvent tous deux détecter les packages concernés. Vous pouvez utiliser Snyk gratuitement dès maintenant pour déterminer lesquels de vos projets les intègrent.

Même si nous avons réalisé une analyse approfondie de l’impact de libwebp, les experts en sécurité continuent d’étudier les différents usages de libwebp dans les applications, les écosystèmes et les systèmes d’exploitation. La vulnérabilité affectant les composants logiciels qui utilisent des codecs d’image .webp et en affichent le contenu (navigateurs, outils de conception, etc.), son périmètre ne cessera de s’étendre. Il est donc essentiel de suivre l’actualité de libwebp.

Cet article de blog vise à mieux comprendre l’impact de cette vulnérabilité sur les écosystèmes logiciels et à servir de référence rapide pour y remédier.

Au 3 octobre 2023, les CVE connues qui suivaient activement cette vulnérabilité de libwebp étaient les suivantes :

• CVE-2023-4863 : publiée le 11 septembre 2023, avec un score CVSS de 9.6 et un score EPSS de 31.86 % (97e percentile). Remarque : le score initial de cette CVE était de 8.8 (« Élevé »), avant la divulgation d’informations supplémentaires. 

• CVE-2023-5129 : publiée le 25 septembre 2023, avec un score CVSS de 10 (le maximum possible), puis rejetée le 27 septembre 2023 par Google, l’autorité chargée de l’attribution des numéros CVE, car il s’agissait d’un doublon ;

Pour en savoir plus sur la vulnérabilité et son historique récent, consultez notre précédent article de blog. Dans cet article, nous allons passer en revue les recommandations de correction suivantes :

1. Repérer où vous utilisez libwebp

2. Mettre à niveau vers libwebp 1.3.2 ou une version ultérieure

3. Surveiller les projets à l’aide de la prise en charge des PR automatiques

1. Repérer où vous utilisez libwebp

La difficulté principale lorsqu’on remédie à une vulnérabilité zero-day consiste à déterminer si vous êtes concerné et où. La vulnérabilité de libwebp ne fait pas exception. libwebp peut être une dépendance de votre projet, directement ou indirectement, en tant que dépendance transitive. Il est donc essentiel de la repérer pour pouvoir corriger le problème correctement : il est très probable que vous soyez concerné à un certain degré sans le savoir. Les éléments suivants peuvent notamment être touchés : 

• Tout logiciel que vous développez et qui dépend directement de la bibliothèque libwebp ou indirectement par l’intermédiaire de dépendances transitives est concerné par la vulnérabilité.

• Tout logiciel que vous utilisez pour encoder et/ou décoder des images .webp est concerné par la vulnérabilité.

• Tous les systèmes d’exploitation ou images de conteneur qui incluent des outils de traitement des images .webp sont concernés par la vulnérabilité.

L’une des raisons pour lesquelles cette vulnérabilité a un impact si étendu sur les écosystèmes de développement est que des langages de programmation de plus haut niveau utilisent la bibliothèque sous-jacente libwebp. Par exemple, le moteur de jeu GoDot, utilisé pour créer des jeux en 2D et en 3D, dépend de la bibliothèque libwebp, tout comme l’utilitaire FFmpeg, très répandu, qui utilise également la bibliothèque libwebp.

Détecter la vulnérabilité libwebp avec Snyk

Snyk vous permet de détecter la vulnérabilité de libwebp de différentes manières, gratuitement. Avec la Snyk CLI, vous pouvez tester vos projets en local :

• Pour les applications, exécutez snyk test --unmanaged avec la Snyk CLI afin de comparer les dépendances non gérées de votre dépôt et de détecter les packages concernés et leurs vulnérabilités.

• Pour les conteneurs, exécutez snyk container test afin de détecter les packages du système d’exploitation qui dépendent de versions vulnérables de libwebp.

Vous pouvez également analyser tous vos projets dans vos dépôts Git pour obtenir un rapport sur l’ensemble des dépendances directes et transitives que vous utilisez. Ce rapport vous indiquera si vous utilisez libwebp et dans combien de chemins de votre graphe de dépendances elle apparaît. Vous pouvez également rechercher rapidement « CVE-2023-4863 » dans tous vos projets. 

2a. Mettre à niveau vers libwebp 1.3.2 ou une version ultérieure (open source)

• Correction automatique : Connectez Snyk à vos dépôts Git pour lui permettre de créer des pull requests afin de mettre à jour votre graphe de dépendances lorsque c’est possible. Puis reconstruisez votre application.

• Correction manuelle : Si votre application utilise libwebp comme dépendance directe, mettez directement à jour votre fichier de dépendances vers la version 1.3.2 ou une version ultérieure. Puis reconstruisez votre application.

• Correction manuelle : Si votre application utilise libwebp comme dépendance transitive, identifiez une version de votre dépendance directe qui inclut la dépendance transitive libwebp en version 1.3.2 ou ultérieure. Puis reconstruisez votre application.

2b. Mettre à niveau vers libwebp 1.3.2 ou une version ultérieure (conteneur)

• Correction automatique : Connectez Snyk à vos dépôts Git pour lui permettre de créer des pull requests afin de mettre à jour l’image de base de votre Dockerfile lorsque c’est possible. Vérifiez si la mise à niveau de l’image de base proposée est toujours vulnérable à l’adresse https://snyk.io/test/docker/<image_name> , puis reconstruisez votre conteneur après avoir identifié une voie de mise à niveau acceptable.

• Correction manuelle : Si votre image contient une version vulnérable de libwebp et qu’une mise à niveau de l’image de base n’est pas disponible ou souhaitable, vous pouvez la mettre à niveau vous-même en suivant les conseils de correction de Snyk Container.  Exemple : sur une image basée sur Debian, si la CLI Snyk Container affiche ce qui suit :

✗ High severity vulnerability found in libwebp/libwebpdemux2
  Description: Out-of-bounds Write
  Info: https://security.snyk.io/vuln/SNYK-DEBIAN12-LIBWEBP-5918869
  Introduced through: imagemagick@8:6.9.11.60+dfsg-1.6, imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6, libwebp/libwebp-dev@1.2.4-0.2, libwebp/libwebp7@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-dev@8:6.9.11.60+dfsg-1.6 > librsvg/librsvg2-dev@2.54.7+dfsg-1~deb12u1 > gdk-pixbuf/libgdk-pixbuf-2.0-dev@2.42.10+dfsg-1+b1 > tiff/libtiff-dev@4.5.0-6 > libwebp/libwebp-dev@1.2.4-0.2 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpmux3@1.2.4-0.2
  and 4 more...
  Fixed in: 1.2.4-0.2+deb12u1

Vous pouvez ajouter une commande de ce type pour mettre à niveau la bibliothèque manuellement :

…
RUN apt-get update && \
    apt-get install -y libwebp-dev=1.2.4-0.2+deb12u1 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*
…

3. Surveiller les projets à l’aide de la prise en charge des PR automatiques

Comme il s’agit d’une vulnérabilité zero-day, de nouveaux impacts sont découverts chaque jour. Il est donc important de surveiller régulièrement vos projets afin de prendre connaissance des nouvelles recommandations pour corriger le problème. Si vous utilisez Snyk, veillez à maintenir la surveillance de vos projets (activée par défaut lorsqu’un dépôt est importé dans l’application Snyk). Snyk testera ainsi automatiquement vos projets chaque jour, en plus des autres tests effectués lors de vos mises à jour.

Ces tests quotidiens détectent automatiquement les améliorations de sécurité possibles, notamment les nouveaux correctifs disponibles. Par exemple, si libwebp est une dépendance transitive de package A, vous devez attendre que package A publie une version utilisant libwebp en version 1.3.2 ou ultérieure. Cette version n’est peut-être pas encore disponible, mais elle pourrait l’être demain ou la semaine prochaine. Avec snyk monitor, Snyk effectuera des tests quotidiens et vous enverra une PR dès que la nouvelle mise à niveau sera disponible. Celle-ci mettra à niveau libwebp afin de corriger la vulnérabilité.

Notez également que Snyk vous avertira, par le biais de PR ou d’autres mécanismes, si d’autres correctifs sont apportés à cette vulnérabilité ou si de futurs vecteurs d’attaque révèlent de nouvelles vulnérabilités. Vous saurez ainsi rapidement quelles mesures prendre si d’autres problèmes surviennent.