Apple corrige un bug utilisé par la police pour extraire des messages de chat supprimés sur iPhone

• Des messages supprimés ou éphémères dans des applications de messagerie pouvaient rester dans le cache des notifications et être lus avec des outils de forensic, et Apple a corrigé cela via une mise à jour logicielle pour iPhone et iPad
• Les notifications affichant le contenu des messages pouvaient être conservées sur l’appareil pendant jusqu’à un mois, et l’avis de sécurité d’Apple indique que des notifications marquées pour suppression pouvaient être conservées de manière inattendue
• Cette voie d’extraction est liée à la manière dont des messages Signal supprimés restaient dans la base de données du téléphone, permettant aux forces de l’ordre de lire des messages supprimés depuis longtemps
• Signal a demandé à Apple de corriger le problème après sa révélation, et la fonction de minuteur d’autodestruction peut aider les utilisateurs qui veulent garder leurs conversations secrètes même en cas de saisie de l’appareil
• Une suppression dans l’application seule ne faisait pas forcément disparaître le même contenu du stockage des notifications au niveau du système d’exploitation, et ce correctif montre que la couche OS compte aussi pour la protection de la vie privée des messages à suppression automatique

---

Correctif du bug et impact

• Apple a déployé une mise à jour logicielle pour iPhone et iPad afin de corriger un bug qui permettait aux forces de l’ordre d’extraire des messages supprimés ou éphémères depuis des applications de messagerie
  • Le problème venait du fait que les notifications affichant le contenu des messages étaient mises en cache sur l’appareil pendant jusqu’à un mois
• L’avis de sécurité d’Apple indique que des notifications marquées pour suppression pouvaient être conservées de manière inattendue sur l’appareil
• On ne sait pas avec certitude pourquoi le contenu des notifications était enregistré dès le départ
  • Ce correctif révèle que ce comportement était bien un bug
• Apple n’a pas répondu immédiatement aux questions sur la raison de cette conservation
• Apple a aussi rétroporté le correctif sur des iPhone et iPad exécutant des versions plus anciennes d’iOS 18

La voie d’extraction mise au jour

• Ce correctif est directement lié à un problème révélé plus tôt ce mois-ci par 404 Media
  • Le FBI pouvait utiliser des outils de forensic pour extraire des messages Signal supprimés depuis l’iPhone d’une personne
• Cette extraction était possible parce que le contenu des messages, après avoir été affiché un temps dans une notification, restait stocké dans la base de données du téléphone même après la suppression du message dans Signal
• Lors de l’utilisation d’outils de forensic, les forces de l’ordre pouvaient lire des messages supprimés depuis longtemps

Signal et la fonction de suppression des messages

• Meredith Whittaker, de Signal, a indiqué avoir demandé à Apple de corriger le problème après sa révélation
  • Elle a écrit que les notifications liées à des messages supprimés ne devraient rester dans la base de données des notifications d’aucun système d’exploitation
• Comme WhatsApp et d’autres applications de messagerie, Signal propose une fonction de minuterie qui supprime automatiquement les messages après un certain délai
• Cette fonction peut aider les utilisateurs qui veulent garder leurs conversations secrètes même si les autorités saisissent leur appareil

Inquiétudes sur la vie privée

• La révélation selon laquelle le FBI avait trouvé un moyen de contourner une fonction de sécurité utilisée au quotidien a renforcé l’inquiétude des défenseurs de la vie privée
• La fonction de suppression automatique des messages est notamment un outil de sécurité utilisé au quotidien par des utilisateurs exposés à des risques
• Ce bug a montré que supprimer un message dans l’application ne suffisait pas toujours à effacer le même contenu du stockage des notifications au niveau du système d’exploitation

[GN⁺]

Réactions sur Hacker News

• À mon avis, il s’agissait d’un bug laissant un cache sur l’appareil. Cela dit, le fait qu’Apple et Google se trouvent au milieu de la plupart des flux de notifications reste inquiétant en soi, puisque le contenu transite par leurs serveurs. Donc si l’on veut moins exposer des messages chiffrés de bout en bout, le bon réglage me semble être d’afficher seulement nouveau message reçu dans la notification, en masquant le contenu et l’expéditeur
  • Je pense que cette explication est erronée sur deux points. D’abord, ce problème concernait le fait que l’OS conservait localement un historique des notifications, pas un souci avec les serveurs de notification d’Apple ou de Google. Ensuite, même si les notifications passent par les serveurs d’Apple ou de Google, on peut préserver l’E2EE en chiffrant les données elles-mêmes ou en retirant le corps du message. C’est d’ailleurs ainsi que fonctionne Signal : Apple et Google ne voient pas les messages en clair
  • À mon sens, Apple comme Google fournissent tous deux des mécanismes permettant à l’app de modifier un message avant son affichage. Il suffit donc d’envoyer une notification chiffrée, puis de la déchiffrer avec le code de l’app sur l’appareil de l’utilisateur avant l’affichage
  • Oui, je pense que c’est exact. Le serveur n’envoie qu’une notification, puis l’appareil combine localement cela avec les messages réellement lus après déverrouillage pour les afficher, donc il n’est pas nécessaire que du texte en clair passe par les serveurs d’Apple ou de Google
  • D’après la FAQ de Matrix que j’ai lue récemment, cette explication n’est pas exacte. Dans les apps Matrix, seules certaines métadonnées passent du serveur de chat au serveur de push puis par Google jusqu’à mon appareil, tandis que le corps du message reste en E2EE. L’app se réveille grâce à cette notification de métadonnées, récupère ensuite le vrai message, puis l’affiche dans la notification. Comme l’a signalé le dernier commentaire, tant qu’Android n’est pas corrigé, le problème de conservation locale reste présent
  • Dans ce cas précis, j’ai l’impression qu’on utilisait bien les API de notification de l’OS de Google et d’Apple en leur remettant des messages en clair
