Faille critique WebP : les dangers d'une mauvaise communication

Faille critique WebP : les dangers d’une mauvaise communication

C'est pas moi, c'est...

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

02/10/2023
27

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.

27

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Round 1 : une faille critique, mais pas trop

Round 2 : une faille bel et bien critique

Un sérieux problème de communication

Que s’est-il passé ?

Angle mort

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (27)


jotak Abonné
Le 02/10/2023 à 16h 52

Les ingénieurs de google qui publient les CVE devraient peut-être discuter avec les ingénieurs de google qui publient des white-papers sur les transparence en sécurité ? Genre comme ici: https://www.securityweek.com/google-proposes-more-transparent-vulnerability-management-practices/


Le 02/10/2023 à 19h 43

Pendant très, très longtemps, je me suis servi d’une vieille version de Firefox (54-dev edition) qui date d’avant le lâche abandon de XUL par Mozilla.



Tout simplement parce que je tiens à mes vieilles extensions XUL (speed Dial, DownThemAll, Grab and Drag….) comme à la prunelle de mes yeux !



Mais voilà : du jour au lendemain, un de mes sites préférés a commencé à afficher ses images au format Webp… Suivi par plein, plein d’autres… Images / illustrations / têtes d’articles que FF 54 ne peut tout simplement pas décoder, n’ayant pas le codec approprié…



Bref, c’était la fin de tout. :craint:



Et là est venu… l’espoir ! Un navigateur basé sur XUL qui fait le pont entre le passé et l’avenir, en prenant en charge les dernières technos (polyfills, web components…) et la plupart des derniers codecs…



…sauf ceux relatifs aux DRM, tels que Widevine par exemple, ce qui veux dire pas de Netflix ni de Prime, ce qui n’est pas un problème : pour ces utilisations, il y aura toujours la dernière version de FF…




Bref, je me régale, j’ai pu ré-installer la plupart de mes vieilleries (telles que FEBE, par exemple), et de son côté le site de Palemoon en propose un nombre certain, spécialement mises à jour (re-développées) pour ce navigateur.



:poke: N’oubliez pas : “There.is.only.XUL” !!! Rien - non, pas même ça - ne peut exister en dehors de XUL !!! :yoda: :arrow: :arrow: :arrow:


R4VEN Abonné
Le 02/10/2023 à 20h 37

(reply:2156370:DantonQ-Robespierre)




Haha je ne m’attendais tellement pas à lire un tel com’ sous cette news mais j’ai appris des trucs ! Merci Danton pour la rigolade et la découverte 😁😘


potn Abonné
Le 02/10/2023 à 20h 44

Est-ce qu’il existe un site/outil FIABLE permettant de déterminer si on est vulnérable ?


rm Abonné
Le 02/10/2023 à 21h 23

Merci pour cet article !


Uther Abonné
Le 02/10/2023 à 22h 02

(reply:2156370:DantonQ-Robespierre)




Pour le coup en effet cet article ne te concerne pas vu que ton navigateur doit déjà se trainer des dizaines de failles critiques qui bien heureusement pour toi n’intéressent personne au vu des parts de marché de Palemoon.
N’en fait pas trop la pub quand même, s’il devenait vraiment utilisé, ça serait la cata.


grsbdl Abonné
Le 02/10/2023 à 23h 10

pierreonthenet a dit:


Est-ce qu’il existe un site/outil FIABLE permettant de déterminer si on est vulnérable ?




Tu as une liste non-exhaustive de logiciels affectés : https://www.ninjaone.com/blog/webp-0-day-how-to-identify-vulnerable-apps-cve-2023-5129/ (dont des gestionnaires de mots de passe 😁)
Pour ton ou tes navigateurs web, il suffit de regarder sa version. Le même site énonce les versions contenant le correctif de sécurité. Sous windows/macos, grosso modo, il suffit d’être à jour. Sous distros linux et dérivés, ca va dépendre de la réactivité de celles-ci… mais ça ne devrait pas être bien long.


potn Abonné
Le 03/10/2023 à 06h 39

Merci, mais j’aimerais bien savoir si mon téléphone Android est touché, même avec Firefox. Et aussi pour tous les autres logiciels que j’utilise mais qui ne sont pas référencés.
Comme à priori la faille est relativement simple à exploiter, j’aurais aimé vérifier par moi-même quels logiciels sont vulnérables.


