Dans notre article hier, nous avons vu comment Facebook pestait contre l’arrivée prochaine de l’ATT sur iOS 14, qui forcera les applications à demander l’autorisation pour accéder à l’identifiant unique publicitaire (IDFA).

Mark Zuckerberg, durant la présentation des derniers résultats trimestriels de son entreprise, s’en est notamment pris à iMessage, dont les sauvegardes sur iCloud ne sont pas protégées par le chiffrement de bout en bout.

• Apple : l’App Tracking Transparency actif au début du printemps, Mark Zuckerberg en colère

Et voilà que Google, relativement silencieux sur la thématique de la publicité et même « bon élève » en implémentant la solution d’Apple, décide justement de publier un article sur iMessage. Via son Project Zero, on en apprend davantage sur le sérieux renforcement de la sécurité avec iOS 14.

Selon Google, un pirate cherchera idéalement à obtenir une corruption de mémoire ne requérant aucune interaction de l’utilisateur. Il faut alors au minimum les éléments suivants : une vulnérabilité, une manière de casser l’ASLR à distance, un moyen de transformer la vulnérabilité en exécution distante de code et une méthode pour s’échapper de la sandbox.

L’article explique qu’avec iOS 14, Apple a largement remanié le fonctionnement d’iMessage et a introduit un service pour en renforcer la sécurité, BlastDoor. Il s’agit d’une nouvelle sandbox, beaucoup plus stricte, écrite en Swift (langage memory safe) et responsable de l’analyse des données provenant de sources non sûres, par exemple NSKeyedArchiver.

Google ajoute qu’Apple s’est également débarrassé d’une ancienne faiblesse de son implémentation d’ASLR : le cache partagé, ce qui permettait une attaque spécifique sur cette région. iOS 14 détecte ce type d’attaque et, le cas échéant, lance une nouvelle randomisation du cache.

En outre, le service BlastDoor rend les tentatives de casser d’ASLR par force brute plus complexes. Un mécanisme d’étranglement (throttling) exponentiel a été mis en place, géré par launchd. Si l’attaque provoque un plantage du processus, BlastDoor double à chaque fois le temps d’attente avant qu'une nouvelle tentative puisse être faite, jusqu’à un maximum de 20 min (a priori). L’attaque aurait ainsi besoin d’une demi-journée pour réussir sur ce point, là où il fallait auparavant quelques minutes.

Le papier, très technique, se conclut sur une note évidemment très positive, Google félicitant Apple pour les mesures proactives faites sur iMessage, la société ne s’étant pas contentée de corriger quelques bugs.

Mark Zuckerberg pourrait toujours faire valoir que cela ne résout en rien le problème des sauvegardes non chiffrées de bout en bout sur iCloud. Mais cela ne résout en rien non plus le problème des communications non chiffrées de bout en bout de Messenger.