• À mon avis, le bug évoqué dans l’article ne représente qu’une partie du problème. Le point central, c’est que le texte des notifications est stocké dans une base du téléphone en dehors de Signal, et qu’il faut modifier les paramètres pour l’éviter. Dans ce cas, l’accusé avait supprimé l’app Signal elle-même, et normalement les notifications de cette app auraient aussi dû être marquées comme supprimées en interne ; le correctif semble justement porter sur le fait qu’elles ne l’étaient pas. L’élément essentiel des informations publiées est que des notifications marquées pour suppression pouvaient malgré tout rester sur l’appareil. D’après la description, il s’agirait d’un logging issue, donc il est possible que les données soient restées plutôt dans les journaux que dans la base principale
  • D’après ce que j’ai vu, cela semblait impliquer non seulement les logs, mais aussi les logs, json, plist et SQLite DB. Dans /private/var/mobile/Library/Biome/streams/.../Notification/segments/, il y aurait des journaux bruts des titres et du corps des messages ; dans /var/mobile/Library/{BulletinBoard,UserNotificationsCore}/, des fichiers json et plist indiquant les états de livraison et de fermeture ; et dans /var/mobile/Library/CoreDuet/coreduetdClassD.db, une base SQLite qui réinjecte des événements Biome. La source est ce tweet
  • Pour moi, cette interprétation reste encore de la spéculation. Le fait qu’elles aient été marquées pour suppression peut vouloir dire non seulement après la suppression complète de l’app, mais aussi après qu’un utilisateur a fermé la notification
  • Moi, la possibilité d’un SQLite WAL m’est venue à l’esprit en premier
  • À mes yeux, les deux sont en pratique le même problème. Je me demande pourquoi on voudrait absolument les distinguer
• Je pense que le mode de notification générique proposé par Signal, du type « vous avez reçu un message », est globalement une bonne pratique de sécurité
  • En réalité, c’est possible avec presque toutes les apps. Il suffit de régler shows previews sur never dans les paramètres de notifications d’iOS
• Je trouve assez frustrant que Signal ne communique pas davantage ce problème aux utilisateurs. J’avais désactivé les notifications, et pourtant Signal continuait seulement à me rappeler de les réactiver
• En voyant cela, je me demande à nouveau si, avec Mythos, la plus grande inquiétude est la découverte d’une vulnérabilité ou sa correction
• Au début, j’étais moi aussi un peu confus. Je pensais que les notifications push étaient chiffrées de bout en bout, donc qu’un service de push ne pouvait pas les mettre en cache sous une forme lisible, et que l’app les recevait puis les déchiffrait sur l’appareil. Mais en réalité, il semble que l’app les déchiffre, les affiche à l’utilisateur via une API de l’OS, puis que ce texte de notification soit à nouveau enregistré quelque part localement sur l’appareil, dans une sorte de base d’historique des notifications
  • Oui, c’est aussi à peu près comme ça que je comprends le fonctionnement
  • À mon avis, dans l’architecture push d’Apple et de Google, une bonne partie des métadonnées reste en clair
• Du point de vue de la vie privée, j’ai l’impression que ce problème est connu depuis longtemps. Google et Apple envoient parfois le contenu des notifications à leurs propres serveurs, ce qui permet de contourner la frontière de l’app. On peut aussi citer cet article dans une catégorie similaire
  • Je m’attendrais à ce que Signal pré-chiffre les données de notification avant de les envoyer à Apple, puis les déchiffre sur l’appareil avec une Notification Service Extension. C’est un schéma courant quand on ne veut pas faire confiance à Apple, donc au final le texte en clair aurait été stocké après déchiffrement sur l’appareil, et non chez Apple
  • Dans le cas rapporté ici, je comprends que le contenu n’a pas été récupéré depuis les serveurs, mais directement sur le téléphone par les autorités fédérales
  • Cela me fait aussi penser à des messageries comme Snapchat ou WhatsApp. WhatsApp met en avant l’end-to-end, mais il existe aussi des affirmations selon lesquelles certaines copies de messages seraient remises aux autorités sur la base de mots-clés, ce qui soulève des inquiétudes du même ordre
• L’app ne peut pas demander à iOS de ne pas conserver cette notification après affichage, donc la charge utile est simplement mise en cache. Au final, c’est encore le problème classique du « supprimé ne veut pas vraiment dire supprimé », et les données restent à plus d’endroits qu’on ne le pense. De ce point de vue, Signal a bien mis en lumière un cas très parlant
• Heureusement, Apple a aussi rétroporté ce correctif vers iOS 18
  • Et même au-delà, il est intéressant de voir qu’iOS 18.7.8 semble être distribué sans détour particulier même sur les appareils capables de faire tourner iOS 26. En revanche, comme ce n’était pas le cas de 18.7.3 à .6, je me demande si ces versions intermédiaires étaient censées sortir mais ont connu un problème de distribution que personne n’a corrigé
• Pour ma part, je refuse de m’appuyer sur un système fermé pour la messagerie sécurisée, surtout lorsqu’il s’agit de communiquer avec beaucoup d’interlocuteurs non déterminés
  • Malgré cela, iOS est probablement la plateforme mobile la plus sûre pour la messagerie sécurisée, surtout avec le lock down mode