L’attaque Retbleed en termes simples | Blog officiel de Kaspersky

Les chercheurs de l’École polytechnique fédérale de Zurich ont publié mi-juillet une étude qui décrit une nouvelle attaque qui exploite les vulnérabilités (autrement dit, les fonctionnalités) des processeurs modernes. L’attaque a été nommée Retbleed, en référence à Retpoline, une méthode de protection contre un type précis d’attaque Spectre. Les auteurs ont essentiellement montré que cette technique de compilation de programmes, que l’on considérait comme une solution de protection efficace contre les attaques Spectre de type 2, ne fonctionne qu’occasionnellement ou pas du tout. Cette recherche, tout comme les autres études sur les vulnérabilités du hardware dans les processeurs, est assez complexe. Dans cet article, nous n’allons pas entrer dans les détails techniques de cette étude scientifique mais plutôt décrire les résultats en utilisant des termes simples. Commençons avec quelques informations générales pour mieux comprendre le contexte.

Qu’est-ce que Spectre v2 ? Parlons de la prédiction de branchement

Il y a plus de quatre ans, début 2018, deux études ont décrit les vulnérabilités Spectre et Meltdown. Ce sont des vulnérabilités matérielles : les données pourraient être volées lors d’une attaque à cause de la façon dont les processeurs fonctionnent. Dès lors, plusieurs variantes de Spectre ont été découvertes. Les chercheurs ont trouvé d’autres techniques qui permettent d’attaquer une classe courante de vulnérabilités. L’une d’elles consiste à utiliser la fonctionnalité par défaut du processeur, la « prédiction de branchement », pour réaliser l’attaque.

La prédiction de branchement et l’exécution spéculative des instructions aident à améliorer les performances du processeur de façon significative. Dans n’importe quel programme, l’exécution d’autres étapes dépend du résultat des calculs précédents. L’exemple le plus simple est celui de l’utilisateur qui saisit un mot de passe pour accéder à des données confidentielles. Si le mot de passe est correct, l’utilisateur peut voir les données. Si le mot de passe est incorrect, l’utilisateur doit réessayer. En termes d’instructions simples pour le processeur, cela se traduit par une vérification des droits d’accès à certaines données dans la RAM. Si les droits nécessaires sont confirmés, l’accès est autorisé ; si non, il est refusé.

Le processeur peut réaliser des milliards d’opérations par seconde, et il est souvent inoccupé pendant qu’il vérifie une condition, c’est-à-dire quand il attend que l’utilisateur saisisse un mot de passe ou que les droits d’accès soient vérifiés. Et s’il utilisait ce temps mort pour calculer en avance ce qui pourrait se passer à partir du résultat le plus probable ? Au moment où notre hypothétique utilisateur saisit son éventuel mot de passe, le résultat du calcul est déjà prêt et l’utilisateur accède plus rapidement à ses données confidentielles.

Comment savoir quelle partie du code a plus de probabilité d’être exécutée ? Grâce aux statistiques d’exécutions précédentes d’instructions similaires, évidemment. Voici un exemple purement théorique et extrêmement simplifié. Si l’utilisateur saisit le bon mot de passe neuf fois sur dix, le système peut préparer les données confidentielles en avance. Si le mot de passe est incorrect, il n’a qu’à oublier les résultats et mettre un peu plus de temps à afficher le message d’erreur.

Les auteurs de cette étude de 2018 ont décrit deux variantes des attaques Spectre. La variante 2, aussi connue comme injection cible de branche, entraîne le prédicteur de branchement pour qu’il réalise les instructions nécessaires, comme en lisant les données auxquelles le cybercriminel ne devrait pas avoir accès. Oui, ces calculs sont ensuite éliminés, mais le résultat (un renseignement extrêmement sensible) est temporairement stocké dans la mémoire-cache, d’où il peut être volé.

Cette attaque est extrêmement complexe. Tout d’abord, le cybercriminel doit pouvoir exécuter un code dans le système pris pour cible, bien qu’il n’ait pas les privilèges désirés, c’est-à-dire sans avoir accès aux données sensibles. Par exemple, l’utilisateur pourrait ouvrir dans son navigateur un site Internet qui contient un script malveillant. Ensuite, le cybercriminel a besoin de programmes sur le système pris pour cible, dont un code qui convient à l’attaque. C’est ce que les chercheurs appellent un « gadget ». Le code de l’attaque entraîne le système de prédiction de branchement à exécuter ce gadget de façon spéculative. Cela lui permet d’accéder à un espace de la mémoire auquel l’escroc n’a pas accès. Les données confidentielles sont placées dans la mémoire-cache du processeur d’où elles peuvent lentement être extraites, pas plus d’une dizaine de bits par seconde, en lisant le canal secondaire.

