Auteur Sujet: Faille WebP CVE-2023-4863 exploitée par le logiciel espion Pegasus via iMessage (Lu 7167 fois)

vivien · « **le:** 16 septembre 2023 à 11:55:05 »

Faille WebP CVE-2023-4863 exploitée par le logiciel espion Pegasus via iMessage (attaque zéro clic)
Une faille activement exploitée, avec des dizaines de milliers de logiciels vulnérables

La vulnérabilité WebP CVE-2023-4863 affecte la bibliothèque d'images libwebp utilisée pour rendre des images au format WebP. La vulnérabilité réside dans l'algorithme de codage de Huffman utilisé par libwebp pour la compression sans perte et permet aux attaquants d'exécuter des écritures de mémoire hors limites à l'aide de pages HTML conçues de manière malveillante. Ce type d'exploit peut avoir de graves conséquences, allant des plantages à l'exécution de code arbitraire et à l'accès non autorisé à des informations sensibles, quand il est utilisé avec d'autres failles. La bibliothèque d'images libwebp est intégrée dans presque tous les systèmes d'exploitation et applications. Le bug affecte tout logiciel utilisant la bibliothèque libwebp.

La faille a été découverte par Citizen Lab en relation avec un exploit iMessage zéro clic, qui a été utilisé pour diffuser le logiciel espion Pegasus du groupe NSO. Concrètement, la personne attaquée se fait prendre le contrôle de son iPhone sans aucune action de sa part. L'attaquant doit simplement envoyer le fichier dangereux et laisser l’exploit fonctionner sans aucune action de la part de l’utilisateur (il n'est même pas nécessaire que l'utilisateur consulte iMessage). Ce type d'attaque se réalise en utilisant la faille WebP avec une autre afin de faire une attaque zéro clic. Ce type d'attaques zéro clic est le summum des attaques, ce type de faille peut se vendre plusieurs millions d'euros quand elles ne sont pas corrigées. Pour en savoir plus sur les personnes attaquées, vous pouvez lire Le projet Pegasus, une enquête journalistique internationale qui révèle en juillet 2021 que onze États ont espionné des journalistes, opposants politiques, militants des droits de l'homme, chefs d'État… au moyen du logiciel espion Pegasus. Emmanuel Macron et Édouard Philippe ont été ciblés par ce logiciel. La vulnérabilité peut être exploitée à l'aide d'un fichier webp sans perte conçu de manière malveillante, ce qui provoque un débordement de la bibliothèque libwebp.

Apple a corrigé le problème en déclaré la failla à Google en précisant activement exploité. Les versions de libwebp0.5.0 à 1.3.1 incluses sont concernées.

3 CVE ont été déclarés pour la même faille WebP :

CVE-2023-41064 (déclaration par Apple le 7 septembre 2023, serait bien le même bug que CVE-2023-4863) :
- https://www.cve.org/CVERecord?id=CVE-2023-41064
- https://nvd.nist.gov/vuln/detail/CVE-2023-41064

CVE-2023-4863 (déclare par Google le 12 septembre 2023, concernant Chrome)
- https://www.cve.org/CVERecord?id=CVE-2023-4863
- https://nvd.nist.gov/vuln/detail/CVE-2023-4863

CVE-2023-5129 (déclare par Google le 25 septembre 2023, concernant libwebp, mais rejeté, car duplicata de CVE-2023-4863)
- https://www.cve.org/CVERecord?id=CVE-2023-5129
- https://nvd.nist.gov/vuln/detail/CVE-2023-5129

Pourquoi 2 CVE déclarées par Google ? Google avait initialement émis un avis de sécurité pour CVE-2023-4863, qu'il a décrit comme un débordement de buffer dans Chrome, malgré le fait que la vulnérabilité avait un impact plus large et a affecté tout code utilisant libwebp. Dans CVE-2023-5129, la vulnérabilité est identifiée concernant libwebp et non chrome, mais finalement CVE-2023-5129 a été rejeté et CVE-2023-4863 a été mis à jour.

Voici pourquoi une correction rapide est essentielle :

vivien · « **Réponse #1 le:** 20 septembre 2023 à 21:46:27 »

Des mises à jour ont été proposées sur de nombreux logiciels, souvent avec des versions spécifiquement mises à dispositions pour corriger la faille :