Nozalys Abonné
Le 03/10/2023 à 08h 06

potn

Merci, mais j’aimerais bien savoir si mon téléphone Android est touché, même avec Firefox. Et aussi pour tous les autres logiciels que j’utilise mais qui ne sont pas référencés.
Comme à priori la faille est relativement simple à exploiter, j’aurais aimé vérifier par moi-même quels logiciels sont vulnérables.

Il existe une autre liste plus exhaustive des applications basées sur Electron qui sont impactées :



https://gist.github.com/mttaggart/02ed50c03c8283f4c343c3032dd2e7ec


potn Abonné
Le 03/10/2023 à 20h 18

Nozalys

Il existe une autre liste plus exhaustive des applications basées sur Electron qui sont impactées :



https://gist.github.com/mttaggart/02ed50c03c8283f4c343c3032dd2e7ec


Merci, mais encore une fois ça ne va pas être exhaustif.
Un truc tout bête : est-ce que Signal sur Android est vulnérable ? Je n’ai pas trouvé trace du CVE sur leur Github, et pas de changelog qui en parlerai.
Avoir une image “test” qui affiche “vulnerable” lorsqu’on tente de l’afficher sur une appli serait très pratique.


Vekin Abonné
Le 04/10/2023 à 08h 37

potn

Merci, mais encore une fois ça ne va pas être exhaustif.
Un truc tout bête : est-ce que Signal sur Android est vulnérable ? Je n’ai pas trouvé trace du CVE sur leur Github, et pas de changelog qui en parlerai.
Avoir une image “test” qui affiche “vulnerable” lorsqu’on tente de l’afficher sur une appli serait très pratique.

Je me suis posé la question pour Paint.NET (il peut manipuler des images WebP), pas mis à jour récemment et sans aucune information au sujet de la faille.



En fait, en allant fouiller dans ses fichiers, je me suis rendu compte qu’il utilise déjà une version plus récente de la lib WebP, dans laquelle la faille n’existe plus.



Dans le cas de Signal, il est possible qu’ils utilisent déjà une version récente de la lib en interne.


potn Abonné
Le 04/10/2023 à 08h 49

Vekin

Je me suis posé la question pour Paint.NET (il peut manipuler des images WebP), pas mis à jour récemment et sans aucune information au sujet de la faille.



En fait, en allant fouiller dans ses fichiers, je me suis rendu compte qu’il utilise déjà une version plus récente de la lib WebP, dans laquelle la faille n’existe plus.



Dans le cas de Signal, il est possible qu’ils utilisent déjà une version récente de la lib en interne.


C’est dommage le manque de communication à ce propos tout de même…


serpolet Abonné
Le 03/10/2023 à 05h 23

grsbdl a dit:


Sous distros linux et dérivés, ca va dépendre de la réactivité de celles-ci… mais ça ne devrait pas être bien long.




Effectivement, reçu ça hier :




Paquet : libvpx7 (1.11.0-2ubuntu2.2 et autres) [security] VP8 and VP9 video codec (shared library)




(sur Mint 21.2)


vivienfr Abonné
Le 03/10/2023 à 07h 03

Un point important concerne Android : la faille n’est pas encore corrigée.



Cela devrait arriver avec le patch d’octobre, mais le fait de ne pas faire une mise à jour en urgence pourait être reproché.


Arona Abonné
Le 03/10/2023 à 07h 21

Et donc tous les téléphones android ne recevant quasiment jamais de MAJ de sécurité sont comme d’habitude des passoires.


Nozalys Abonné
Le 03/10/2023 à 08h 08

Oui, et non : oui si la librairie existe nativement dans Android, non car les applications que tu utilises sont en grande majorité des applications tierces que tu mets à jour via le PlayStore. Et ce sont ces applications qui embarquent leurs propres librairies et qui lisent le contenu téléchargé.



Mais dans les faits, oui, la politique de support logiciel bas de gamme d’Android est par nature une passoire. Et rien ne semble changer pour le moment.


Vekin Abonné
Le 03/10/2023 à 12h 49

Nozalys

Oui, et non : oui si la librairie existe nativement dans Android, non car les applications que tu utilises sont en grande majorité des applications tierces que tu mets à jour via le PlayStore. Et ce sont ces applications qui embarquent leurs propres librairies et qui lisent le contenu téléchargé.



