Faille critique WebP : les dangers d’une mauvaise communication

Il y a deux semaines, Google avait publié un bulletin de sécurité concernant une faille dans la bibliothèque libwebp. Il y a quelques jours, la société a révisé la dangerosité de la note, lui attribuant un 10, soit le maximum. Que s’est-il passé ?

WebP est un format d’image révélé par Google en 2010. Les avantages posés sur la table étaient simples : proposer une qualité équivalente au PNG, mais avec un poids plus faible, des gains pouvant aller de 30 à 80 % selon Google, grâce à la compression octroyée par le codec VP8 (le même que pour la vidéo). Le format était également présenté comme une alternative au JPG. Dans les années qui ont suivi, Google s’en est largement servi sur l’ensemble de ses sites.

Il a fallu cependant du temps pour qu’il soit pris en charge dans un nombre suffisant d’autres produits. Chrome a été servi le premier bien sûr, et avec lui tous les navigateurs Chromium. Mais il a fallu par exemple attendre 2018 pour que WebP soit supporté dans Windows 10, 2019 pour Firefox et même 2020 par Apple (iOS 14 et macOS Big Sur). Aujourd’hui, l’immense majorité des applications en lien avec les images (visionneuses, retouche…) prennent en charge WebP.

Les capacités liées à ce format sont gérées par une bibliothèque nommée libwebp. Elle est incluse dans la quasi-totalité des systèmes et applications proposant le support de WebP. C’est dans cette bibliothèque que se trouvait une faille, dont Google a averti de l’existence il y a quelques semaines.

Round 1 : une faille critique, mais pas trop

Le bulletin initial date du 11 septembre. Google communique alors sur une faille affectant toutes les versions de Chrome.

La firme indique que WebP est affecté par une brèche résultant d’un dépassement de mémoire tampon. La faille porte la référence CVE-2023-4863 et est affublée d’une note de sévérité de 8,8. Google recommande bien sûr de mettre à jour Chrome aussi rapidement que possible, les nouvelles moutures pour l’ensemble des plateformes étant disponibles en même temps que le bulletin.

Et pour cause : Google avertissait déjà que la faille était exploitée dans la nature.

On apprenait également que la faille avait été trouvée par le Citizen Lab de l’université de Toronto et par l’équipe SEAR (Security Engineering and Architecture) d’Apple.

Round 2 : une faille bel et bien critique

Environ deux semaines plus tard, Google révèle de nouveaux détails, sous une autre référence : CVE-2023-5129. Il y est à nouveau question de WebP, mais le descriptif est cette fois beaucoup plus consistant :

« Avec un fichier WebP lossless spécialement conçu, libwebp peut écrire des données hors limites dans le tas. La fonction ReadHuffmanCodes() alloue le tampon HuffmanCode avec une taille qui provient d'un tableau de tailles précalculées : kTableSize. La valeur color_cache_bits définit la taille à utiliser. Le tableau kTableSize ne prend en compte que les tailles pour les tables de recherche de premier niveau de 8 bits, mais pas les tables de recherche de second niveau. libwebp autorise des codes allant jusqu'à 15 bits (MAX_ALLOWED_CODE_LENGTH). Lorsque BuildHuffmanTable() tente de remplir les tables de second niveau, il peut écrire des données hors limites. L'écriture OOB dans le tableau sous-dimensionné se produit dans ReplicateValue. »

En clair, c’est le pire des scénarios pour une faille. Dans le cas présent, une image spécialement conçue peut permettre de déclencher une exécution arbitraire de code à distance, de manière automatique et sans intervention de l’utilisateur. La note de sévérité est révisée et devient maximale : 10

Un sérieux problème de communication

Dans l’intervalle de deux semaines, de nombreux systèmes et applications ont été mis à jour. Cependant, des chercheurs en sécurité ont rapidement pointé du doigt un défaut de communication, car le premier bulletin de sécurité ne mentionnait même pas la bibliothèque libwebp. Selon le descriptif de Google, le problème résidait dans Chrome.

Ce qui n’a pas empêché certains de réagir rapidement, notamment Mozilla, qui publiait une mise à jour pour toutes les versions de Firefox et Thunderbird dès le 12 septembre. Cependant, Google et Apple avaient entre les mains des informations précises qu’aucune des deux entreprises n’a donné sur l’instant.