Essayons de tout expliquer simplement. Le système de prédiction de branchement du processeur ne sépare pas les instructions des différents programmes, et un même programme peut être utilisé pour que le processeur exécute de façon spéculative une instruction qu’il n’est pas censé exécuter. Cela n’est pas vraiment un problème puisqu’un programme ne peut pas directement accéder aux données de la mémoire-cache du processeur. La situation est différente maintenant que l’on sait que les données peuvent être extraites en lisant les canaux secondaires. Ce mécanisme est très complexe puisqu’il faut reconstruire les données à partir des informations obtenues après avoir analysé la rapidité des réponses aux demandes de lecture.

Attendez. Spectre a été découvert en 2018. Ce problème a sûrement été résolu, n’est-ce pas ?

Les choses ne sont pas si simples lorsqu’il s’agit de vulnérabilités du hardware. Tout d’abord, même à partir de cette description simplifiée, il est évident qu’une vulnérabilité, bien que définitivement basée sur le hardware, a besoin que le programme remplisse certaines conditions pour être exploitée. Si c’est le cas, pourquoi ne pas simplement corriger le programme ? C’est beaucoup plus facile à faire que de mettre à jour le hardware. La vulnérabilité du processeur peut aussi être partiellement corrigée grâce à des mises à jour du microcode. La sortie d’un nouveau processeur avec un hardware modifié est la seule solution définitive au problème. En attendant, les anciens modèles restent complètement ou partiellement vulnérables.

Un autre aspect est crucial lorsque nous étudions le contexte de cette étude sur Retbleed. Quel serait le coût d’un correctif pour un programme ou pour un hardware ? Chaque méthode unique de « clôture » de Spectre réduit les performances. Par exemple, le système assez évident de spéculation indirecte restreinte de branchement (IBRS) introduit des contrôles d’autorisation supplémentaires pendant l’exécution spéculative du code et empêche les programmes à faibles privilèges d’accéder aux données sensibles, ce qui rend impossible une attaque Spectre. Pourtant, les performances du processeur vont indéniablement baisser à cause de ces centaines de milliers ou de millions de vérifications. À quel point ? Une étude montre qu’un ensemble de correctifs différents pour Spectre dans le système réduit jusqu’à 25 % les performances.

C’est là que Retpoline entre en jeu. Il s’agit d’une méthode de protection assez simple contre Spectre proposée par les ingénieurs de Google et utilisée lors de la compilation de programmes. Comme les créateurs de cette méthode le suggèrent, la substitution de certaines instructions dans les situations typiques de branchement par d’autres n’affecte pas l’opérabilité du programme, alors qu’une attaque Spectre n’est plus possible. Le principal atout de Retpoline par rapport au système IBRS et à d’autres méthodes de protection est que les performances ne baissent que légèrement, pas plus de 5 %.

Qu’est-ce que l’étude sur Retbleed nous apprend ?

Sommairement, cette nouvelle étude a démontré que Retpoline… ne fonctionne pas ! Les instructions de retour sur lesquelles la méthode Retpoline repose pouvaient aussi être exploitées grâce à une méthode légèrement différente afin de tromper (ou d’entraîner de façon malveillante) le prédicteur de branchement. Les auteurs ont même enregistré une vidéo pour justifier l’attaque :

Démo d’une attaque Retbleed sur un système Linux.

La vidéo montre comment un programme arrive à voler un mot de passe super-utilisateur haché alors qu’il n’a pas accès à ces données. Il convient de souligner que la vidéo est très accélérée : en temps réel, il faut compter au moins 1h30 pour voler le mot de passe d’un système Intel ! Les résultats sont résumés dans le tableau ci-dessous :

Comme le tableau le montre, les processeurs AMD Zen 1 et Zen 2 (2017–2019) et Kaby Lake et Coffee Lake d’Intel (2016–2017), pas totalement nouveaux mais assez récents, sont susceptibles d’être victimes d’une attaque Retbleed. En revanche, une attaque Retbleed ne fonctionne pas sur les processeurs encore plus modernes AMD Zen 3, Alder Lake d’Intel et la 9º génération précédente. Cela est également dû à la mise en place de la protection améliorée IBRS du hardware dans les processeurs Intel.

Le coût de la protection

S’il est si difficile de lancer une attaque Spectre, pourquoi s’en protéger ? En effet, pour adapter Spectre à une situation réelle, et avec de vrais dégâts pour la victime, beaucoup de conditions doivent être remplies : pouvoir exécuter le code sur le système attaqué, avoir un logiciel susceptible d’aider l’attaque, et obtenir correctement les données de la mémoire-cache (avec un risque d’erreur de lecture). Nous avons antérieurement dit que l’attaque la plus réaliste avait été simulée dans un navigateur Chrome et qu’un cybercriminel pourrait, par exemple, extraire les mots de passe sauvegardés dans la RAM. Ce problème a été résolu avec une simple amélioration de la protection interne du navigateur, comme lorsqu’un bug normal est corrigé.

Il est possible que les progrès réguliers accomplis dans la recherche de vulnérabilités similaires à Spectre donnent un jour lieu à une éventuelle attaque de masse sur les ordinateurs et les serveurs des utilisateurs. En revanche, Spectre doit être pris en compte dès maintenant s’il s’agit de données particulièrement sensibles.

