La Fibre
Télécom => Réseau => 
Attaques informatiques => Discussion démarrée par: 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
(https://lafibre.info/images/format/202309_faille_webp_cve-2023-4863.webp)
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 (https://fr.wikipedia.org/wiki/Projet_Pegasus_(journalisme)). 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 :
(https://lafibre.info/images/ssl/202210_vitesse_et_ampleur_de_la_banalisation_des_vulnerabilites.webp)
-
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 (https://lafibre.info/attaques/webp-cve-2023-4863/msg1036720/#msg1036720).
(https://lafibre.info/images/smileys/firewall_ordinateur.svg)
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 !
-
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é (https://support.apple.com/en-us/HT213905) 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 (https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html?ref=blog.isosceles.com)". 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 (https://developer.apple.com/documentation/passkit/?ref=blog.isosceles.com), 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 (https://chromium.googlesource.com/webm/libwebp/+/902bc9190331343b2017211debcec8d2ab87e17a?ref=blog.isosceles.com)
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 (https://en.wikipedia.org/wiki/Huffman_coding?ref=blog.isosceles.com).
- 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.
[...]
-
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 (https://storage.googleapis.com/oss-fuzz-coverage/libwebp/reports/20230901/linux/src/libwebp/src/utils/report.html?ref=blog.isosceles.com), et il est clair que la prise en charge sans perte de WebP était largement fuzzée :
(https://lafibre.info/images/ssl/202309_libwebp_fuzz.webp)
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é.
-
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 (https://blog.isosceles.com/the-webp-0day/) du blog Isosceles, article écrit par Ben Hawkes, le 21 septembre 2023
-
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à.
(https://lafibre.info/images/format/202310_webp_maj_android.webp)
Source : https://source.android.com/docs/security/bulletin/2023-10-01?hl=fr
-
Mise à jour Apple iOS 16 :
(https://lafibre.info/images/format/202309_webp_maj_apple_ios16.webp)
Mise à jour Apple iOS 15 :
(https://lafibre.info/images/format/202309_webp_maj_apple_ios15.webp)
-
Mise à jour Apple macOS 13 :
(https://lafibre.info/images/format/202309_webp_maj_apple_macos13.webp)
Mise à jour Apple macOS 11 :
(https://lafibre.info/images/format/202309_webp_maj_apple_macos11.webp)
-
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).
(https://lafibre.info/images/format/202309_webp_maj_chrome.webp)
Mise à jour des logiciels Mozilla :
(https://lafibre.info/images/format/202309_webp_maj_firefox.webp)
-
Mise à jour Microsoft :
(https://lafibre.info/images/format/202310_webp_maj_teams_skype.webp)
Source : Microsoft (https://msrc.microsoft.com/blog/2023/10/microsofts-response-to-open-source-vulnerabilities-cve-2023-4863-and-cve-2023-5217/)
(https://lafibre.info/images/format/202309_webp_maj_windows.webp)
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.
(https://lafibre.info/images/format/202309_webp_maj_edge109.webp)
-
CVE-2023-4863, classé critique :
(https://lafibre.info/images/format/202309_webp_cve-2023-4863.webp)
-
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 :
(https://lafibre.info/images/format/202309_snyk_image_libwebp_insights_report.webp)
-
La liste des logiciels vulnérable à la faille CVE-2023-4863 est énorme :
Libre Office a confirmé utiliser libwebp 1.3.1 et donc être vulnérable à des images WebP malicieuses.
Voici l'annonce de la mise à jour :
(https://lafibre.info/images/format/202309_webp_maj_libre_office.webp)
(https://lafibre.info/images/format/202310_webp_maj_libre_office_ubuntu2304.webp)
L'application Signal Desktop, également vulnérable, à elle déjà été mise à jour, la version 6.30.2 corrige le bug.
(https://lafibre.info/images/format/202309_webp_maj_signal.webp)
D'autres applications de messagerie comme Matrix étaient vulnérables et ont été corrigées.
-
Tous les systèmes d'exploitations doivent également recevoir une mise à jour, car ils permettent d'afficher le contenu d'un fichier WebP
Mise à jour Ubuntu le 14 septembre 2023 : (visualisation des images WebP dans le système)
(https://lafibre.info/images/format/202309_webp_maj_ubuntu.webp)
-
Correctifs Red Hat :
(https://lafibre.info/images/format/202309_webp_maj_redhat.webp)
-
Je profite de ce topic ô combien intéressant et pertinent, pour pousser un coup de gueule sur les MaJ de Chrome...
Excellent navigateur au demeurant, que j'utilise depuis de nombreuses années, j'ai du mal à comprendre la logique du mécanisme de mise à jour de la version desktop (Windows tout au moins) : si on ne va pas de soi-même dans l'onglet "A propos de Chrome.." de la rubrique "Aide", la mise à jour ne se fait pas automatiquement, ou alors j'ai zappé qqchose...
Comment, en 2023, un tel logiciel ne pourrait pas se mettre à jour de lui-même, ou au moins afficher une notif pour signaler qu'un MaJ est dispo ???
Si (encore une fois, dans mon cas...) je ne vais pas de temps en temps checker, Chrome n'est jamais mis à jour !
-
Les mises à jour se font silencieusement (Chrome, comme Firefox ou Edge).
En allant dans "À propos de Chrome.." tu vas juste forcer une vérification, mais sans le faire la mise à jour est distribuée après quelques heures à quelques jours au maximum, si tu n'as pas désactivé les mises à jour.
-
Ok merci tu me rassures !
Je trouve juste un peu perturbant de ne pas être informé que la MaJ a été faite, alors...
Mais je chipote peut-être. ;D
-
C'est complétement silencieux. Il y a plusieurs mises à jour par mois.
-
Ok merci tu me rassures !
Je trouve juste un peu perturbant de ne pas être informé que la MaJ a été faite, alors...
Mais je chipote peut-être. ;D
ho oui, quel monde merveilleux ce serait, d'etre prevenu explicitement pour chaque maj de securité !
Le mieux ce serait un appel telephonique "he mec ! la maj est passée sur ton tel ! c'est bon !"
-
ho oui, quel monde merveilleux ce serait, d'etre prevenu explicitement pour chaque maj de securité !
Le mieux ce serait un appel telephonique "he mec ! la maj est passée sur ton tel ! c'est bon !"
N'importe quoi !
Comment comparer des choux et des bananes !
-
N'importe quoi !
Comment comparer des choux et des bananes !
heu, je te cite :
"Ok merci tu me rassures !
Je trouve juste un peu perturbant de ne pas être informé que la MaJ a été faite, alors..."
donc un mec perturbé et qui a besoin d'etre rassuré, c'est bien ca ? ou je ne sais pas lire correctement ? :)
-
Je suis rassuré dans le sens où j'apprend par Vivien que les MaJ sont faites, point barre...
Quelles soient faites en mode silencieux me va très bien, encore faut-il le savoir une bonne fois pour toute...
Une notif pour dire qu'une MaJ vient d'être faite ne mange pas de pain...
Quant à ton exemple du tel, sauf erreur sur le mien je suis prévenu lorsqu'un correctif de sécu est passé...
-
Souvent Firefox ouvre un onglet "What's new" au prochain lancement suite à une mise à jour transparente.
-
Les mises à jour se font silencieusement (Chrome, comme Firefox ou Edge).
En allant dans "À propos de Chrome.." tu vas juste forcer une vérification, mais sans le faire la mise à jour est distribuée après quelques heures à quelques jours au maximum, si tu n'as pas désactivé les mises à jour.
si je pige bien la seule diff se fait sous nux ou mac, car ils exigent le mdp root pour maj (en tout cas j'ai jamais vu de FF/chrome se maj de lui meme sans passer par le terminal)
en complément, si la faille pegasus (une parmi des millions?) passe bien par le webp, alors les vieux logiciels peuvent dormir tranquille : ils revent pas du webp dans la nuit, et n'auront donc pas d'intrusion à constater au ptit dej, car le format est "trop récent" pour qu'ils le prennent en charge (de ce que j'en comprnds)
-
Sous Linux, les mises à jour sont gérées par le système d'exploitation et généralement se font silencieusement (certaines distributions demandent le mot de passe root, mais d'autres non, car le process qui gère les mises à jour est lancé avec les droits suffisants)
Souvent Firefox ouvre un onglet "What's new" au prochain lancement suite à une mise à jour transparente.
En cas de mise à jour fonctionnelle.
Il y a toute une partie des mises à jour qui est exclusivement destinée à combler des failles de sécurité importantes, qui ne peuvent pas attendre la mise à jour fonctionnelles suivantes.
Il y a quelques jours, on a eu un correctif 0-day concernant le codec vidéo VP8 dans tous les navigateurs.
=> https://www.mozilla.org/en-US/security/advisories/mfsa2023-44/
=> https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_27.html
-
La machine à remonter le temps existe : On est bien le 4 octobre 2023 et j'ai déjà les mises à jour de sécurité du 5 octobre 2023 !
Moins drôle, Google propose 3 date de mise à jour de sécurité avec des patchs différents : 1ᵉʳ octobre 2023 / 5 octobre 2023 / 6 octobre 2023 cf https://source.android.com/docs/security/bulletin/2023-10-01?hl=fr
Le correctif du 5 octobre inclus celui du 1ᵉʳ octobre, plus d'autres supplémentaires.
Le correctif du 6 octobre inclus celui du 1ᵉʳ octobre et 5 octobre, plus un seul correctif : La fameuse faille WebP CVE-2023-4863.
CVE-2023-4863 a été déclaré par Google le 12 septembre 2023 (et la même faille déclarée par Apple le 7 septembre 2023) : Pourquoi un correctif aussi tard dans Android ? Je me demande à quel jeu joue Google.
Et je vous le donne dans le mille, le correctif d'octobre déployé sur mon pixel 6 et c'est le correctif à la date du 5 octobre qui est déployé ! J'ai tous les correctifs, sauf la faille WebP. Il y a eu une volonté de la corriger tardivement cette faille, je dois attente le correctif de novembre pour être corrigé, alors que c'est une faille de début septembre et qu'elle est corrigée presque partout ailleurs.
(https://lafibre.info/testdebit/android/202310_google_android14_maj_securite.webp)
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à.
(https://lafibre.info/images/format/202310_webp_maj_android.webp)
Source : https://source.android.com/docs/security/bulletin/2023-10-01?hl=fr
-
Merci pour les infos détaillées. NextInpact a un article sur le sujet :
https://www.nextinpact.com/article/72512/faille-critique-webp-dangers-dune-mauvaise-communication
-
J'ai contacté son auteur, Vincent Hermann, pour lui demander de faire une mise à jour.
On était étonné de l'absence de corrections de la faille dans Android en septembre.
Lors du Bulletin de sécurité Android d'octobre 2023, j'ai été étonné par le fait de séparer cette faille et de la date du 6 octobre.
Finalement, le correctif déployé s'arrête au 5 octobre et n'intègre pas le correctif daté du 6 octobre : je suis persuadé que Google retarde VOLONTAIREMENT le correctif de la faille WebP CVE-2023-4863 sur Android, vu qu'il faudra maintenant attendre le correctif de novembre, incompréhensible 😱
Quand on regarde le bulletin de sécurité Android d'octobre 2023 :
Niveau du correctif de sécurité du 01/10/2023 :
CVE-2023-21266
CVE-2023-40116
CVE-2023-40120
CVE-2023-40131
CVE-2023-40140
CVE-2023-21291
CVE-2023-40121
CVE-2023-40134
CVE-2023-40136
CVE-2023-40137
CVE-2023-40138
CVE-2023-40139
CVE-2023-40129
CVE-2023-21244
CVE-2023-40117
CVE-2023-40125
CVE-2023-40128
CVE-2023-40130
CVE-2023-40123
CVE-2023-40127
CVE-2023-40133
CVE-2023-40135
CVE-2023-21252
CVE-2023-21253
CVE-2023-40127
CVE-2023-21252
Niveau du correctif de sécurité du 05/10/2023 : correctifs du 01/10/2023 +
CVE-2021-44828
CVE-2022-28348
CVE-2023-4211
CVE-2023-33200
CVE-2023-34970
CVE-2023-20819
CVE-2023-32819
CVE-2023-32820
CVE-2023-40638
CVE-2023-33029
CVE-2023-33034
CVE-2023-33035
CVE-2023-24855
CVE-2023-28540
CVE-2023-33028
CVE-2023-21673
CVE-2023-22385
CVE-2023-24843
CVE-2023-24844
CVE-2023-24847
CVE-2023-24848
CVE-2023-24849
CVE-2023-24850
CVE-2023-24853
CVE-2023-33026
CVE-2023-33027
Niveau du correctif de sécurité du 06/10/2023 : correctifs du 01/10/2023 + correctifs du 05/10/2023 +
CVE-2023-4863 (notre faille WebP)
Le correctif déployé sur les Pixel pour octobre s'arrête au 5/10 et intègre donc tous les correctifs sauf celui sur WebP qui sera corrigé avec le patch de novembre 2023.
Cela pourrait s'expliquer si le correctif est tout récent (ce n'est pas le cas, cela fait presque un mois qu'il est déployé partout), complexe (ceux qui l'ont analysé note sa simplicité). Je ne comprends pas cette volonté de ne pas le corriger, sachant qu'il y a dans la nature tout le nécessaire pour faire des images WebP malveillantes et vu la publicité de ce bug, il doit y avoir des cybercriminels qui se disent qu'il y a une fenêtre de tir intéressante.
Comme le rappelait Google lors de la mise à jour de Chrome début septembre : "Google est conscient qu'un exploit pour CVE-2023-4863 existe dans la nature"
(https://lafibre.info/images/format/202309_webp_maj_chrome.webp)
-
On m'a également demandé si la faille est présente au niveau d’Android ou de Chrome seulement ?
La faille est présente partout où il y a du traitement d'image, d'où la variété des logiciels qui ont publié un correctif.
La sévérité n'est pas la même partout. Par exemple, le correctif LibreOffice parle de "correctif sécurité clé", mais le risque est presque nul : Un document Open Document ne transmet pas d'image WebP : elles sont converties en PNG avant. Donc il n'est pas possible de piéger l'utilisateur avec un document Writer malveillant. Pour exploiter la faille, il faut que l'utilisateur intègre lui-même un fichier malveillant, bref rien de trés réaliste, mais c'est bien de corriger les failles.
(https://lafibre.info/images/format/202309_webp_maj_libre_office.webp)
Pour Android, le risque est de recevoir un message avec une image WebP malveillante. Là ce n'est pas Chrome qui va décoder l'image, mais Android et il n'est pas corrigé.
Le correctif Android me semble donc important (contrairement au correctif LibreOffice). À noter que Microsoft n'a pas encore annoncé le correctif de Word ou Excel, qui comme LibreOffice permet d'importer une image WebP qui sera convertie avant d'être enregistrée.
-
je suis persuadé que Google retarde VOLONTAIREMENT le correctif
Je me demande quel est l'intérêt de Google de retarder ce correctif...
-
Quel serait le but de Google à ne pas le corriger le bug ?
Aucune idée.
C'est étonnant, car Google est plutôt bon sur la sécurité.
-
Le patch correctif pour la faille WebP CVE-2023-4863 est dans "Android Open Source Project" depuis le 18 septembre 2023.
Pourquoi le dater dans les correctifs Android au 6 octobre, pour l'exclure de la mise à jour d'octobre ?
(https://lafibre.info/images/format/202309_webp_maj_android_open_source_project.webp)
Source: https://grapheneos.org/releases#2023091800
Dans Android (différent de "Android Open Source Project"), le correctif passe du 18 septembre au 6 octobre 2023.
Il aurait dû être dans les correctifs datés du 1er octobre.
6 jours qui font au final un mois d'attente supplémentaire et surtout qui font que l'on se pose la question de pourquoi un tel décalage, qui y gagne ?
(https://lafibre.info/images/format/202310_webp_maj_android_anglais.webp)
Source : https://source.android.com/docs/security/bulletin/2023-10-01
-
On a une explication de la lenteur (le patch WebP CVE-2023-4863 arrivera en novembre sur Android) avec un développeur qui travaille sur Android Open Source Project :
Source : https://twitter.com/wdesportes/status/1709829520075657515
(https://lafibre.info/images/format/202310_webp_explication_grapheneos.webp)
-
Traduction en français : (voir au-dessus pour la version d'origine en anglais)
GrapheneOS : GrapheneOS a appliqué le correctif en septembre : https://grapheneos.org/releases#2023091800
Nous appliquons également des centaines de correctifs de sécurité du noyau qui ne sont pas encore disponibles dans AOSP [Android Open Source Project] ou dans le système d'exploitation d'origine. Nous appliquons également d'autres correctifs plus tôt. C'est une partie mineure de ce sur quoi nous travaillons, mais nous y consacrons du temps.
Vivien GUEANT : Comment expliquer que le correctif du #WebP CVE-2023-4863 soit daté du 6 octobre ? Le patch déployé sur les smartphones pixel se termine le 5 octobre, ce qui inclut tous les patchs d'octobre, à l'exception du CVE-2023-4863, le seul daté du 6 octobre. Il faudra attendre novembre pour obtenir le correctif.
GrapheneOS : Les dates des niveaux de patch sont arbitraires. AAAA-MM-01 sont les correctifs AOSP [Android Open Source Project], AAAA-MM-05 sont les correctifs liés au noyau et au matériel spécifiques aux périphériques et AAAA-MM-06 est utilisé pour ajouter des correctifs une fois que les niveaux de correctifs standard ont déjà été finalisés. Les niveaux de correctifs incluent tous les niveaux précédents.
Les niveaux de correctifs sont finalisés environ 30 jours avant la sortie. Les correctifs peuvent être supprimés s'ils provoquent des régressions et être déplacés vers une version ultérieure, mais ils ne peuvent pas ajouter de nouveaux correctifs aux niveaux de correctifs qu'ils ont déjà définis, car il existe une période de divulgation standard aux OEM.
Il leur faut des semaines pour qu'une version passe par tous leurs processus de test et de certification. S’ils y vont rapidement, ils peuvent le faire en 15 jours environ. C'est pourquoi ils ne sont pas en mesure d'inclure des correctifs supplémentaires dans leur version sans retarder l'ensemble de la version de plusieurs semaines.
Leur politique est de ne faire qu'une seule version par mois, sinon ils pourraient avoir le correctif WebP disponible dans une nouvelle version dans une semaine ou deux. Le retard est dû à leurs politiques en matière de versions, en particulier à leurs processus de test et de certification. Ils ne sont pas capables d'avancer rapidement.
Vivien GUEANT : Mais le patch est corrigé sur Google Chrome depuis 3 semaines ! Vous comprenez ma surprise de ne pas voir le patch WebP CVE-2023-4863 dans le patch de sécurité d'octobre, alors même que la vulnérabilité est exploitée. Pourquoi le patch distribué dans les smartphones Pixel n'est-il pas celui du 6 octobre ?
GrapheneOS : Notre réponse explique pourquoi ils ne l'ont pas encore inclus : https://twitter.com/GrapheneOS/status/1709864967611036040
Il leur faut normalement 3 à 4 semaines pour qu'une version passe par leurs processus de test/certification. C’est pourquoi la version de septembre basée sur Android 13 a été publiée plus de la moitié du mois.
Ils ont construit la version de septembre le 1er septembre après avoir décidé de retarder Android 14 à octobre. Cette version a été publiée le 18 septembre car c'est le temps qu'il leur faut pour effectuer leurs tests et leur certification lorsqu'ils sont pressés. Cela prend normalement plus de temps.
Ils ne sont pas en mesure de créer une version puis de la publier après quelques jours de tests. Il existe de nombreuses procédures officielles qu'ils se sont engagés à suivre, notamment dans le cadre des accords avec les transporteurs. Ils devraient améliorer considérablement cela, mais c’est ainsi que les choses se passent actuellement.
Ce n'est en aucun cas spécifique à ce patch WebP. Vous n'êtes au courant que de ce cas particulier, mais c'est ainsi que cela fonctionne en général. Il existe des centaines de correctifs de sécurité du noyau inclus dans GrapheneOS qui ne sont pas encore inclus dans AOSP ou dans le système d'exploitation Pixel d'origine, car cela prend encore plus de temps.
Ils ont déjà intégré le patch WebP avant octobre. Ce qui vous manque, c'est qu'ils n'ont pas été autorisés à publier la version incluse dans la mise à jour d'octobre, car elle n'a pas été incluse à temps pour qu'ils puissent terminer un nouveau processus de test/certification de version complète.
Ils se sont probablement également engagés à ne faire qu'une seule mise à jour par mois, les empêchant de publier une version avec le correctif, y compris dans une semaine ou deux. Il sera inclus dans leur mise à jour de novembre. C’est exactement ainsi que fonctionne leur processus de publication et de test/certification. C'est lent.
Le problème n'est pas qu'ils n'ont pas réussi à intégrer rapidement le correctif WebP. Le problème est qu'ils ont pour politique d'effectuer 3 à 4 semaines de tests/certifications pour les versions, qui peuvent être accélérées jusqu'à 2 à 3 semaines dans des situations particulières, mais ils ont dû lancer Android 14 à une date précise.
Ils seraient bientôt en mesure de publier une nouvelle version incluant le correctif WebP une fois les tests/certificats terminés, mais leur politique est de faire 1 mise à jour par mois et cela peut faire partie de leurs accords avec les opérateurs. Les opérateurs n'aiment pas les mises à jour et les tolèrent à peine. Ils ont beaucoup de règles.
Ce n'est pas inhabituel et ce n'est pas quelque chose de nouveau. C’est ainsi que fonctionne le processus de publication et de test/certification. Les problèmes de sécurité urgents découverts début octobre ne seront résolus qu'en décembre, car la version de novembre est déjà en cours de construction.
À cette époque [5 octobre], ils préparent la version de novembre et la soumettent à 3-4 semaines de tests/certification. Si un problème de sécurité est découvert au cours d'une semaine d'exploitation active, ils peuvent choisir de retarder la date de sortie de novembre pour l'inclure ou de le faire en décembre.
Vivien GUEANT : Donc une autre question : Pourquoi le processus de patching est-il beaucoup plus rapide pour Google Chrome que pour Android ? Pour Chrome, il ne semble pas nécessaire d’attendre 3 semaines.
GrapheneOS : Cela s'explique en partie par le fait que Chrome est un navigateur et n'a pas autant de choses à tester qu'un système d'exploitation complet. Chrome a également un cycle de publication beaucoup plus rapide. Chrome publie des versions majeures toutes les 4 semaines plutôt que chaque année, de sorte que les changements se produisent plus progressivement dans Chrome plutôt que d'un seul coup.
Android a une durée de développement beaucoup plus longue et des branches stables. Android 14 est entré en test public en février 2023, mais était en cours de développement avant cette date, et il est maintenant publié comme stable en octobre 2023. Android 13 était toujours activement développé en parallèle jusqu'à ce mois-ci également.
Android est une famille d'OS, pas un OS spécifique. Android compte de nombreux partenaires OEM. Chacun possède des forks d’AOSP et doit intégrer des correctifs de sécurité. Il existe un processus de divulgation de 30 jours pour les niveaux de correctifs afin de leur donner suffisamment de temps pour les gérer et passer par les tests/certifications.
Les opérateurs exigent de longs tests/certifications et ont des règles sur le délai d'expédition des modifications. En premier lieu, ils n’aiment pas les mises à jour. Ils considèrent qu’il s’agit d’un risque énorme et sont peu préoccupés par le fait de laisser les failles de sécurité non corrigées.
Google pourrait envoyer très rapidement des mises à jour des problèmes tels que le correctif WebP pour ses smartphones Pixels, s'ils n'avaient pas les mains liées par les opérateurs et leurs propres processus internes. Ils devraient pouvoir obtenir un correctif critique expédié dans un délai maximum de 72 heures au lieu de 3 à 4 semaines, mais c'est comme ça.
Ce n'est pas vraiment un problème technique et ce n'est donc pas vraiment quelque chose que leurs ingénieurs peuvent résoudre. Ils peuvent faire pression pour que les processus deviennent plus rapides, mais cela implique de négocier de meilleurs accords avec les opérateurs, car ils ne commercialisent pas d'appareil sans le soutien officiel des opérateurs.
Vivien GUEANT : Merci pour toutes les explications. Je comprends mieux. Même si en comparaison, on constate qu'Apple a été très réactif (correction du 6 septembre), mais ils ont probablement moins de contraintes. CVE-2023-41064 et CVE-2023-4863 feraient référence à la même faille WebP.
GrapheneOS : On peut voir que sur Chrome ils l'ont géré rapidement, mais ils ont des retards artificiels majeurs sur Android causés par les processus de publication/test/certification qui n'ont pas d'impact sur Chrome. Il convient de noter qu'Apple prend souvent beaucoup plus de temps pour résoudre un problème, mais ils n'ont pas ces contraintes.
-
Donc mise à jour retardée par le processus de vérification, très lourd parce qu'il faut vérifier avec tous les partenaires qui commercialisent Androïd, souvent avec une surcouche, sur leurs smartphones.
Déjà que sur beaucoup de modèles Androïd, la durée de support est faible...
Bon, Pegasus sur Androïd peut encore profiter de la faille pendant plusieurs semaines (voire plus si plus sous support).
-
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 :
(https://lafibre.info/images/format/202310_webp_explication_grapheneos_2.webp)
-
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 ?
(https://lafibre.info/images/format/202309_webp_maj_ubuntu.webp)
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).
(https://lafibre.info/images/format/202310_webp_maj_android_anglais.webp)
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 ?
-
Je continue de mettre ici ces échanges, car sinon, uniquement sur X, on va les perdre :
(https://lafibre.info/images/format/202310_webp_explication_grapheneos_3.webp)
-
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.
(https://lafibre.info/testdebit/android/202310_google_android14_maj_securite.webp)
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.
-
(https://lafibre.info/images/format/202310_webp_explication_grapheneos_4.webp)
-
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 (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.
-
(https://lafibre.info/images/format/202310_webp_explication_grapheneos_5.webp)
(https://lafibre.info/images/format/202310_webp_explication_grapheneos_6.webp)
-
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.
-
7 septembre 2023 mise à jour iOS pour corriger la faille WebP CVE-2023-4863 :
Mise à jour Apple iOS 16 :
(https://lafibre.info/images/format/202309_webp_maj_apple_ios16.webp)
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.
(https://lafibre.info/testdebit/android/202311_google_android14_maj_securite.webp)
-
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 !
(https://lafibre.info/images/ssl/202210_vitesse_et_ampleur_de_la_banalisation_des_vulnerabilites.webp)
-
Selon Amnesty International, le smartphone du journaliste Indien Siddharth Varadarajan, le fondateur du média The Wire (https://thewire.in/), 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 (https://next.ink/121588/des-journalistes-cibles-par-lutilisation-de-pegasus-en-inde/), écrit par Martin Clavey le 29 décembre 2023.