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

vivien · « **Réponse #36 le:** 07 octobre 2023 à 14:05:31 »

D'autres échanges avec un développeur qui travaille sur Android Open Source Project, pour comprendre les lenteurs d'arrivée des correctifs de sécurité sur Android :

vivien · « **Réponse #37 le:** 07 octobre 2023 à 14:08:02 »

Traduction en français : (voir au-dessus pour la version d'origine en anglais)

Vivien GUEANT : On ne peut pas comparer Chrome, un navigateur, à Android, un système d'exploitation, mais :
- Ubuntu es un système d'exploitation et a corrigé WebP CVE-2023-4863 en 2 jours.
- Android a mis 2 mois à mettre à jour WebP CVE-2023-4863.
Peut-être y a-t-il des actions à entreprendre pour pouvoir corriger des failles critiques en quelques jours ?

GrapheneOS : Android l'a rapidement corrigé et l'a mis à disposition des partenaires via un bulletin spécial en dehors du cycle mensuel. Android est une famille de systèmes d'exploitation, pas un système d'exploitation spécifique. Vous faites référence à ce qui se passe avec Pixel OS d'origine comme étant ce qui se passe avec Android en général, mais ce n'est pas le cas.

Ils devraient disposer d’un processus beaucoup plus rapide pour tester et certifier les versions du système d’exploitation Pixel. Rien sur Android n'empêche les fournisseurs de publier un correctif comme celui-ci en quelques jours plutôt qu'en 1,5 à 2 mois. Ce sont les accords que les équipementiers concluent avec les opérateurs qui leur lient les mains.
https://android.googlesource.com/platform/external/webp/+/e2ac623f648ceef83779c7a1d36b46a56f38a042

Vous mélangez le temps qu'il leur faut pour publier les versions de production du système d'exploitation Pixel OS d'origine avec la rapidité avec laquelle cela a été corrigé sur Android et mis à la disposition des partenaires Android, ce qui a été rapide. Ce qui n'est pas rapide, ce sont les tests/certifications de mise à jour Pixel.

Ils devraient être en mesure de créer plus d’une version du système d’exploitation Pixel par mois. Ils devraient être en mesure de certifier la publication d’un correctif de sécurité pour le système d’exploitation des Pixel en quelques jours plutôt qu’en quelques semaines. Ce sont de graves problèmes causés par les processus qu’ils ont créés et convenus avec les opérateurs.

Il a été corrigé sur Android le 7 septembre après que les correctifs habituels d'octobre (2023-10-01, 2023-10-05) aient déjà été envoyés aux partenaires. Il a donc été ajouté à un nouveau niveau de correctif d'octobre (2023-10-06).

Les niveaux de correctifs sont une liste de vulnérabilités qui doivent être corrigées par les fournisseurs pour répertorier leur appareil comme ayant un niveau de correctif. Les numéros non divulgués sont sous embargo jusqu’à la date de sortie. Rien n'empêche les fournisseurs de prendre le correctif et de publier dans la journée du côté d'Android.

Oriane : Je comprends que le problème ne vient pas d'Android en tant que système d'exploitation principal, mais de sa mise en œuvre sur les *véritables smartphones*, n'est-ce pas ?

GrapheneOS : Il s'agit d'un problème lié aux processus de publication utilisés par les OEM, y compris ce que Google fait pour les Pixels. Cela a probablement beaucoup à voir avec les opérateurs. Les opérateurs n'aiment pas les mises à jour et sont extrêmement prudents à leur sujet. Ils souhaitent que chaque mise à jour soit certifiée auprès de leur réseau avant leur publication.

Cette certification inter-organisation prend beaucoup de temps. Souvent, les problèmes spécifiques à l'opérateur sont résolus trop tard pour en faire une version. Les Pixels disposent donc de versions spécifiques à l'opérateur pour publier plus tôt les correctifs spécifiques à l'opérateur.

Ils ne sont pas spécifiques à un opérateur dans le sens où ils ne prennent pas en charge d'autres opérateurs ou quelque chose comme ça. Il s'agit simplement d'un moyen de publier plus tôt des correctifs résolvant les problèmes de l’opérateur sans violer la période de certification en général. C'est un cas particulier pour un opérateur spécifique.

D'un point de vue technique, ils sont capables à 100 % de créer une nouvelle mise à jour et de la diffuser aux utilisateurs en 72 heures. Ce n'est pas le problème. Ils corrigent ces problèmes rapidement et peuvent préparer une version rapidement, mais ils ne sont pas autorisés à publier en raison de leurs processus / accords.

Si l’on réfléchit aux conséquences de ce qu’ils font, cette approche n’a pas de sens logique. La version de novembre du Pixel OS d'origine sera bientôt construite si ce n'est pas déjà fait. Il passera par des semaines de tests/certification. Voici le problème : s'ils trouvent un problème, que se passe-t-il ?

S'ils détectent un problème mineur, il sera résolu dans la version du mois prochain. S'ils découvrent un problème majeur, ils ont le choix : créent-ils une nouvelle version et retardent-ils le lancement en raison de la longue période de certification, ou envoient-ils le problème majeur et le corrigent-ils dans la version du mois prochain ?

L’approche qu’ils utilisent n’a aucun sens logique. Il peut sembler qu'ils soient très prudents et préfèrent la stabilité plutôt que de pouvoir envoyer rapidement des mises à jour, y compris des correctifs de sécurité. Cependant, cela les amène à publier des versions avec des régressions qu’ils ont déjà corrigées…

Cela a du sens si vous comprenez que cela ne dépend pas vraiment d'eux, car ils ont fait des compromis avec les opérateurs et autres équipementiers. Ils se sont engagés à faire les choses d'une certaine manière au lieu de gérer les mises à jour comme ils le font pour Chrome. Pour les inciter à patcher, vous devez le comprendre.

Oriane : Je comprends mieux, merci ! Et je suppose que le cas Pixel est le plus simple : Pixel est un produit Google. Peut-être que les fabricants de téléphones plus petits ont un processus encore plus lent ?
(Je veux dire : si vous êtes plus petit, vous êtes plus susceptible de compter sur des tiers pour votre logiciel ou une partie de celui-ci. Et cela peut aussi introduire des retards, je suppose, car plus de couches = plus de retards.)
La variété des téléphones entraîne-t-elle des retards ? Dans le fait que vous devez implémenter la mise à jour dans chaque smartphone (car la puce et tout ça change) ?
Cela peut ralentir le processus, car lorsque vous avez terminé de certifier, etc. votre téléphone le plus vendu, il en reste 15 AUTRES à corriger ?

GrapheneOS : il existe une source unique pour le système d'exploitation Pixel OS d'origine, qui est une extension d'AOSP [Android Open Source Project] avec des référentiels supplémentaires.
Ils ont des problèmes comme celui-ci corrigés en un jour ou deux avec des versions construites incluant les correctifs. Ce n'est pas un problème technique.

Il n’y a aucune raison technique pour laquelle ils y a besoin d’un processus de test/certification de plusieurs semaines. Il n'y a aucune raison technique pour laquelle ils ne peuvent pas publier une version dans les heures qui suivent l'application du correctif s'ils le souhaitent, mais bien sûr, en pratique, cela devrait vraiment passer par quelques jours de tests.

Oriane : Oui tester des régressions et donc ce n'est pas mal en soi !

GrapheneOS : Leur processus ne fonctionne même pas pour cela. Imaginez qu'ils ont connaissance d'une vulnérabilité aujourd'hui qu'ils corrigent et intègrent dans la version de novembre, ce qui nécessite peut-être déjà de la refaire. Maintenant, imaginons qu’une régression majeure soit constatée dans 2 semaines, à la mi-octobre.

Il ne resterait plus assez de temps pour résoudre le problème et publier le correctif dans le cadre de la version de novembre sans le retarder par rapport à la date de sortie habituelle du 1er lundi du mois. Ils doivent décider s'il vaut la peine de retarder la publication, y compris de retarder d'autres correctifs.

Dans de nombreux cas, ils livrent des versions avec des régressions qu'ils ont déjà corrigées en interne des semaines plus tôt. Leur processus est dysfonctionnel. Ils devraient être en mesure de corriger les régressions et de les tester en quelques jours au maximum. Quel est l’intérêt de tous les tests s’ils ne peuvent pas apporter de correctifs ?

vivien · « **Réponse #38 le:** 27 octobre 2023 à 22:35:29 »

Je continue de mettre ici ces échanges, car sinon, uniquement sur X, on va les perdre :

vivien · « **Réponse #39 le:** 27 octobre 2023 à 22:37:19 »

Traduction en français : (voir au-dessus pour la version d'origine en anglais)

Vivien GUEANT : La mise à jour de sécurité déployée sur les Pixel 6 et Pixel 7 se termine le 5 octobre, le patch WebP CVE-2023-4863 ne serait donc pas inclus, ce dernier étant daté du 6 octobre.

GrapheneOS : Le système d'exploitation du Pixel aurait pu fournir le correctif pour CVE-2023-4863 juste après sa correction sur Android le 7 septembre. Android ne détermine pas quand un OEM publie des mises à jour. Ils choisissent de publier une mise à jour Pixel par mois, et les processus pour le faire certifier prennent 2 à 4 semaines.

Il n’était pas nécessaire d’attendre jusqu’en octobre pour corriger le problème. Un OEM choisit le moment où il publie une mise à jour pour son système d’exploitation. Android l'a corrigé début septembre et l'a mis à la disposition des partenaires, mais APRÈS, la version du système d'exploitation Pixel d'octobre avait déjà été préparée.

Cela pose le problème dans la manière dont ils publient le système d'exploitation Pixel depuis le début. On sait que c'est un problème depuis des années. Il n'y a pas d'exceptions à la façon dont cela fonctionne et ce bug WebP corrigé dans le cadre de leur cycle habituel est toujours la façon dont les choses fonctionnent pour eux.

Il n'y a aucune raison qui impose cette vitesse de correction, mis à part le fait qu'ils ont probablement conclu des accords avec des fabricants qui leur liraient les mains et exigeraient qu'ils passent par de longs processus de certification. Ce patch n'était pas sous l'embargo d'Android, ce n'est donc pas pertinent d'attendre.

Il est très problématique d'avoir un embargo de 30 jours avec une large divulgation aux fournisseurs, mais cela n'est pas le cas pour cet exemple. Ici, c'est l'impact négatif causé par le long processus de publication / certification du système d'exploitation Pixel. Nous avons essayé d’expliquer les différents problèmes ici.

vivien · « **Réponse #40 le:** 27 octobre 2023 à 22:46:35 »

vivien · « **Réponse #41 le:** 27 octobre 2023 à 23:03:11 »

Traduction en français : (voir au-dessus pour la version d'origine en anglais)

GrapheneOS : Les niveaux de correctifs sont une liste de vulnérabilités qui doivent être corrigées par les fournisseurs pour répertorier leur appareil comme ayant un niveau de correctif. Les numéros non divulgués sont sous embargo jusqu'à la date de sortie. Rien n'empêche les fournisseurs de prendre le correctif et de le publier dans la journée du côté d'Android.

Ils ont rapidement livré un correctif pour CVE-2023-5217 (vulnérabilité libvpx) dans Chromium et ont appliqué le correctif pour Android à la fois publiquement et en interne, mais il n'est pas non plus fourni par le système d'exploitation Pixel :
https://android.googlesource.com/platform/external/libvpx/+/baed1218776fba096c05c1c683564ba4523d17e5
C’est ainsi que les choses fonctionnent en général, pas dans un cas particulier.

Nous livrons des correctifs pour littéralement des centaines de vulnérabilités du noyau Linux qui ne sont pas encore corrigées par le système d'exploitation Pixel, car il faut plusieurs mois pour livrer les versions LTS https://kernel.org. Nous avions l'habitude de fusionner nous-mêmes les modifications LTS, mais nous utilisons désormais Android GKI LTS pour réduire la charge de travail.

Ils choisissent de rétroporter uniquement des correctifs spécifiques avec leur délai habituel de 1 à 2 mois pour le cycle de publication du système d'exploitation Pixel dans les versions mensuelles normales. Ils fusionnent les versions LTS dans le cadre de versions trimestrielles / annuelles comme Android 14, qui subissent des mois de tests avant de les publier.

Il peut sembler qu'ils sont trop prudents et effectuent beaucoup trop de tests avant de publier quelque chose. Cependant, si vous y réfléchissez, vous réaliserez que leur approche leur cause d'énormes problèmes, car ils ne peuvent pas réellement résoudre les problèmes détectés lors des tests avant de publier une version...

Sous-entendu : quand une régression est observée pendant la période de 4 semaines de test, il est trop tard pour que le correctif soit testé et donc la version d'Android sort avec la régression et il faut attendre un mois de plus pour avoir le correctif de la régression, qui était pourtant prêt avant la sortie de la mise à jour qui a introduit la régression.

vivien · « **Réponse #42 le:** 27 octobre 2023 à 23:15:34 »

vivien · « **Réponse #43 le:** 27 octobre 2023 à 23:15:59 »

Traduction en français : (voir au-dessus pour la version d'origine en anglais)

Oriane : (Je veux dire : si vous êtes plus petit, vous êtes plus susceptible de compter sur des tiers pour votre logiciel ou une partie de celui-ci. Et cela peut aussi introduire des retards, je suppose, car plus de couches = plus de retards.)

GrapheneOS : Cela n'est pas pertinent pour corriger des problèmes comme celui-ci. Les problèmes libwebp, libvpx et autres problèmes similaires sont rapidement corrigés dans GrapheneOS et en interne pour le système d'exploitation Pixel, mais ils ont un processus de publication / certification très lent. Ce n'est pas un problème avec l'application de correctifs et la création d'une version mise à jour.

Oriane : Bon, le problème réside vraiment dans : l'accord qui a été négocié avec les fournisseurs et / ou l'OEM et / ou le fabricant.

GrapheneOS : Il s'agit du constructeur OEM, donc tout ce qui compte, c'est ce qu'il a négocié avec les fournisseurs et ses propres politiques. Ils ont intégré dans une certaine mesure les lésions cérébrales causées par les fournisseurs dans leurs propres politiques / approches, il est donc difficile de savoir à quel point les accords avec les fournisseurs coûtent cher par rapport à leur propre mauvais processus.

Oriane : Je comprends mieux, merci ! Et je suppose que le cas Pixel est le plus simple : Pixel est un produit Google. Peut-être que les fabricants de téléphones plus petits ont un processus encore plus lent ?

GrapheneOS : Le message initial concerne le système d’exploitation Pixel. On croit souvent, à tort, qu'Android est un système d'exploitation spécifique. Ce n'en est pas un. Chaque OEM possède ses propres forks d’AOSP. Les Pixels utilisent une arborescence source unique pour tous les modèles Pixel. La plupart des OEM ont plusieurs forks d’AOSP en même temps.

Android a résolu cette Faille WebP CVE-2023-4863 en quelques jours et a rapidement publié un bulletin partenaire définissant un nouveau niveau de correctif d'octobre (en septembre). Les OEM ont bien sûr été autorisés à publier le correctif immédiatement, car il n’y a pas d’embargo. Le fait d'être dans le bulletin d'octobre ne signifie pas que vous devez attendre.

Cela signifie que pour réclamer le niveau de correctif 06/10/2023 ou supérieur, vous devez le corriger. C'est ça. Ils n'ont pas pu l'ajouter au 01/10/2023, car ce correctif était déjà défini en septembre lorsque la faille WebP CVE-2023-4863 est arrivée. Ils ne peuvent pas l'inclure rétroactivement dans le 01/10/2023, qui était en test par les fournisseurs.

Ils auraient pu publier une version du système d'exploitation Pixel avec le correctif en septembre, si leurs processus leur permettaient de réaliser des versions sans x semaines de certification et s'ils étaient autorisés à réaliser plus d'une version par mois. Le retard n'est pas un problème technique. Ce n'est pas pour des raisons techniques.

vivien · « **Réponse #44 le:** 09 novembre 2023 à 21:18:03 »

7 septembre 2023 mise à jour iOS pour corriger la faille WebP CVE-2023-4863 :

Citation de: vivien le 04 octobre 2023 à 12:48:03

Mise à jour Apple iOS 16 :

9 novembre 2023 mise à jour Android pour corriger la faille WebP CVE-2023-4863 sur les smartphones Google Pixel, 63 jours après Apple :

Pour les smartphones qui non Google, le correctif pourrait mettre plusieurs mois à arriver pour certaines marques qui ne font pas de correctif mensuel.

vivien · « **Réponse #45 le:** 09 novembre 2023 à 21:20:21 »

Voici pourquoi une correction rapide est essentielle :

Je précise que ici, le code pour faire un fichier WebP vulnérable a été publié le 21 septembre, donc à J+14, alors que le correctif Android sur les Pixel est arrivé à J+63 !

vivien · « **Réponse #46 le:** 31 décembre 2023 à 13:28:53 »

Selon Amnesty International, le smartphone du journaliste Indien Siddharth Varadarajan, le fondateur du média The Wire, a été attaqué le 16 octobre 2023.

Ils ont trouvé la preuve de l’envoi d’une attaque « zero-click » sur son iPhone. Les traces correspondraient à la faille BLASTPASS, identifiée par Citizen lab en septembre dernier, estampillée CVE-2023-41064 et patchée par Apple depuis sa version iOS 16.6.1 qui correspond à la faille WebP CVE-2023-4863.

Bref, NSO tentait encore d'atteindre des iPhone non mis à jour en octobre 2023.

Selon le Washington Post, Apple a également subi des intimidations de l’administration indienne qui souhaitait que l'affaire ne fasse pas de bruit.

Plus d'information : Des journalistes ciblés par l’utilisation de Pegasus en Inde, écrit par Martin Clavey le 29 décembre 2023.