Le scénario le plus évident est celui d’une attaque via l’hébergement et une distribution par les fournisseurs de services. Le serveur virtuel de base que vous pouvez louer pour un montant raisonnable à un fournisseur quelconque est en réalité un programme qui s’exécute à côté d’autres systèmes d’exploitation virtuels des clients sur un même serveur haute performance. L’abonné d’un serveur virtuel peut, par définition, y exécuter des programmes mais n’a pas les privilèges qui permettent d’accéder aux alentours ou à l’hôte, autrement dit ce qui contrôle le système d’exploitation. L’isolement des environnements virtuels et l’impossibilité de vous échapper de votre espace virtuel sont un élément de sécurité important pour les fournisseurs de services.

D’autre part, les fournisseurs de services veulent avoir autant de systèmes virtuels qui s’exécutent sur le même serveur que possible sans qu’ils n’interfèrent entre eux. C’est la solution au retour sur investissement d’un programme malveillant coûteux dont nous parlions antérieurement. Cela étant dit, les patchs de Spectre qui fonctionnent vraiment réduisent la performance et donc les revenus des fournisseurs de services. Ces derniers ne peuvent pas ignorer ce problème puisque le vol réussi de données sensibles ne laisse aucune trace !

Ainsi, lorsque la solution Retpoline a été proposée, beaucoup s’en sont servis comme bouée de sauvetage pour lutter contre ce nouveau fléau. Pourtant, en janvier 2018, on doutait de l’efficacité de cette méthode de protection. Une conversation dans la liste de diffusion des développeurs du noyau Linux montre plusieurs plaintes concernant Retpoline. D’ailleurs, l’auteur ne se montre pas très favorables aux autres méthodes. D’autre part, Linus Torvalds, le créateur et le principal gardien de Linux, a clairement dit, et de façon assez directe, que la méthode Retpoline est généralement suffisante.

Les auteurs de Retpoline s’appuient sur les dires de Torvalds et sur son jugement en le citant au début du document. Ils ont aussi calculé le « coût » de cette protection réelle pour les processeurs vulnérables qui ne peuvent pas être corrigés au niveau du hardware. Les patchs du noyau Linux ont provoqué une baisse des performances qui s’élève jusqu’à 39 % pour les processeurs Intel et 14 % pour les processeurs AMD.

Les processeurs AMD sont vulnérables à leur façon, et les chercheurs ont découvert un phénomène qu’ils ont nommé « Phantom JMP ». Il s’avère que, sous certaines conditions, un système de prédiction de branchement peut exécuter une instruction arbitraire même si cela n’apparaît pas dans le code lors de l’attaque. C’est à cause de cela que les auteurs ont dû ajouter un court avenant d’une page à l’étude. Ils indiquent toutefois que l’exploitation de cette vulnérabilité pour causer de vrais dégâts est encore plus difficile que celle de la traditionnelle faille Spectre v2.

Et maintenant ?

Pour les utilisateurs ordinaires, la menace d’une attaque Spectre reste entièrement virtuelle. Les patchs préventifs des développeurs des systèmes d’exploitation suffisent. En revanche, Windows a activé une protection IBRS par défaut. Les nouveaux patchs du noyau Linux vont certainement provoquer une baisse des performances, et ce sont surtout les entreprises qui vont le remarquer lorsque le matériel informatique atteint ses limites.

Le problème est qu’il y a beaucoup de variantes de Spectre. On pourrait aussi considérer Retbleed comme une variante à part entière qui fonctionne différemment sur les processeurs des divers fabricants. AMD et Intel ont reconnu Retbleed comme une vulnérabilité séparée et vont certainement apporter une solution informatique. Les entreprises utiliseront les nouveaux hardwares équipés de mesures de protection afin de trouver l’équilibre entre les performances et la sécurité. Malheureusement, tous les patchs de logiciels sont ceux qui pèsent le plus sur les performances des processeurs relativement anciens. Non seulement le logiciel est de plus en plus exigeant au fil du temps, mais en plus il y a cette « sanction » sur l’exécution spéculative.

À vol d’oiseau, ce problème n’a rien de nouveau. Les développeurs proposent une solution qui améliore la performance sans penser à la sécurité. Tôt ou tard (tard dans ce cas-là puisque l’exécution spéculative est apparue au milieu des années 90), ce problème revient et nous hante tous. Les mesures de sécurité ont un coût, mais de nouvelles solutions apparaissent et l’industrie de la haute technologie évolue.

La surprise a été la découverte du problème dans le hardware : plus difficile à corriger que dans le logiciel. Il ne s’agit pas d’un simple bug mais plutôt d’une approche pauvre (en termes de sécurité) que les entreprises ont adoptée plusieurs années auparavant. Espérons que les développeurs de processeurs trouvent de nouvelles méthodes qui garantissent une informatique sûre et puissante avant qu’un événement imprévu, comme l’attaque extrêmement dangereuse d’un hardware, ne nous affecte. Un incident qui nous menace tous, qui est très connu et qui ne peut être résolu qu’en remplaçant complètement le hardware.