Dans le cas d’Apple, c’est d’ailleurs flagrant. Le 8 septembre, nous indiquions ainsi que la société de Cupertino diffusait d’importantes mises à jour de sécurité. On y trouvait des correctifs pour deux failles critiques, dont l’une résidait dans ImageIO. S'agissait-il de la vulnérabilité découverte dans WebP ? C'est justement toute la question, et les interrogations ont entrainé du retard dans le traitement du problème.

Que s’est-il passé ?

Pour mieux comprendre l’imbroglio, il faut remonter au 7 septembre. À cette date, le Citizen Lab publie un billet relatant (avec peu de détails) leur découverte d’une faille 0-day et zero-click dans iOS. Pire, cette faille fait partie d’une exploitation en chaine utilisée par le fameux logiciel espion Pegasus de NSO Group. Au Citizen Lab, la faille est alors nommée BLASTPASS.

Apple a corrigé très rapidement les failles, puisqu’elles pouvaient être exploitées par une simple image envoyée par iMessage. La brèche dans ImageIO est alors estampillée CVE-2023-41064.

Le 6 septembre, à la veille du billet, le Citizen Lab et l’équipe SEAR d’Apple avaient prévenu Google, car l’exploitation était jugée possible en dehors de l’écosystème d’Apple. Ce qui était effectivement le cas. Cinq jours plus tard, Google publie son propre bulletin et décrit sa faille nommée CVE-2023-4863.

Bien que l’entreprise ait publié un autre bulletin deux semaines plus tard, CVE-2023-5129, il s’agit de la même faille, le second n’ayant initialement publié que pour réviser la portée du problème. Il a depuis été désactivé et le premier a été mis à jour.

Angle mort

Les choix du Citizen Lab, d’Apple et Google ont été copieusement critiqués. En publiant des bulletins CVE distincts, du temps précieux a été perdu dans la correction de la faille. Google, notamment, savait que le correctif visait la bibliothèque libwebp, mais cette dernière n’était pas mentionnée dans le billet du 11 septembre. Aujourd’hui, on sait que toute version de libwebp antérieure à la 1.3.2 est vulnérable.

Même le lien entre les bulletins CVE-2023-41064 d’Apple et CVE-2023-4863 de Google n’était pas explicite. Le 21 septembre, les chercheurs Ofri Ouzan et Yotam Perkal, de Rezillion, ont ainsi publié une analyse dans laquelle on découvre le puissant faisceau d’indices montrant que les deux failles n’en sont qu’une. La question avait d’ailleurs été posée à Apple et Google, qui n’y ont pas répondu. Rebelote le lendemain chez Ars Technica, sans succès.

Tout ce que l'on savait à ce moment-là était qu'Apple avait publié un bulletin CVE pour une faille dans l'un de ses composants, puis que Google en avait fait de même pour Chrome quelques jours plus tard.

Si les chercheurs se montrent si critiques, c’est qu’en ne nommant pas directement libwebp, de nombreux éditeurs n’ont pas réagi immédiatement. En outre, cette bibliothèque est présente dans un très grand nombre d’autres projets (Gimp, Libreoffice, Telegram, 1Password...), y compris des frameworks.

La faille a par exemple été corrigée dans la version 25.8.1 d’Electron, signifiant que tous les projets l’utilisant devaient être mis à jour pour être à l'abri. Il a ainsi fallu plusieurs jours pour que Microsoft propose une version corrigée de Visual Studio Code, mais Teams n’y a pas encore eu droit. On peut se rendre compte de l’étendu des dégâts en regardant la liste des « rappels » du CERT-FR.

Le danger a d’ailleurs été illustré par les chercheurs de Rezilion. De nombreux développeurs se servent en effet de scanners automatisés (SBOM, Software Bill of Materials, ou inventaire logiciel) pour repérer les composants vulnérables dans les applications qu’ils maintiennent. Le Citizen Lab, Apple et Google, en ne mentionnant pas clairement la bibliothèque libwebp dès le départ, n’ont pas donné les éléments nécessaires à une détection fructueuse du problème dans les projets utilisant libwebp.

Ils recommandaient donc aux utilisateurs de telles solutions d’y chercher directement des mentions des versions vulnérables de libwebp, c’est-à-dire toutes celles antérieures à la 1.3.2. C’est particulièrement vrai pour les systèmes d’exploitation, les navigateurs Chromium se servant de l’implémentation existante dans certains cas, notamment sur Android.