Comment trouver et corriger la vulnérabilité zero-day critique de WebP (CVE-2023-4863)

Le mois dernier, l’équipe Security Engineering and Architecture (SEA) d’Apple et le Citizen Lab de la Munk School de l’université de Toronto ont découvert deux vulnérabilités critiques (CVE-2023-4863 et CVE-2023-5129). Ces vulnérabilités concernant des images WebP malveillantes, conçues pour exploiter les navigateurs basés sur Chromium et la bibliothèque webmproject/libwebp fournie par Google. Pour en savoir plus sur cette vulnérabilité et ses derniers développements, n’hésitez pas à vous plonger dans notre article.

Fait notable, la vulnérabilité de libwebp ne se limite pas aux navigateurs. Elle touche également les écosystèmes de développement, les systèmes d’exploitation et les conteneurs. Voici la liste des écosystèmes et conteneurs qui sont, d’après notre enquête, concernés par cette faille :

Comme vous le constatez, elle touche divers écosystèmes de développement, directement ou indirectement, ce qui témoigne de l’étendue de son impact. Elle est principalement présente sous forme de dépendance transitive dans des projets Cocoapods, Swift et Python, ce qui peut rendre l’analyse de son impact plus complexe pour les développeurs. Pas de panique, Snyk Container et Snyk Open Source sont capables de détecter les paquets concernés. Vous pouvez dès maintenant utiliser Snyk gratuitement pour identifier les projets qui les intègrent.

Nous avons analysé en profondeur l’impact de libwebp, mais les experts en sécurité se penchent toujours sur les différentes utilisations de libwebp dans les applications, écosystèmes et systèmes d’exploitation. La vulnérabilité concerne les composants logiciels qui utilisent les codecs d’image .webdp et rendent leur contenu (navigateurs, outils de conception, etc.). Par conséquent, l’étendue de son impact devrait encore augmenter. Vous devez donc absolument vous tenir informé des dernières évolutions concernant cette faille.

L’objectif de cet article est de vous aider à comprendre l’impact de cette vulnérabilité sur les écosystèmes logiciels et à la corriger rapidement.

Au 3 octobre 2023, 2 CVE sont associées à cette vulnérabilité de libwebp :

• CVE-2023-4863 : ouverte le 11 septembre 2023 avec un score CVSS de 9.6 et un score EPSS de 31,86 % (97e percentile). Remarque : dans un premier temps, le score de 8,8 (« Elevée ») lui avait été attribué, mais il a été revu après la publication d’informations supplémentaires. 

• CVE-2023-5129 : ouverte le 25 septembre 2023 avec un score CVSS de 10 (le maximum possible), puis rejetée le 27 septembre 2023 par Google, l’autorité de numérotation CVE attribuée, car il s’agissait d’un doublon.

Pour en savoir plus sur cette vulnérabilité et ses derniers développements, n’hésitez pas à vous plonger dans notre article. Dans cet article, nous allons nous pencher sur les recommandations de correction suivantes :

1. Déterminez où vous utilisez libwebp.

2. Mettezlibwebp à jour vers la version 1.3.2 ou une version ultérieure.

3. Suivez les projets à l’aide des PR automatiques.

1\. Déterminez où vous utilisez libwebp

La grande difficulté de la résolution d’une vulnérabilité zero-day consiste à déterminer si elle vous concerne et où. Celle de libwebp ne fait pas exception à la règle. Cette bibliothèque peut être une dépendance directe ou indirecte (transitive) de votre projet. Par conséquent, détecter son utilisation est essentiel, car il est très probable que vous soyez concerné d’une manière ou d’une autre sans le savoir. Éléments pouvant être concernés : 

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

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

• Tout système d’exploitation et toute image de conteneur intégrant des outils de gestion des images .webp est concerné par la vulnérabilité.

Si cette vulnérabilité touche de nombreux écosystèmes de développement, c’est notamment parce que de nombreux langages de programmation de haut niveau utilisent la bibliothèque libwebp. Par exemple, le moteur GoDot, qui permet de créer des jeux 2D et 3D, dépend de la bibliothèque libwebp, tout comme le très populaire utilitaire FFmpeg.

Détection de la vulnérabilité de libwebp avec Snyk