- iOS 15.7.9, iOS 16.6.1
- iPad OS 15.7.9, iPad OS 16.6.1
- macOS BigSur 11.7.10, macOS Monterey 12.6.9, macOS Ventura 13.5.2
- Chrome 116.0.5845.187
- Edge 109.0.1518.140, Edge 116.0.1938.81, Edge 117.0.2045.31
- Firefox 102.15.1, Firefox 115.2.1, Firefox 117.0.1
- Thunderbird 102.15.1, Thunderbird 115.2.2
- Opera 102.0.4880.51
- Vivaldi 6.2.3105.47.
- Brave v1.57.64
- Tor Browser 12.5.4.
- LibreOffice 7.5.7, LibreOffice 7.6.2
- Signal Desktop 6.30.2
- 1Password 8.10.15
- Microsoft Visual Studio Code August 2023 Recovery 2
- Node
- Des applications intégrant Pillow (bibliothèque de traitement d'image pour le langage Python)
- Des applications basées sur le framework Electron (correction à partir d'Electron 25.8.1)
- De nombreux cas où il y a la vulnérabilité, mais où la criticité est moindre : NGINX, Joomla, WordPress,...

Il manque Android : Android n'a pas reçu de correctif pour cette faille.
Édit : La faille n'est pas non plus inclus dans le correctif de sécurité mensuel du 5 octobre 2023 : Le correctif a été daté du 6 octobre et donc sera diffusé dans les mises à jour de novembre !
Il semblerait qu'il y ait une volonté de Google de retarder la correction. Voir ce message pour en savoir plus.

Les applications vulnérables sont très nombreuses :
- Tous les navigateurs web
- Tous les systèmes d'exploitations
- Tous les logiciels de messagerie
- Les suites bureautiques (Word, Excel, Writer, Calc,...)
- Toutes les visionneuses de photos (Visionneuse de photos Windows, Eye of Gnome, Gwenview, GPicView, Ristretto,...)
- Les logiciels de retouche d'image (Paint, Gimp, Photoshop,...)
- Les logiciels basés sur le framework Electron (Beekeeper, Bitwarden, CrashPlan, Cryptocat, Discord, Etcher, GitHub Desktop, Joplin, Microsoft Teams, Signal, Skype, Slack, Tidal, Twitch, Visual Studio Code, WebTorrent, WhatsApp, Wire, Yammer...)
- Certains logiciels ont bloqué temporairement l'usage de fichiers WebP : C'est le cas de X / Twitter (via l'application web) qui a bloqué plusieurs jours l'envoi d'images WebP (WebP est de nouveau autorisé depuis que les serveurs ont été corrigés)
- Logiciels de gestion de vidéos (FFMPEG intègre libwebp et de nombreux logiciels intégrent FFMPEG)

Le nombre d'applications concerné est colossal !

vivien · « **Réponse #2 le:** 23 septembre 2023 à 23:41:04 »

Analyse de la faille WebP

Analyse réalisée par par Ben Hawkes, dont j'ai traduit de larges extraits de son article (j'ai supprimé les passages les plus techniqes, n'hésitez pas à vous rendre sur https://blog.isosceles.com/the-webp-0day/ pour voir l'article complet en Anglais)

Chronologie

Début septembre (date exacte inconnue), Citizen Lab a détecté un comportement suspect sur l'iPhone d'« un individu employé par une organisation de la société civile basée à Washington DC » : Ils ont attribué ce comportement à un exploit « zéro clic » pour iMessage utilisé pour déployer le logiciel espion Pegasus du groupe NSO, et ont envoyé leurs conclusions techniques à Apple. Apple a réagi rapidement et a publié le 7 septembre un bulletin de sécurité présentant deux nouveaux CVE issus de l'attaque identifiée par Citizen Lab. Sur chaque CVE, ils notent : « Apple est au courant d'un rapport selon lequel ce problème pourrait avoir été activement exploité. »

Citizen Lab a appelé cette attaque "BLASTPASS", car les attaquants ont trouvé un moyen astucieux de contourner le bac à sable iMessage "BlastDoor". Nous n'avons pas tous les détails techniques, mais il semble qu'en regroupant un exploit d'image dans une pièce jointe PassKit, l'image malveillante serait traitée dans un processus différent, sans bac à sable. Cela correspond au premier CVE publié par Apple, CVE-2023-41061.

Mais vous auriez toujours besoin d'un exploit d'image pour profiter de cette situation, et en effet, le deuxième CVE publié par Apple est CVE-2023-41064, une vulnérabilité de dépassement de buffer dans ImageIO. ImageIO est le framework d'analyse d'images d'Apple. Il faudra une séquence d'octets et tentera de faire correspondre les octets à un décodeur d'image approprié. Plusieurs formats différents sont pris en charge et ImageIO est un domaine actif de recherche en sécurité. Nous n'avons pas encore de détails techniques sur CVE-2023-41064, nous ne savons donc pas quel format d'image cela affecte.

Mais nous savons qu'ImageIO a récemment commencé à prendre en charge les fichiers WebP, et nous savons que le 6 septembre (un jour avant le bulletin de sécurité iOS/macOS), l'équipe de sécurité d'Apple a signalé une vulnérabilité WebP dans Chrome qui a été corrigée en urgence (seulement 5 jours après le rapport initial) et marqué par Google comme "exploité à l'état sauvage". Sur cette base, il semble probable que la vulnérabilité BLASTPASS et CVE-2023-4863 (« le WebP 0day ») soient le même bug.

Analyse technique

En croisant l'ID de bogue du bulletin de sécurité de Chrome avec les récents commits open source dans le code de la bibliothèque libwebp, il est possible de trouver le correctif suivant : Correction de l'écriture OOB dans BuildHuffmanTable

Ce patch a été créé le 7 septembre (un jour après le rapport d'Apple) et correspond à CVE-2023-4863. Sur la base d'un premier examen du correctif, nous apprenons ce qui suit :

- La vulnérabilité réside dans la prise en charge de la « compression sans perte » pour WebP, parfois appelée VP8L. Un format d'image sans perte peut stocker et restaurer les pixels avec une précision de 100 %, ce qui signifie que l'image sera affichée avec une précision parfaite. Pour y parvenir, WebP utilise un algorithme appelé codage de Huffman.

- Bien que le codage de Huffman soit conceptuellement basé sur une structure de données arborescente, les implémentations modernes ont été optimisées pour utiliser des tables à la place. Le correctif suggère qu'il était possible de déborder de la table de Huffman lors du décodage d'une image non fiable.

- Plus précisément, les versions vulnérables utilisent des allocations de mémoire basées sur des tailles de buffer pré-calculées à partir d'une table fixe, et construiront ensuite les tables de Huffman directement dans cette allocation. La nouvelle version effectue une construction de « premier passage » qui calcule la taille totale dont la table de sortie aura besoin, mais n'écrit pas réellement la table dans le buffer. Si la taille totale est supérieure à la taille du buffer pré-calculée, une allocation plus importante est effectuée.

C'est un bon début, mais ce n'est pas constructif. Nous voulons être capables de construire un exemple de fichier qui puisse réellement déclencher le débordement, et pour ce faire, nous devons comprendre comment ce code fonctionne réellement et pourquoi les tailles des buffers pré-calculées n'étaient pas suffisantes.

En prenant du recul, que fait réellement le code vulnérable ? Lorsqu'une image WebP est compressée sans perte, une analyse de fréquence des pixels d'entrée est effectuée. L'idée de base est que les valeurs d'entrée qui apparaissent plus fréquemment peuvent être affectées à une séquence plus courte de bits de sortie, et les valeurs qui apparaissent moins fréquemment peuvent être affectées à des séquences plus longues de bits de sortie. Le véritable truc est que les bits de sortie sont intelligemment choisis afin que le décodeur puisse toujours déterminer la longueur de cette séquence particulière -- c'est-à-dire qu'il est toujours possible de lever l'ambiguïté entre un code à 2 bits et un code à 3 bits, et ainsi de suite, et ainsi le décodeur sait toujours combien de bits consommer.

Pour y parvenir, l'image compressée doit inclure toutes les informations statistiques sur les fréquences et les attributions de codes, afin que le décodeur puisse reproduire le même mappage entre codes et valeurs. Comme mentionné, en interne, webp utilise une table pour cela (ils l'appellent "huffman_table")... mais les tables elles-mêmes peuvent être assez volumineuses, et les inclure à côté de l'image compressée augmenterait la taille du fichier. La solution consiste également à utiliser le codage de Huffman pour compresser les tableaux.

Nous essayons de dépasser l'allocation huffman_tables dans ReadHuffmanCodes (src/dec/vp8l_dec.c), et l'idée est d'utiliser l'appel VP8LBuildHuffmanTable/BuildHuffmanTable dans ReadHuffmanCode (pas celui dans ReadHuffmanCodeLengths) pour déplacer le pointeur huffman_table au-delà du pré- taille de buffer calculée. Pour ajouter à la complexité, il existe en fait 5 segments différents de la table de Huffman, chacun avec une taille d'alphabet différente (par exemple, le nombre de symboles de sortie possibles pour ce segment particulier de la table) -- et nous devrons probablement créer les 5 ceux-ci doivent se rapprocher suffisamment de la fin du buffer pour provoquer un débordement.

[...]

En pratique, de nombreuses entrées de ce type débordent de huffman_tables. J'ai trouvé des longueurs de code qui entraînent des écritures jusqu'à 400 octets après la fin de l'allocation huffman_tables. Même avec un contrôle partiel de la valeur écrite, elle semble définitivement exploitable. Pour exploiter ce problème, vous devrez probablement utiliser les bits de cache de couleurs (ou num_htree_groups) pour obtenir une allocation huffman_tables qui est à peu près alignée sur les pages, mais cela ne devrait pas poser de problème. Il se peut qu'il existe d'autres moyens de provoquer une écriture OOB sur l'allocation huffman_tables, mais cette méthode semble être une approche acceptable.

[...]

vivien · « **Réponse #3 le:** 04 octobre 2023 à 12:46:46 »

Découverte précoce ?

Immédiatement après la mise à jour de sécurité de Chrome, des discussions ont eu lieu sur le fuzzing. Un format de fichier binaire implémenté par une bibliothèque de code C est une cible idéale pour le fuzzing – alors pourquoi ce bug n'a-t-il pas été trouvé plus tôt ? La bibliothèque n'avait-elle pas été suffisamment floue ? Ou n'avait-il pas été flou, n'est-ce pas ?

Le projet OSS-Fuzz de Google a fuzzé des centaines de bibliothèques open source depuis de nombreuses années, notamment libwebp et de nombreuses autres bibliothèques de décodage d'images. Il est possible d'examiner en détail la couverture du code pour les projets OSS-Fuzz, et il est clair que la prise en charge sans perte de WebP était largement fuzzée :

Le problème, nous le savons désormais, est que ce format est incroyablement complexe et fragile, et que les conditions préalables pour déclencher ce problème sont immenses. Parmi des milliards de possibilités, nous devons construire une séquence de 4 tables de Huffman valides qui sont dimensionnées au maximum pour deux tailles d'alphabet différentes (280 et 256) avant de construire un type très spécifique de table de Huffman invalide pour une troisième taille d'alphabet (40). Si un seul bit est erroné à un moment donné, le décodeur d'image génère une erreur et rien de grave ne se produit.

En fait, l'une des premières choses que Google a faites après la correction de WebP 0day a été de publier un nouveau fuzzer spécifiquement pour les routines de Huffman dans WebP. J'ai essayé d'exécuter ce fuzzer pendant un moment (avec un peu de rétroportage requis en raison des modifications de l'API) et, comme on pouvait s'y attendre, il n'a pas trouvé CVE-2023-4863.

Peut-être que je me trompe et que certaines des techniques les plus récentes impliquant une exécution symbolique (comme le TritonDSE de Quarkslab) seraient capables de résoudre ce problème - mais des approches standard basées sur des mutations bitflip avec une boucle de rétroaction de couverture de code, et même des approches légèrement plus sophistiquées comme CmpLog (entrée vers état), ne serait pas capable de franchir toutes ces étapes intermédiaires pour atteindre cet état extrêmement pessimal.

Il est intéressant de comparer ce bug avec une vulnérabilité antérieure, le bug Load_SBit_Png dans FreeType, qui a également été découvert « dans la nature » dans un exploit avancé de 0day. C'est similaire dans le sens où il s'agit d'un débordement de tas dans une bibliothèque commune pour un format de fichier binaire (pour les polices dans ce cas) écrit en C, c'est similaire dans le fait que cela affecte Chrome, et c'est similaire dans le sens où FreeType a été fortement floué dans les mois et les années qui ont précédé cette attaque. La différence était que le bogue Load_SBit_Png n'a pas été trouvé lors du fuzzing en raison d'un manque d'exploitation adéquate, plutôt que d'une contrainte spécifique de la vulnérabilité qui rendait le fuzz difficile. Si les harnais de fuzzing avaient été mis à jour plus tôt pour mieux refléter l'utilisation des API,

Ce n'est pas le cas pour le WebP 0day (CVE-2023-4863) -- à moins, peut-être, que vous ayez eu une chance incroyable en ayant un fichier dans votre corpus de fuzzing qui était déjà extrêmement proche du bug et que votre fuzzer était très bien calibré en termes de ses taux de mutation.

En pratique, je soupçonne que ce bug a été découvert lors d'une révision manuelle du code. En examinant le code, vous verrez l'allocation huffman_tables effectuée lors de l'analyse de l'en-tête d'un fichier VP8L, donc naturellement vous regarderez comment elle est utilisée. Vous essaieriez alors de rationaliser le manque de contrôles de limites sur l'allocation huffman_tables, et si vous êtes suffisamment persistant, vous approfondiriez progressivement le problème avant de vous rendre compte que le code était subtilement brisé. Je soupçonne que la plupart des auditeurs de code ne sont pas si persistants - ce truc de code de Huffman est hallucinant - donc je suis impressionné.

vivien · « **Réponse #4 le:** 04 octobre 2023 à 12:47:07 »

Quel est le problème

Il y a de bonnes et de mauvaises nouvelles.

✓ La bonne nouvelle est que l'équipe de Citizen Lab a, une fois de plus, fait un travail incroyable en détectant un exploit de premier plan utilisé dans la nature. Ils ont cultivé une grande confiance auprès des organisations et des individus les plus susceptibles d’être lésés par des exploits. C'est très impressionnant.

✗ La mauvaise nouvelle est que de tels exploits continuent d’avoir des ramifications sociétales, et nous ne pouvons que deviner à quel point la situation est réellement grave. La vérité est que personne ne le sait avec certitude, même ceux qui ont des exploits.

✓ La bonne nouvelle est qu'Apple et Chrome ont fait un travail incroyable pour répondre à ce problème avec l'urgence qu'il mérite. Il semble que les deux groupes aient publié une mise à jour pour leurs milliards d'utilisateurs en quelques jours seulement. C'est un exploit impressionnant, il faut un effort et une coordination incroyables entre les équipes d'analyse des menaces, d'ingénierie de sécurité, d'ingénierie logicielle, de gestion de produits et de test pour rendre cela possible, même à distance.

✗ La mauvaise nouvelle est qu'Android est probablement toujours affecté. Semblable à ImageIO d'Apple, Android dispose d'une fonctionnalité appelée BitmapFactory qui gère le décodage des images, et bien sûr, libwebp est pris en charge. À ce jour, Android n'a pas publié de bulletin de sécurité incluant un correctif pour CVE-2023-4863, bien que le correctif ait été fusionné dans AOSP. Pour mettre cela en contexte : si ce bug affecte Android, il pourrait alors potentiellement être transformé en un exploit à distance pour des applications comme Signal et WhatsApp. Je m'attendrais à ce que cela soit corrigé dans le bulletin d'octobre.

✓ La bonne nouvelle est que le bug semble être correctement corrigé dans la libwebp en amont, et ce correctif fait son chemin partout où il devrait aller.

✗ La mauvaise nouvelle est que libwebp est utilisé dans de nombreux endroits, et cela pourrait prendre un certain temps avant que le patch atteigne sa saturation. De plus, le code est encore très difficile à raisonner, et nous ne pouvons pas compter sur les fuzzers pour trouver d'autres bugs qui se cachent ici.

Dernières pensées

Le WebP 0day (CVE-2023-4863) est une vulnérabilité subtile mais puissante dans une bibliothèque open source largement utilisée et fortement exposée aux entrées des attaquants. Il est à la fois très difficile à fuzzer et très difficile à déclencher manuellement, mais le prix est un débordement de tas exploitable qui fonctionne sur plusieurs navigateurs, systèmes d'exploitation et applications. Il est probable que CVE-2023-4863 soit la même vulnérabilité utilisée dans les attaques BLASTPASS .

En pratique, il a fallu environ 3 jours de travail complets (avec beaucoup d'aide supplémentaire de @mistymntncop ) pour comprendre le bogue et créer un scénario de test reproductible.

Le manque d'informations techniques disponibles auprès des fournisseurs a rendu la vérification difficile, et on peut se demander à qui cela profite réellement. Les attaquants sont clairement très motivés pour suivre et exploiter les vulnérabilités de N jours, et le manque de détails techniques publiés ne les ralentira pas de manière significative. D’un autre côté, très peu de défenseurs disposent des ressources nécessaires pour effectuer le type d’analyse technique que j’ai partagé aujourd’hui. C'est contre-intuitif, mais en dissimulant des détails techniques de base sur la façon dont ces attaques fonctionnent dans une asymétrie qui profite principalement aux attaquants, vous vous retrouvez rapidement dans une situation où les attaquants ont accès à des informations sur la vulnérabilité/l'exploit que les défenseurs n'ont pas.

Ce bug montre également que nous comptons trop sur le fuzzing pour garantir la sécurité du code d'analyseur complexe. Le fuzzing est une bonne chose, mais nous savons qu'il existe de nombreux problèmes de sécurité graves qui ne sont pas faciles à flouter. Pour les surfaces d'attaque sensibles telles que le décodage d'images (surface d'attaque d'exploit à distance sans clic), il faut 1) investir davantage dans des révisions proactives du code source et 2) se concentrer de nouveau sur la garantie que ces analyseurs sont correctement mis en bac à sable.

