Vulnérabilités matérielles
> This article has been translated to English here.
Que sont les vulnérabilités matérielles ? Faut-il absolument tenter de les corriger ? Si oui, a-t-on des solutions abordables ?
Cet article a été écrit en collaboration avec Emmanuel Gublin et est à destination d’un public curieux, non spécialiste mais avec une certaine connaissance de base des architectures modernes.
Lecture conseillée au préalable : Modern Microprocessors - A 90-Minute Guide!
Des hypothèses fortes
De nombreux systèmes modernes reposent aujourd’hui sur l’ingéniosité mise dans le logiciel. Les développeurs font appel à des hypothèses fortes sur le matériel pour construire ces systèmes, comme par exemple l’isolation matérielle des processus et des threads (deux processus n’ont pas d’influence l’un sur l’autre), l’isolation électrique de cellules de RAM entre elles (une cellule n’a pas d’influence électrique sur une autre), la MMU interdit d’accéder à une zone mémoire non autorisée, etc.
Ces hypothèses étaient pour la plupart vraies il y a quelques dizaines d’années mais aujourd’hui, après une course à la performance toujours plus acharnée entre les constructeurs de processeurs, certaines d’entre elles ont été invalidées : deux threads peuvent fonctionner sur le même cœur de processeur et donc se partagent des ressources matérielles, les cellules de RAM DDR3 ne sont finalement pas assez isolées et l’exécution spéculative permet au CPU d’accéder à des zones mémoires ou des ressources matérielles avant que l’autorisation n’ait été vérifiée.
Origine des vulnérabilités hardware
Les vulnérabilités présentées en annexe ci-dessous sont présentes soit au niveau purement matériel (Row hammer), soit dans un système embarqué à côté du processeur (Intel Management Engine), soit dans le jeu d’instructions du processeur (Portsmash, Spectre et Meltdown).
Elles sont souvent nées de la recherche de la performance ou du confort : plus de mémoire, gestion à distance, performances globales toujours plus élevées… Par exemple l’exécution spéculative utilisée par Spectre et Meltdown permet d’exécuter en avance des instructions dont on pense que l’exécution sera probable pour gagner du temps si jamais cette prédiction se réalise.
Elles sont particulièrement vicieuses dans le sens où elles sont complètement invisibles des outils de détection classiques qui sont limités au système d’exploitation et ne peuvent pas intervenir à un niveau si profond dans la machine.
Des impacts graves mais difficilement actionnables
Les impacts de ces vulnérabilités sont divers et graves : sortir d’une sandbox, gagner un accès root ou extraire des informations d’un contexte plus privilégié. Par exemple, sur certains systèmes, les privilèges de l’utilisateur sont stockés en RAM à une adresse appartenant au kernel, lui seul est donc en mesure de légitimement modifier cette valeur. Row hammer permet de modifier les bits d’une cellule mémoire quelconque pourvu qu’on sache quelle zone on veut cibler, on peut donc modifier les privilèges d’un utilisateur sans en avoir la permission.
Il faut cependant relativiser ces impacts dans la mesure où la plupart des vulnérabilités matérielles sont très difficiles à exploiter. Il faut souvent un accès direct (pas nécessairement physique) à la machine comme pour Spectre, Meltdown ou Portsmash, ou encore avoir une connaissance extrêmement précise de l’état de la machine en question pour Row hammer qui nécessite de cibler une adresse mémoire précise pour obtenir des résultats intéressants.
Des corrections presque impossibles à grande échelle mais pas forcément nécessaires pour tous
Il n’est pas facile de corriger ces vulnérabilités, la plupart étant dues à des problèmes dans la conception matérielle des composants. Pour se protéger de leur impact, il faudrait dans certains cas non pas appliquer un patch logiciel mais bien remplacer du matériel, ce qui est beaucoup plus coûteux. Dans d’autres cas plus rares un patch logiciel permet de résoudre ou au moins d’atténuer les effets mais au prix de la performance. Ainsi de nombreux acteurs considèrent que leur modèle de menace ne recouvre pas ces vulnérabilités et choisissent de vivre avec.
Néanmoins, tous ne peuvent pas se permettre cette largesse. Des fournisseurs de service type IaaS comme OVH, Amazon, Google, Microsoft ou d’autres ne peuvent pas ignorer les menaces permettant d’extraire des informations d’un contexte privilégié vers un contexte moins privilégié (par exemple de l’hyperviseur vers le système invité).
Ainsi, Portsmash, Spectre, Meltdown et Row hammer sont des menaces directes pour ces entreprises. En effet, ces vulnérabilités pourraient permettre à un attaquant ayant un accès légitime à une machine virtuelle d’accéder à des informations de VMs voisines ou même de s’échapper de la sandbox imposée par l’hyperviseur. Ce sont donc des menaces sérieuses pour ces sociétés ainsi que leurs clients qui pourraient voir des données sensibles s’échapper.
A contrario, un utilisateur lambda n’aura peut-être pas trop à s’inquiéter. Ces attaques sont suffisamment complexes à mettre en place et requièrent des connaissances très précises sur le système cible. Il semble donc peu probable de les voir se déployer à grande échelle pour le moment.
Take away
Comme nous avons pu le découvrir au long de cet article, les vulnérabilités matérielles sont de nature diverses et les chercheurs en sécurité en découvrent de nouvelles régulièrement. Se protéger de leurs effets peut être aussi simple qu’un correctif à déployer mais peut également s’avérer aussi complexe et coûteux que de changer le composant matériel concerné. Tous les acteurs ne sont pas menacés au même niveau : l’utilisateur lambda aura peu d’inquiétude à avoir tandis que les fournisseurs de services type IaaS auront plus de souci à se faire.
Annexe : Cartes d’identité de quelques vulnérabilités matérielles
PortSmash
Type : CPU
Permet : L’extraction de données d’un autre thread
Impact :
- Les architectures Intel Skylake et Kaby Lake ont été impactées dans la preuve de concept des chercheurs mais ils supposent que ça va au-delà et que ça impacte tous les processeurs qui utilisent de l’Hyper Threading, y compris chez AMD.
- Ça serait particulièrement intéressant à exploiter dans une infrastructure type IaaS puisque les ressources sont souvent partagées.
Comment fonctionne une attaque ?
- En mesurant le temps d’attente imposé au thread espion pour accéder à une ressource matérielle. On part de l’hypothèse que ce temps d’attente est imposé par le scheduler du processeur pour que le thread victime puisse lui aussi s’exécuter. On peut apprendre pas mal de choses. Les chercheurs ont réussi à extraire une clé privée SSL lors de leur preuve de concept mais ça pourrait être complètement autre chose.
Fix possible ? Connu ? Il faut désactiver l’hyper threading d’Intel, au prix de lourdes pertes de performance.
Notions : Ressource partagée, Goulot d’étranglement, Timing
Pour aller plus loin :
- https://www.bleepingcomputer.com/news/security/new-portsmash-hyper-threading-cpu-vuln-can-steal-decryption-keys/
- https://thehackernews.com/2018/11/portsmash-intel-vulnerability.html
- https://arstechnica.com/information-technology/2018/11/intel-cpus-fall-to-new-hyperthreading-exploit-that-pilfers-crypto-keys/
- https://eprint.iacr.org/2018/1060.pdf
- https://github.com/bbbrumley/portsmash
Spectre / Meltdown
Type : CPU
Permet :
- Meltdown : lire la mémoire kernel dans un programme utilisateur
- Spectre : fuite d’informations dans l’espace kernel vers l’espace utilisateur mais aussi depuis un hyperviseur vers un système invité
- Spectre pourrait permettre de s’échapper de la virtualisation imposée par un hyperviseur
Impact : Les puces Intel sont touchées par Spectre et Meltdown. Des preuves de concept ont été réalisés pour Spectre sur les puces AMD et ARM mais pas pour Meltdown. Cela dit les chercheurs suspectent que ce serait quand même possible.
Comment une attaque fonctionne ?
- Meltdown : quand on fait certains appels au kernel, la vérification de si on a le droit de les réaliser est effectuée après le début de l’exécution spéculative. En faisant un timing précis, on pourrait déterminer si certaines adresses mémoires sont chargées dans le cache du kernel ou non
- Spectre : se base sur une plus grande classe d’exécutions spéculatives, comme par exemple les branches (if, while, for), puis idem avec un timing précis pour déterminer si certaines adresses sont chargées.
Fix possible ? Connu ?
- Meltdown : Oui c’est fixé normalement. Les OS vérifieront d’abord que le call est autorisé avant de le réaliser. Ça a un coût important pour les programmes effectuant de nombreux appels système (réseau, disque).
- Spectre : Pas de solution évidente. L’exécution spéculative est nécessaire pour atteindre un certain niveau de performances. Les constructeurs vont ou ont rajouté des instructions spécifiques pour attendre que toutes les opérations mémoires soient terminées avant d’en relancer mais il faudrait savoir où les placer et ce n’est pas évident (pas automatisable).
Notions : exécution spéculative, timing
Pour aller plus loin :
- https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/
- https://arstechnica.com/gadgets/2018/11/spectre-meltdown-researchers-unveil-7-more-speculative-execution-attacks/
Vulnérabilités dans l’Intel Management Engine (IME)
Type :
- Soft dans le CPU
- L’Intel Management Engine est un système embarqué dans la plupart des processeurs Intel. Le code est largement obfusqué et le fonctionnement n’est pas documenté. Un chercheur en sécurité affirme que ce système embarqué qui fonctionne sur une puce séparée du processeur principal a un accès direct à la mémoire ainsi qu’à la stack TCP/IP et qu’il peut donc communiquer sur le réseau indépendamment de l’OS de la machine.
- De nombreuses vulnérabilités ont été détectées dans ce système embarqué.
- Ce système est hors de la portée des outils de sécurité habituels qui fonctionnent en tant que services sur l’OS et n’ont pas accès à ce système parallèle qui fonctionne donc indépendamment.
Permet : Exécution de code arbitraire à distance avec accès root.
Impact : Les processeurs Intel des générations 1 à 8 sont impactés, ainsi que plusieurs gammes de processeurs Xeon (serveurs) et certaines familles de processeurs Atom, Pentium et Celeron. On parle donc de la plupart des ordinateurs de bureau, des ordinateurs portables et des serveurs en circulation.
Comment une attaque fonctionne ? On parle ici d’une famille de vulnérabilités dans ce système embarqué, donc différents scénarios d’attaque. La plupart requièrent un accès physique à la machine mais certains permettent une exécution à distance.
Fix possible ? Connu ? Des patchs ont été publiés par Intel et les fabricants de PC
Notions : Système embarqué, Système hors de la portée des outils de sécurité
Pour aller plus loin :
- https://arstechnica.com/information-technology/2017/11/intel-warns-of-widespread-vulnerability-in-pc-server-device-firmware/
- https://news.softpedia.com/news/intel-x86-cpus-come-with-a-secret-backdoor-that-nobody-can-touch-or-disable-505347.shtml
- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html
- https://en.wikipedia.org/wiki/Intel_Management_Engine
- https://en.wikipedia.org/wiki/Intel_Active_Management_Technology
Row hammer
Type : RAM
Permet :
- S’échapper d’une sandbox pour exécuter des commandes système
- Accès illimité à la totalité de la mémoire du système
- PoC d’accès root sur Android
Impact : Toutes les machines équipées de DDR3 et nombreuses DDR4
Comment une attaque fonctionne ?
- En activant rapidement deux lignes de mémoire physique séparées par une ligne “victime”, on peut provoquer un changement d’état électrique sur des transistors de la ligne victime et donc changer des bits sur cette ligne de mémoire.
- Ça vient du fait que la DDR3 est très dense et que l’isolement entre les lignes de mémoire n’est pas très efficace.
- Il faut savoir précisément où “frapper” pour pouvoir utiliser cet exploit. Le faire au hasard sur une ligne donnée ne rendra pas nécessairement un résultat intéressant.
Fix possible ? Connu ? Il est possible de mitiger l’effet en rafraîchissant plus souvent les zones de mémoire potentiellement victimes. Ces mitigations sont toutefois plutôt matérielles et non logicielles. Il paraît difficile de réduire les effets sur une machine n’embarquant pas du hardware spécifiquement conçu pour mitiger cet exploit.
Notions : Conception électronique de la mémoire vive, Perturbations électriques
Pour aller plus loin :
