Spectre v2 : fuite de données via BTR sur Intel, AMD et Arm

Une nouvelle variante de Spectre v2 permet d'extraire des données sensibles de la mémoire sur des systèmes équipés de processeurs Intel, AMD et Arm. Selon les chercheurs, l'attaque fonctionne même sur des machines entièrement à jour avec les paramètres de sécurité par défaut.

Baptisée Branch Target Reuse (BTR), la technique a été mise au point par le groupe VUSec de la Vrije Universiteit Amsterdam, aux Pays-Bas, et par des chercheurs de la Scuola Superiore Sant'Anna, en Italie. Elle cible les compilateurs à la volée (JIT), qu'utilisent les noyaux de systèmes d'exploitation, les navigateurs web et les environnements d'exécution pour générer du code à la demande.

Un attaquant capable d'exécuter du code sur la machine visée pourrait se servir de BTR pour lire le contenu de la mémoire, par exemple des empreintes de mots de passe. Les chercheurs estiment que des attaques depuis des pages web malveillantes sont aussi envisageables, mais ils n'ont pas encore mis au point d'exploit complet pour navigateur.

Des prédictions périmées qui survivent au code

BTR exploite la manière dont les processeurs gèrent le code modifié en cours d'exécution. Les CPU modernes veillent à ce que les instructions réellement présentes en mémoire restent cohérentes lorsque le code se modifie lui-même. Pour le prédicteur de branchement, c'est une autre histoire.

"L'idée clé de l'attaque, c'est que si les CPU modernes rétablissent la cohérence architecturale du code après une automodification, ils n'invalident pas forcément les entrées périmées de prédiction de branchement indirect (c'est-à-dire les cibles de branchement)", expliquent les chercheurs.

Dans un moteur JIT, ces entrées obsolètes peuvent persister après la disparition du code auquel elles correspondaient. Lorsqu'un nouveau code est écrit au même emplacement mémoire, les anciennes prédictions peuvent être réutilisées. Les chercheurs parlent d'une primitive d'exécution spéculative après libération ("speculative execute-after-free"). Elle permet à un attaquant d'orienter l'exécution spéculative vers le nouveau code, à des positions qui n'ont plus aucun sens.

L'équipe a étudié trois cibles : cBPF sous Linux, l'environnement d'exécution GraalVM d'Oracle et SpiderMonkey, le moteur JavaScript et WebAssembly de Firefox.

L'empreinte du mot de passe root extraite du noyau Linux

Deux exploits complets ont été développés contre le noyau Linux, tous deux reposant sur le BPF classique (cBPF). Son successeur, eBPF, est réservé aux utilisateurs privilégiés, mais les programmes sans privilèges peuvent toujours utiliser cBPF. Seccomp, le filtrage de sockets et le filtrage de paquets dans des logiciels comme Docker et Chrome en dépendent encore.

Sur les CPU Intel récents, l'exploit lit n'importe quelle zone mémoire et contourne toutes les protections activées.

"Notre exploit fait fuiter 8 octets par seconde. Cela peut paraître lent, mais en suivant les pointeurs avec soin, il suffit de faire fuiter une petite quantité de données pour atteindre le secret", précisent les chercheurs. Lors d'une démonstration, ils ont localisé puis extrait l'empreinte du mot de passe root une fois celle-ci chargée en mémoire.

Firefox et GraalVM également concernés

Dans Firefox, l'attaque partirait d'un site malveillant exécutant du JavaScript dans le navigateur de la victime. Mozilla n'a pas encore achevé le déploiement de l'isolation des sites, si bien que le contenu d'autres onglets pourrait se trouver dans le même espace d'adressage que le code de l'attaquant.

Une preuve de concept a montré que, sur les puces Intel, les entrées de branchement périmées subsistent dans SpiderMonkey assez longtemps pour être réutilisées. Les chercheurs estiment le débit de fuite à plusieurs dizaines d'octets par seconde, même si un exploit fonctionnel pour navigateur demande encore du travail.

Pour GraalVM, BTR pourrait permettre à un attaquant de sauter de manière spéculative par-dessus le masquage mémoire qui protège contre Spectre le mode bac à sable le plus strict de l'environnement d'exécution. Les chercheurs ont réussi à réutiliser des adresses mémoire de façon fiable, mais la compilation et le ramasse-miettes de GraalVM effaçaient les entrées périmées avant qu'elles puissent être exploitées. Selon eux, cet obstacle "ne semble pas fondamental".

Les fondeurs renvoient vers des correctifs logiciels

Les fabricants de puces et les développeurs de logiciels concernés ont été prévenus et ont pris acte des résultats. Les fournisseurs de CPU ont indiqué que des outils existants comme la barrière de prédiction de branchement indirect (IBPB) permettent de contrer BTR, et que les correctifs relèvent du logiciel.

Les développeurs du noyau Linux ont ajouté une protection x86 qui déclenche une IBPB sur chaque cœur du processeur lorsqu'un programme cBPF est placé dans une zone mémoire déjà utilisée par du code BPF exécuté. Oracle a publié certaines protections. Mozilla, de son côté, donne la priorité à l'achèvement de l'isolation des sites plutôt qu'à des correctifs basés sur l'IBPB.

Les chercheurs ont confirmé ce comportement sur tous les CPU Intel, AMD et Arm qu'ils ont testés. "Aucun CPU actuel ne dispose d'un mécanisme pour garder les deux synchronisés, donc tant que les fabricants n'en ajoutent pas, votre CPU est vulnérable", avertissent-ils.

Les protections matérielles du flux de contrôle, IBT sur x86 et BTI chez Arm, compliquent l'exploitation sans pour autant supprimer le risque. Les anciens CPU Intel peuvent encore exécuter des instructions de manière spéculative avant que la vérification n'ait lieu. Lion Cove est la première génération Intel dans laquelle les chercheurs n'ont pas trouvé cette situation de concurrence. Même là, ils ont contourné IBT lorsque le masquage des constantes ("constant blinding") était désactivé, tout en qualifiant la combinaison d'un IBT sans situation de concurrence et du masquage des constantes de défense bien plus solide.

AMD a déclaré à SecurityWeek que l'étude ne révélait aucune nouvelle vulnérabilité dans ses produits et que les recommandations existantes pour Spectre v2 permettent de contrer la technique. Intel et Arm n'ont pas répondu.

Notre analyse

BTR s'inscrit dans un schéma bien connu : des années après l'apparition de Spectre, les chercheurs continuent de trouver de nouveaux moyens de contourner les protections censées le neutraliser. Le cœur du problème se situe dans le matériel, mais c'est aux développeurs de noyaux, de navigateurs et d'environnements d'exécution qu'il revient de le corriger. On peut donc s'attendre à une réponse inégale, chaque projet évaluant différemment le coût en performances, comme le montre le choix de Mozilla de miser sur l'isolation des sites.

Pour la plupart des lecteurs, la mesure concrète consiste à maintenir à jour les noyaux Linux, les navigateurs et les environnements d'exécution comme GraalVM à mesure que ces protections arrivent. Les hôtes mutualisés sur lesquels des utilisateurs non fiables peuvent charger des filtres cBPF méritent une attention particulière. BTR rejoint aussi d'autres travaux, comme de récentes recherches montrant que les API de notification de fichiers font fuiter l'activité des utilisateurs, pour nous rappeler que le comportement bas niveau des systèmes peut exposer des données de façon inattendue. Reste à voir si un exploit complet pour navigateur fera son apparition, et si les fabricants de CPU finiront par ajouter un mécanisme matériel pour synchroniser les prédicteurs de branchement avec la mémoire.