Source : Larges extraits traduits de l'article The WebP 0day du blog Isosceles, article écrit par Ben Hawkes, le 21 septembre 2023

vivien · « **Réponse #5 le:** 04 octobre 2023 à 12:47:26 »

Mise à jour Android 11, Android 12 et Android 13 :

On peut critiquer le retard, Android est dans les derniers systèmes d'exploitation à proposer une mise à jour pour CVE-2023-4863.

Ces dernières semaines, tout le monde se demandaient comment le système Android (pas Chrome) pourrait ne pas être vulnérable à CVE-2023-4863. Aucune annonce n'a été effectuée.

Finalement, Android est bien vulnérable et c'est corrigé dans la mise à jour du 6 octobre à venir. Je ne comprends pourquoi ce n'est pas dans le correctif du 1ᵉʳ octobre, Google proposant également un correctif à cette date-là.

Source : https://source.android.com/docs/security/bulletin/2023-10-01?hl=fr

vivien · « **Réponse #6 le:** 04 octobre 2023 à 12:48:03 »

Mise à jour Apple iOS 16 :

Mise à jour Apple iOS 15 :

vivien · « **Réponse #7 le:** 04 octobre 2023 à 12:48:11 »

Mise à jour Apple macOS 13 :

Mise à jour Apple macOS 11 :

