L’histoire d’une ligne de code qui pouvait transformer un iPhone en brique

• Présentation d’un cas où il était possible de rendre un iPhone inutilisable en exploitant les caractéristiques et les faiblesses du système Darwin Notification
• Cette vulnérabilité a été enregistrée sous la référence CVE-2025-24091, et son auteur a reçu une prime de bug bounty de 17 500 $ (25 millions de wons)
• En abusant du fait qu’il était possible d’envoyer des notifications de niveau système sans privilèges particuliers, il était possible de paralyser l’ensemble d’un appareil iOS
• Il a été confirmé qu’une simple ligne de code pouvait forcer le mode « Restore in Progress », provoquant des redémarrages en boucle dans le cadre d’une attaque par déni de service (DoS)
• La vulnérabilité a été corrigée via la mise à jour iOS 18.3, qui impose désormais une autorisation restreinte (entitlement) pour l’envoi de notifications Darwin critiques

---

Darwin Notifications

• Les Darwin Notifications sont un mécanisme de niveau CoreOS permettant l’échange de messages simples entre processus sur iOS et macOS
• La structure permet de signaler un événement avec notify_post, de recevoir un événement avec notify_register_dispatch, et de lire ou écrire une valeur d’état (state)
• L’envoi et la réception sont possibles sans privilèges particuliers, et aucune procédure de vérification de sécurité n’existe
• Divers composants du système dépendaient de cette API legacy

Aperçu de la vulnérabilité

• Tous les processus des systèmes d’exploitation d’Apple peuvent recevoir des Darwin Notifications, sans nécessiter de privilèges particuliers
• Il existait une faille structurelle permettant même à des apps sandboxées d’envoyer des Darwin Notifications
• Comme le volume de données transférables est limité, le risque de fuite de données sensibles restait faible
• En envoyant certaines notifications système critiques (par ex. une notification de début de restauration), il était possible d’affecter l’ensemble du système
• Cela a permis d’identifier une possibilité d’attaque par déni de service (DoS)

EvilNotify et VeryEvilNotify

• L’app EvilNotify permettait de forcer différentes réactions du système
  • Affichage de l’icône de détection de liquide
  • Désactivation du Wi‑Fi et bascule forcée sur le cellulaire
  • Blocage des gestes de l’écran de verrouillage et du centre de contrôle
  • Passage en mode perdu de Find My, etc.
• En particulier, une seule ligne, notify_post("com.apple.MobileSync.BackupAgent.RestoreStarted"), suffisait pour faire basculer l’appareil dans l’état Restore in Progress
• Comme l’appareil n’était pas réellement en cours de restauration, ce mode échouait, et la seule solution consistait à appuyer sur le bouton « redémarrer »
• L’app VeryEvilNotify utilisait une extension de widget pour permettre à l’attaque de redémarrer automatiquement même après un reboot
• L’extension de widget était exécutée périodiquement en arrière-plan par le système et appelait la fonction notify_post pour retrigger en boucle le mode « restauration en cours »
• Au final, cela pouvait produire l’effet d’un appareil complètement briqué

Chronologie et enregistrement CVE

• 26 juin 2024 : soumission d’un rapport d’incident initial à Apple
• 27 septembre 2024 : réception d’un message d’Apple indiquant qu’une mesure de mitigation était en cours
• 28 janvier 2025 : résolution complète du problème et confirmation de l’éligibilité à la prime de bug bounty
• 11 mars 2025 : enregistrement officiel sous CVE-2025-24091 et correction dans iOS/iPadOS 18.3
• Le montant de la bug bounty versé s’élevait à 17 500 dollars US

Réponse et mesures de mitigation

• L’envoi de Darwin Notifications sensibles a été modifié pour exiger une autorisation restreinte (entitlement)
• Par exemple, la notification com.apple.MobileBackup.BackupAgent.RestoreStarted a été renommée en com.apple.private.restrict-post.MobileBackup.BackupAgent.RestoreStarted
• Les processus qui reçoivent ces notifications utilisent eux aussi ce nouveau nom afin de bloquer les envois non autorisés par des apps tierces
• Ce système d’autorisations restreintes a commencé à être déployé à partir de iOS 18.2 beta 2, puis a été finalisé dans iOS 18.3

[GN⁺]

Avis sur Hacker News

• Il est intéressant que cette API n’exige pas d’autorisation pour tous les usages liés aux réglages et à la publication de notifications

  • Il existe un moyen de partager des informations 64 bits entre processus sur l’appareil
  • C’est une fonctionnalité idéale pour le suivi des utilisateurs entre applications
  • Si le système stocke la valeur sans suivre de quelle application elle provient, cela permet un stockage persistant même après la suppression et la réinstallation d’une app
  • Cela peut être utilisé pour contourner la réinitialisation de l’IDFA ou de l’IDFV

• La vulnérabilité décrite ne transforme pas l’appareil en « brique »

  • Une restauration tethered est nécessaire pour la récupération

• 17 500 $ est une somme plutôt correcte

  • Les billets de blog parlent souvent de montants faibles, ou de cas où l’entreprise corrige la vulnérabilité sans verser de récompense
  • Apple s’est amélioré sur ce point depuis 2019

• Excellent travail

  • C’est une vulnérabilité simple, efficace et puissante
  • Cela rappelle la vulnérabilité serveur parfaite que j’avais théorisée avec un ami d’université il y a 20 ans
  • Elle a été découverte il y a 2 ans sous la référence CVE-2022-23093

• J’imagine à quel point la journée a dû être difficile au bureau quand l’équipe centrale d’iOS a examiné cela

• Une seule ligne de code pouvait faire entrer l’appareil en mode « récupération en cours »

  • N’importe quel processus pouvait envoyer une notification et tromper le système pour lui faire croire qu’il était dans ce mode

• L’époque de l’IRC me manque

  • Cela rappelle à quel point un petit changement peut être dangereux pour une technologie
  • Je me demande si la sécurité est en train de prendre de l’avance, ou si elle continue simplement à colmater les fuites

• Cela laisse entendre que si une app tierce dispose de son propre système de notifications, elle pourrait être imitée de manière similaire

  • Cela ne permettrait probablement pas de transformer l’appareil en brique, mais pourrait déclencher d’autres comportements

• La priorité peut sembler faible, puisque l’utilisateur doit installer activement une app malveillante

  • Cependant, ce calendrier n’inspire pas confiance

• Cet article était une lecture remarquable

  • Il montre à quel point une très vieille API pouvait être puissante
  • C’était une belle démo capable de déclencher tous les états bas niveau d’iOS
  • Je me demande ce qu’est devenu notify_post aujourd’hui