Snyk vous propose divers moyens gratuits pour détecter la vulnérabilité de libwebp. Vous pouvez tester vos projets en local avec Snyk CLI :

• Pour les applications, exécutez snyk test --unmanaged depuis Snyk CLI pour analyser les dépendances non gérées de votre référentiel et répertorier chaque paquet et ses vulnérabilités.

• Pour les conteneurs, exécutez snyk container test pour détecter les paquets de systèmes d’exploitation qui dépendent de versions vulnérables de libwebp.

Vous pouvez aussi analyser tous les projets de vos dépôts Git pour obtenir un rapport sur l’ensemble des dépendances directes et transitives que vous utilisez. Ce rapport vous montrera si vous utilisez libwebp et dans combien de chemins de votre graphe des dépendances elle est utilisée. Vous pouvez aussi faire une simple recherche de « CVE-2023-4863 » sur l’ensemble des projets. 

2a. Mettez libwebp à jour vers la version 1.3.2 ou une version ultérieure (open source)

• Correction automatique : connectez Snyk à vos dépôts Git pour obtenir des PR permettant de mettre à jour votre graphe de dépendances lorsque cela est possible. Ensuite, régénérez votre application.

• Correction manuelle : si vous utilisez libwebp sous forme de dépendance directe dans votre application, vous pouvez directement mettre à jour le fichier de la dépendance vers la version 1.3.2 ou une version supérieure. Ensuite, régénérez votre application.

• Correction manuelle : si vous utilisez libwebp sous forme de dépendance transitive dans votre application, trouvez une version de votre dépendance directe qui importe la dépendance transitive libwebp dans sa version 1.3.2 ou une version ultérieure. Ensuite, régénérez votre application.

2b. Mettez libwebp à jour vers la version 1.3.2 ou une version ultérieure (conteneur)

• Correction automatique : connectez Snyk à vos dépôts Git pour obtenir des requêtes d’extraction qui mettront à jour votre image de base Dockerfile lorsque cela est possible. Vérifiez si l’image de base suggérée intègre toujours la vulnérabilité avec https://snyk.io/test/docker/<image_name>, puis régénérez le conteneur une fois que vous avez trouvé un chemin de mise à niveau acceptable.

• Correction manuelle : si votre image inclut une version vulnérable de libwebp et qu’aucune mise à jour de l’image de base n’est possible ou souhaitable, vous pouvez faire la mise à jour vous-même en vous appuyant sur les conseils de correction de Snyk Container.  Exemple : pour une image Debian, la CLI de Snyk Container fournit les informations suivantes :

✗ 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 pourriez ajouter la commande suivante pour mettre à jour 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\. Suivez les projets à l’aide des PR automatiques

S’agissant d’une vulnérabilité zero-day, de nouvelles conséquences de cette faille apparaissent jour après jour. Il est donc important de vérifier vos projets régulièrement pour obtenir de nouvelles recommandations de corrections. Si vous utilisez Snyk, veillez à maintenir vos projets sous surveillance (option par défaut lors de l’importation d’un dépôt dans l’application Snyk). Vos projets seront ainsi testés chaque jour automatiquement, en plus des autres tests réalisés lorsque vous procédez à des modifications.

Ces tests quotidiens détectent les améliorations possibles de la sécurité, y compris la disponibilité de nouveaux correctifs. Par exemple, si vous utilisez libwebp sous forme de dépendance transitive dans le paquet A, ce paquet doit proposer une nouvelle version qui utilise libwebp dans sa version 1.3.2 ou une version ultérieure. Cette version n’est pas nécessairement disponible à l’instant T, mais elle le sera peut-être le lendemain ou la semaine suivante. La commande snyk monitor effectuera ce test chaque jour et vous enverra une requête d’extraction une fois la nouvelle version disponible afin que vous puissiez mettre à jour la version delibwebp et corriger la vulnérabilité.

Il est également important de noter que Snyk vous alertera, par le biais de requêtes d’extraction ou d’autres mécanismes, si d’autres correctifs sont proposés en lien avec cette vulnérabilité ou si de futurs vecteurs d’attaques ouvrant de nouvelles vulnérabilités sont identifiés. Ainsi, vous avez la certitude d’être le premier à savoir comment réagir si de nouveaux problèmes surviennent.