Mais dans les faits, oui, la politique de support logiciel bas de gamme d’Android est par nature une passoire. Et rien ne semble changer pour le moment.


Exact, je vois peu d’endroits ou d’actions dans mon téléphone Android où c’est l’OS lui-même qui affiche une image (externe). Même la galerie est une application tierce (développée par Huawei).



Maintenant, et c’est là où le bât blesse : Huawei ne diffuse plus de mises à jour pour mon téléphone, donc la faille risque d’être belle et bien problématique… :craint:


hurd Abonné
Le 03/10/2023 à 09h 10
millman42 Abonné
Le 03/10/2023 à 08h 22

Finalement vu qu’ils ont gardé le CVE-2023-4863 le score CVSS reste de 8.8.


cacadenez Abonné
Le 03/10/2023 à 08h 34

(reply:2156370:DantonQ-Robespierre)




ça ressemble dangereusement aux experts en informatique (j’entends : tous les hommes ayant un ordi) qui préconisaient de rester sur Windows XP (maintenant, parait-il, c’est W11 qu’il faut éviter).



C’est vrai que Mozilla a tellement peu œuvrer pour la sécu de son navigateur qu’il vaut mieux rester à des versions antédiluviennes et se blinder d’extensions poussiéreuses. Perso, je garde Netscape.


Le 04/10/2023 à 05h 45

pierreonthenet a dit:


Avoir une image “test” qui affiche “vulnerable” lorsqu’on tente de l’afficher sur une appli serait très pratique.




C’est plus compliqué que cela. Sur ce genre de faille avec exécution de code arbitraire, le code “malicieux” à exécuter doit être adapté à l’environnement sur lequel il s’exécute, parfois même en fonction de la version du système d’exploitation, voir même du logiciel avec lequel tu ouvriras l’image. Ils doit aussi passer les autre gardes fou spécifiques à chaque système d’exploitation (antivirus, intégrité mémoire…) sans être détecté. Autrement dit, l’image capable de compromettre ton système en étant ouverte sur la messagerie de IOS ne fonctionnera sûrement pas sur android ou windows ou même peut-être sur une autre appli de messagerie d’IOS.


potn Abonné
Le 04/10/2023 à 07h 32

Merci pour la précision. J’aurais pensé qu’il serait possible de faire un code générique, même si très lourd, pour chaque OS. Mais si ça dépend de l’application, c’est pas la même tambouille…


Le 04/10/2023 à 09h 41

R4VEN a dit:


Haha je ne m’attendais tellement pas à lire un tel com’ sous cette news mais j’ai appris des trucs ! Merci Danton pour la rigolade et la découverte 😁😘




+1 :-) :-)


vivienfr Abonné
Le 05/10/2023 à 07h 03

Il y a qq chose de très étrange avec la faille WebP CVE-2023-4863, Google semble faire exprès de retarder le correctif pour Android alors que la faille, activement exploitée, est corrigée partout ailleurs.



Le correctif n’était pas dans le patch sécurité de septembre, pourquoi pas, mais pas dans celui diffusé en octobre. Le correctif a été inséré dans le code Android à la date du 6 octobre, or le patch intègre le correctif à la date du 5 octobre (pour les tel pixel).



C’est clairement volontaire => https://lafibre.info/attaques/webp-cve-2023-4863/msg1036720/#msg1036720


Soriatane Abonné
Le 08/10/2023 à 20h 11

Merci pour le fil


Le 06/10/2023 à 22h 50

(reply:2156379:Uther) C’est justement pour ça que j’ai choisi ce navigo : les failles critiques sont toujours adressées (notamment l’infâme, la diabolique CVE 2023-4863 décrite dans l’article), la plateforme XUL n’est plus figée dans le temps depuis un bail, de nouveaux devs travaillent dessus en permanence.




Bref, ça ne plaisante pas avec la sécurité, la dernière version 32.4.1 résout même une nouvelle faille : la CVE-2023-5217, qui affecte libvpx.


Le 07/10/2023 à 00h 18

(reply:2156443:cacadenez) Voir ma réponse juste au dessus, les choses ne sont pas toujours comme l’on est persuadé qu’elles sont, je sais que c’est difficile de dépasser certains a-priori, mais Palemoon est un navigateur moderne, et le moteur est tout à fait actuel, avec des patchs de sécurité réguliers.