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.
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.
Commentaires (7)
#1
Comme d’habitude, GP0 a fait du beau boulot dans son analyse. Il est vraiment dommage qu’Apple soit toujours aussi silencieux à la fois dans le bon (les améliorations comme ici) comme le mauvais (les vulns et leur rémédiation).
#1.1
Ce qui est intéressant est le temps que Google prends pour faire du reverse engineering sur les produit concurrent ….
Ou est la limite entre recherche de faille pour les signaler, recherche de surface d’attaque pour profiler les utilisateur et espionnage industriel (décompilation …) ?
#1.2
La décompilation n’est pas un espionnage industriel ? Comme tout produit, une fois celui-ci acquis (un produit du commerce ou un logiciel installé par exemple), il peut être décortiqué (et crois-moi, quelle que soit l’industrie, c’est fait ! ne serait-ce que pour vérifier une éventuelle violation de brevet)
L’espionnage industriel, c’est j’envoie un de mes gars chez l’entreprise concurrente et pour qu’il vole les données à la source
#2
Oui, la question peut se poser. Mais ils pourraient aussi le faire dans l’ombre sans jamais rien publier.
#2.1
Ils pourraient, mais le faire ouvertement sous couverture “white hat”, c’est mieux.
Du coup, quelle est la séparation réelle entre les équipes “Project Zero” et le reste de Google ?
Le terme n’est peut-être pas le bon, mais la question est réelle. Dans tout les CLUF que j’ai pu lire, la décompilation est interdite. Et je n’irais pas jusqu’à parler de DCMA
#3
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.
C’est marrant au boulot cette semaine j’ai un eu un utilisateur qui a perdu son code iPhone et après reset de l’iphone, impossible de resynchroniser certain services (messages, trousseau de mot de passe) car l’iphone demandait de “saisir l’ancien code”. Du coup il a perdu ses messages.
Après quelques recherches cela semble être à cause du chiffrement de bout à bout sur certains services, notamment messages. Quelqu’un pour éclairer ma lanterne ?
#4
Idem pour mes parents… perte de tous les messages, car les messages n’avait justement pas été stockés sur iCloud.
Car l’enregistrement sur iCloud est une fonctionnalité non activée par défaut (de fait non obligatoire !), et de plus non disponible sur l’utilisateur ne met pas de code sur son tél.