vivien · « **Réponse #8 le:** 04 octobre 2023 à 12:56:27 »

Mise à jour du Google Chrome : Le fait que la version ne comporte qu'un seul correctif est signe d'une urgence absolue pour la corriger et qu'il n'est pas possible d'attendre un groupement avec d'autres failles (ou Chrome 117 qui arrivait quelques jours après).

Mise à jour des logiciels Mozilla :

vivien · « **Réponse #9 le:** 04 octobre 2023 à 12:57:36 »

Mise à jour Microsoft :

Source : Microsoft

Outre le nombre d'applications vulnérables, il y a la gravité et un signe qui ne trompe pas, c'est la sortie Microsoft Edge version 109.0.1518.140 !

Oui, Microsoft propose une nouvelle version de Edge 109. Cette version obsolète de Edge vise Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 et Windows Server 2012 R2, dont la version de Edge est bloquée sur la version 109 : Un seul correctif dans cette nouvelle version 109 : La faille WebP CVE-2023-4863.

vivien · « **Réponse #10 le:** 04 octobre 2023 à 12:57:49 »

CVE-2023-4863, classé critique :

vivien · « **Réponse #11 le:** 04 octobre 2023 à 13:00:47 »

Comme il n'est pas toujours simple de trouver les dépendances aux librairies WebP dans un projet, il y a des logiciels pour aider :