Recommandations concernant les récentes vulnérabilités critiques de libwebp et libvpx
Contexte
Au cours des dernières semaines, Google a publié des mises à jour pour Google Chrome comprenant des correctifs pour les menaces CVE-2023-4863 et CVE-2023-5217. Ces deux failles se sont révélées être des vulnérabilités Zero Day exploitées « in the wild », et les entrées CVE ont été mises à jour pour ne plus se limiter à Google Chrome et s'étendre aux bibliothèques sous-jacentes : libwebp et libvpx. Les deux CVE apparaissent dans le catalogue des vulnérabilités connues et exploitées de la CISA.
Dans cet article de blog, nous présentons les deux vulnérabilités en détail et fournissons des recommandations sur la manière de détecter les applications vulnérables dans votre réseau. Comme ces vulnérabilités font toujours l'objet de recherches, il se peut que cet article soit mis à jour prochainement avec des informations et des conseils supplémentaires.
CVE-2023-4863 — libwebp
Cette vulnérabilité a été signalée par l'équipe SEAR (Security Engineering and Architecture) d'Apple et Citizen Lab. Suite à ce rapport, les chercheurs ont établi une corrélation entre cette vulnérabilité et l'attaque BLASTPASS, une exploitation Zero Day de type Zero Click de NSO Group pour les iPhone.
La vulnérabilité en elle-même est un dépassement de pile dans libwebp, qui se produit lors du décodage des images webp dans le format sans perte. Ben Hawkes a rédigé une analyse technique très détaillée de la vulnérabilité.
Libwebp est une bibliothèque développée par Google pour encoder et décoder des images au format WebP (également développé par Google). La vulnérabilité réside dans l'analyse des images par la bibliothèque avec une compression sans perte, qui utilise des tables de Huffman. Fondamentalement, un cybercriminel peut manipuler les tables pour amener la bibliothèque à allouer moins de mémoire aux tables que leur taille réelle, ce qui entraîne un dépassement de pile et une écriture hors limites.
Il existe de nombreux moyens et configurations pour obtenir ce résultat, il n'y a donc pas de démonstration unique pour le reproduire, mais vous pouvez consulter la démonstration de @mistymntncoppour découvrir un exemple de mise en œuvre de l'exploitation.
CVE-2023-5217 — libvpx
Cette vulnérabilité a été découverte par Clément Lecigne du Threat Analysis Group de Google. Cette faille a également été utilisée par un fournisseur commercial de système de surveillance.
Libvpx fait également partie du projet WebP. Plus précisément, cette bibliothèque traite les formats VP8 et VP9 pour l'encodage et le décodage vidéo. Il y a moins de détails concernant cette vulnérabilité, mais on sait qu'il s'agit également d'une vulnérabilité de corruption de pile.
Qu'est-ce qui est vulnérable ?
Dans un premier temps, seuls les navigateurs ont été signalés comme vulnérables, car les failles se trouvaient dans Chromium. Cependant, comme la vulnérabilité réside dans les bibliothèques sous-jacentes libwebp et libvpx, l'ampleur de l'impact est bien plus large : les applications utilisant les versions 0.5.0. à 1.3.1 de libwebp et les applications utilisant des versions de libvpx antérieures à la version 1.13.1 sont affectées.
Nous avons dressé une liste des applications qui utilisent l'une ou l'autre de ces bibliothèques, d'après les informations accessibles au public. Nous avons également inclus des programmes utilisant la bibliothèque que nous avons détectés à l'aide de nos requêtes Insight. Cela ne signifie pas nécessairement qu'ils sont vulnérables.
Pour qu'un programme soit vulnérable, il doit utiliser la fonction WebP sans perte de la bibliothèque libwebp ou les codecs V8 ou V9 de la bibliothèque libvpx. Comme ces bibliothèques peuvent être utilisées pour des fonctions et des capacités complètement différentes, leur utilisation n'est pas toujours synonyme de vulnérabilité.
Nous savons que les navigateurs Web utilisent ces capacités, mais c'est aux fournisseurs d'indiquer si d'autres programmes les utilisent. Nous avons constaté que les navigateurs et applications suivants utilisent les bibliothèques concernées :
- Fedora (37 à 39)
- Debian (10 à 12)
- Google Chrome
- Firefox
- Microsoft Edge
- Opera
- Tor
- Brave
- Vivaldi
- Telegram
- Discord
- 1Password
- Electron
- GIMP
- Slack
- LibreOffice
- Skype
- Grafana
- KeePassXC
- VLC
De plus, un anonyme a analysé les référentiels de paquets d'Ubuntu et mis en ligne une liste de tous les paquets utilisant libvpx7.
Exposition aux vulnérabilités — OSquery
Puisque la bibliothèque se trouve à de nombreux endroits différents, et qu'il appartient aux éditeurs de logiciels de mettre à jour leurs produits, il est crucial de détecter l'étendue des vulnérabilités et le taux d'exposition des machines de votre réseau. Nous avons développé plusieurs requêtes Osquery à cet effet. Les clients d'Akamai Guardicore Segmentation peuvent utiliser la fonction d'informations pour exécuter ces requêtes sur leurs réseaux.
libweb et libvpx chargés en mémoire
Comme n'importe quelle application peut interagir avec ces bibliothèques, il n'est pas envisageable de les localiser sur le disque dur. À la place, nous pouvons vérifier les modules chargés (fichiers DLL ou SO) dans chaque processus en cours d'exécution en utilisant la table OSquery process_memory_map et essayer d'obtenir la version à l'aide de la table des fichiers.
Les métadonnées de version étant ajoutées pendant le processus de compilation, elles ne seront pas nécessairement disponibles, car la bibliothèque peut être compilée sans elles. Même lorsque les métadonnées de version sont disponibles, elles ne sont pas toujours exactes, car les fournisseurs peuvent ajouter leur propre version de logiciel à la place. Nous conseillons aux utilisateurs de faire preuve de discernement pour éviter les faux positifs ou les vrais négatifs.
SELECT DISTINCT
procs.name AS process_name,
pmm.path AS lib_path,
file.file_version,
CASE
WHEN file_version = '' THEN 'unknown version, potentially vulnerable'
WHEN pmm.path LIKE '%libwebp%' AND file_version < '1.3.2' THEN 'vulnerable version'
WHEN pmm.path LIKE '%libwebp%' AND file_version >= '1.3.2' THEN 'not vulnerable version'
WHEN pmm.path LIKE '%libvpx%' AND file_version <= '1.13.1' THEN 'vulnerable version'
WHEN pmm.path LIKE '%libvpx%' AND file_version > '1.13.1' THEN 'not vulnerable version'
ELSE 'unknown version, potentially vulnerable'
END is_vulnerable
FROM process_memory_map AS pmm
JOIN processes AS procs USING(pid)
JOIN FILE ON file.path = pmm.path
WHERE pmm.path LIKE '%libwebp%' OR pmm.path LIKE '%libvpx%'
Localisation des navigateurs Web
Le rapport initial pour les CVE et le cas d'utilisation provenant de Chromium, nous avons inclus une requête pour détecter les navigateurs installés. Cette requête peut vous aider à localiser les ressources sur le réseau qui exécutent des navigateurs et peuvent nécessiter une enquête plus approfondie. Vous pouvez ensuite comparer la version installée avec la liste des versions de navigateurs vulnérables figurant dans la base de données nationale sur les vulnérabilités (National Vulnerability Database ou NVD).
SELECT name, version FROM programs
WHERE LOWER(name) LIKE "%chrome%"
OR LOWER(name) LIKE "%firefox%"
OR LOWER(name) LIKE "%microsoft edge%"
OR LOWER(name) LIKE "%thunderbird%"
OR LOWER(name) LIKE "%brave%"
OR LOWER(name) LIKE "%opera%"
Localisation des programmes installés
Pour vérifier si l'un des programmes de la liste ci-dessus est installé, utilisez la requête suivante : remplacez simplement <program_name> par le nom réel du programme.
SELECT name, version FROM programs
WHERE name LIKE "%<program_name>%"
Atténuation
Visualisation des applications et des ressources vulnérables
En utilisant la liste compilée des applications et les requêtes OSquery fournies dans cet article de blog, vous pourrez repérer les applications potentiellement vulnérables de votre réseau et en déduire une liste des ressources potentiellement vulnérables.
Les clients d'Akamai Hunt ont reçu un rapport détaillant l'exposition de leurs environnements à la vulnérabilité. Les rapports Hunt s'appuyaient sur des requêtes similaires à celles de cet article de blog, et ont été envoyés quelques heures après le début de l'incident. Les requêtes ont détecté des milliers de ressources vulnérables à travers le monde.
Application de correctifs
De nombreux paramètres sont pris en compte lorsqu'il s'agit de déterminer si une application est vulnérable : quelle version de libwebp ou libvpx charge-t-elle ? L'application utilise-t-elle la compression sans perte WebP ou les codecs VP8/VP9 ? En raison des diverses combinaisons possibles, de nombreuses applications sont susceptibles d'être exploitées, et l'impact peut être considérable.
Malheureusement, il n'existe pas de correctif unique permettant d'atténuer cette vulnérabilité. L'application de correctifs dépend également des éditeurs de logiciels qui publient les correctifs appropriés pour leurs programmes, et cela peut prendre un certain temps. Les entreprises doivent évaluer au fil du temps les charges de travail qui sont vulnérables et qui ne sont pas corrigées.
Seuil d'alerte en cas de menace
Étant donné que les correctifs pour tous les programmes concernés ne sont pas nécessairement disponibles, il peut être prudent d'augmenter votre seuil d'alerte sur les charges de travail potentiellement vulnérables et non corrigées. De cette façon, même si la vulnérabilité est exploitée sans être détectée, vous pourrez toujours garder un œil sur ses conséquences.
Cependant, cela peut accroître le nombre d'alertes inutiles. Par conséquent, nous recommandons d'ajuster votre seuil d'alerte en fonction de l'importance de la charge de travail affectée pour le réseau ou de son impact.
Résumé
Dans cet article de blog, nous avons passé en revue les informations disponibles sur les vulnérabilités critiques de libwebp et libvpx, qui ont été exploitées « in the wild ».
Pour les personnes responsables des systèmes de défense, l'étape critique consiste à déterminer la vulnérabilité des charges de travail dans leur réseau. Nous avons essayé d'apporter notre aide en fournissant des requêtes OSquery afin de détecter les programmes qui utilisent ces bibliothèques. Nous avons également évoqué les mesures à prendre pour atténuer certains risques (c'est-à-dire ajuster le seuil d'alerte en cas de menace) en l'absence de correctifs.
Cet article de blog donne un aperçu de notre compréhension actuelle et de nos recommandations, compte tenu des informations disponibles. Notre analyse est en cours et toutes les informations contenues dans ce document sont susceptibles d'être modifiées. Suivez également notre compte Twitter pour connaître les dernières informations en temps réel.
