Des chercheurs du Georgia Institute of Technology, de l'Université du Michigan et de l'Université de la Ruhr ont développé la technique d'attaque iLeakage, qui permet d'exploiter une vulnérabilité des processeurs ARM Apple des séries A et M en ouvrant une page spécialement conçue dans le navigateur. Les prototypes d'exploits préparés par les chercheurs permettent, lors de l'exécution de code JavaScript dans un navigateur, de connaître le contenu de sites ouverts dans d'autres onglets. Ils ont par exemple démontré la possibilité de déterminer le texte d'une lettre ouverte dans un onglet Gmail, de visualiser YouTube historique, et récupérez le mot de passe inséré par le gestionnaire de mots de passe LastPass dans le formulaire de connexion Instagram. L'attaque est applicable au navigateur Safari sur les systèmes équipés de macOS et à tous les navigateurs de la plateforme iOS (les règles d'Apple exigent que tous les navigateurs iOS utilisent uniquement le moteur système WebKit, commun à Safari).
Bien que l’attaque ne s’applique qu’aux produits Apple, elle offre un moyen intéressant de contourner les restrictions de résolution du minuteur dans le moteur WebKit, ce qui pourrait potentiellement être utile pour contourner des restrictions similaires dans d’autres navigateurs. La vulnérabilité identifiée dans les puces Apple M1 et M2 rappelle la vulnérabilité classique Spectre v1 et entraîne également une fuite du contenu de la mémoire lors de l'exécution d'opérations en mode spéculatif, qui, en cas de prédiction incorrecte, sont rejetées par le processeur, mais les traces de leur exécution sont déposées dans le cache du processeur.
Dans cette méthode d'attaque, l'exécution spéculative a permis de créer une primitive de lecture de pointeurs arbitraires de 64 bits dans l'espace d'adressage du processus chargé de restituer le contenu des pages du navigateur. Pour accéder à l'espace d'adressage du processus dans lequel le site de quelqu'un d'autre est rendu, une astuce a été utilisée pour ouvrir la page étrangère en cours d'examen dans une fenêtre contextuelle à l'aide de la méthode JavaScript window.open(). Dans ce cas, le site n’a pas été ouvert dans le cadre d’un processus distinct, mais dans le même processus avec le code de l’attaquant.
Par mesure de sécurité, le moteur WebKit permet uniquement à JavaScript de fonctionner avec des pointeurs 35 bits compressés. Pour donner accès à l'ensemble de l'espace d'adressage du processus et contourner la limite de 35 bits, les chercheurs ont utilisé la technique de confusion de types pour forcer le moteur JavaScript à traiter un objet avec un type incorrect. Lors du traitement d'un objet JavaScript spécialement conçu dans le moteur, des conditions sont créées qui conduisent à l'exécution spéculative des instructions qui accèdent au tableau.
Étant donné que le type de l'objet ne correspond pas au type du tableau en cours de traitement, dans des conditions normales, de telles actions sont bloquées, de sorte que le code de l'attaque Type Confusion est placé dans un bloc conditionnel « if », qui n'est pas activé dans des conditions normales. , mais est exécuté en mode spéculatif si le processeur prédit de manière incorrecte des branchements supplémentaires. En conséquence, le processeur accède de manière spéculative au pointeur 64 bits généré, mais annule l'état après avoir déterminé une prédiction infructueuse. Dans ce cas, des traces d'exécution spéculative sont déposées dans le cache partagé et peuvent être restaurées à l'aide de méthodes de détermination du contenu du cache via des canaux secondaires.
Pour extraire les données du cache CPU L1 restant après des opérations spéculatives, l'attaque utilise une modification de la méthode pLRU (pseudo Least Récemment Utilisé) proposée précédemment par Google. Dans ce cas, la méthode pLRU originale est basée sur la mesure des délais d'accès aux données, dont la différence permet de juger si une certaine séquence est ou non dans le cache du processeur (si les données sont mises en cache, l'opération est effectuée plus rapidement, et sinon, plus lentement). Pour se protéger contre la détection du cache du processeur dans les navigateurs modernes, la précision du minuteur est considérablement réduite à un niveau qui ne permet pas de détecter les différences.
Pour surmonter la limitation de précision du timer lors de l'attaque iLeakage, une technique est proposée pour déterminer la présence ou l'absence de données dans le cache à l'aide d'une condition de concurrence. L'essence de la méthode est de lancer simultanément deux threads - le principal et le de référence. Un thread de référence comprend une séquence d'instructions exécutées à un instant de référence spécifique. Au tout début de l'exécution du thread de référence, une variable partagée avec le thread principal est mise à 1, et une fois les instructions exécutées, la variable est remise à zéro. Ainsi, une variable partagée ne prend la valeur 1 que pendant un certain temps.
Le thread principal lance un cycle de détermination des données dans le cache à l'aide de la méthode pLRU. Un signe de la présence ou de l'absence de données vérifiées dans le cache n'est pas la mesure du temps par le minuteur, mais l'état de la variable commune après vérification. Si la variable a la valeur 1, alors l'opération s'est terminée plus rapidement que le code de référence n'a été exécuté dans un thread parallèle, c'est-à-dire les données ont été servies à partir du cache. Si la variable contient la valeur 0, alors l'opération a pris un temps relativement long en raison du manque de données dans le cache et le code de référence dans le thread parallèle a eu le temps d'être entièrement traité.
La précision de la méthode proposée pour déterminer le contenu du cache varie de 90 % à 99 % et les performances de détermination des données sont de 23 à 34 octets par seconde, selon le processeur et l'appareil. Avant de procéder à l'attaque, une calibration du code de référence est nécessaire, ce qui prend environ cinq minutes. Une fois l'étalonnage terminé pour le système actuel, il faut environ 64 secondes pour extraire une chaîne de 30 caractères.
De plus, on peut noter la publication d'un prototype d'exploit qui utilise la vulnérabilité Zenbleed dans les processeurs AMD basés sur la microarchitecture Zen2 pour extraire les données traitées dans d'autres processus lors de l'ouverture d'une page avec l'exploit dans Chrome. Outre la vulnérabilité Zenbleed (CVE-2023-20593), l'exploit implique également la vulnérabilité CVE-2023-3079 dans le moteur V8, corrigée dans Chrome 115.
Source: opennet.ru