Comptoir'labs • NetCAT : la sécurité pour Intel, c'est toujours pas glop !

Dans la série Meltdown et Spectre, voici le cousin germain ayant hérité du pire de toute la famille, nous avons nommé NetCAT. Cette fois-ci, il n'est pas question d'exécution spéculative, mais d'utilisation d'un canal auxiliaire via le RDMA et plus précisément la technologie DDIO des cartes réseau. Tout le monde est perdu ? Nous aussi, revoyons donc tout cela avec moins d'acronymes et plus de français.

Pour fonctionner, les périphériques un tant soit peu complexes ont besoin d'accéder à une zone mémoire. Celle-ci était à l'origine directement gérée par le CPU, guidé par les pilotes, puis a évolué pour devenir du DMA (Direct Memory Access) dans lequel le bousin - ici une carte réseau - peut tranquilou aller accéder tout seul comme un grand à sa zone RAM, permettant, vous l'imaginez, de laisser le CPU bosser et ainsi accélérer l'exécution. Dans le cas de notre carte réseau, ce DMA devient distant, soit remote, d'où l'appellation RDMA. Sauf que pour les serveurs gérant essentiellement du trafic via l'Ethernet, ce n'est toujours pas assez rapide : Intel a donc eu l'idée d'aller utiliser du cache L3 pour améliorer les performances des échanges serveur-client : ainsi est née la fonctionnalité DDIO pour Data Direct Input Output... et si le nom du L3 n'est pas évoqué, c'est normal : le bas niveau n'est pas fait pour être clair, mais pour fonctionner (de manière sécurisée si possible... sic). Bouclons la boucle : cette zone de cache DDIO correspond toujours à une zone RAM (spéciale RDMA du coup) : le cache garde ainsi le même rôle qu’escompté lors de son utilisation par le CPU.

Pour compliquer un peu, tout le Last Level Cache (abrégé LLC, L3 donc)) n'est pas accessible en DDIO : seule une partie (ici en jaune) est allouée pour la carte. Petit point jargon ; NIC signifie simplement "Interface Réseau", qu'il s'agisse de câble Ethernet, possiblement WiFi ou tout autre interconnect propriétaire.

Où se situe la faille du coup ? Si vous ne l'avez pas vu venir, il est possible par un pirate de remplir toute la zone cache du DDIO avec des données savamment choisies, puis de sonder (probe) toutes les cases mémoires afin de voir - via une mesure de la latence mémoire - où la carte a été écrire lorsqu'elle s'occupait d'une autre connexion. En effet, si une tierce personne s'est connectée, alors une partie des données attaquantes a été retirée du cache et mise en RAM, menant à un temps d'accès plus long. Ce processus forme le fameux canal auxiliaire : un moyen détourné d'obtenir des données, et requiert une poignée de minutes seulement. La suite se déroule toute seule : aller de l'emplacement mémoire à l'opération effectuée est possible via une étude approfondie du comportement de la carte réseau, ce qui offre la possibilité de faire fuiter des informations potentiellement sensibles.

Une preuve de concept - bien incompréhensible, comme tout travail scientifique bas niveau - a été réalisée sur un serveur à base de Intel  Xeon  Silver  4110 sous  Ubuntu  18.04.1  LTS, et a mené au déchiffrement des commandes tapées par un autre utilisateur dans une session distante. Comment cela ? Grace au canal auxiliaire, la machine attaquante obtient activité mémoire pour chaque touche clavier pressée. En suit alors un monstrueux travail statistique visant à relier les temps séparant chaque frappe (par exemple, sur un clavier azerty, taper "qu" est plus rapide que "de" si vous utilisez bien vos deux mains) au contenu des frappes en elles-mêmes. Complexe, mais effrayant : personne ne souhaite un keylogger alors même que le pirate n'a même pas les droits d'exécution utilisateurs sur le serveur. Hé oui, il faut simplement pourvoir utiliser le RDMA/DDIO de la carte réseau, un privilège moindre dépendant de l'implémentation et de l'application utilisée.

Niveau matériel impacté, l'attaque cible tous les processeurs professionnels bleus - Xeon donc - depuis 2012, et, pour couronner le tout, peut fuiter entre VM voire entre utilisateurs de réseaux locaux différents : joie ! Selon les scientifiques, une seule méthode simple est possible pour colmater la brèche à court terme : désactiver MMIO, et abandonner les gains qui y sont liés. Cependant, des rustines hardwares pourraient voir le jour, qui consistent essentiellement à davantage cloisonner les régions mémoires correspondantes aux paquets reçus en fonction des machines sources. Difficile de rester optimiste quant aux possibilités induites par un tel vecteur d'attaque : partager une zone du cache est à l'heure actuelle simplement non sécurisé... méthode qui a malheureusement été employée à divers endroits, car efficace niveau performances. De quoi pousser vers une séparation plus marquée des architectures de processeurs serveur face à ceux grand public ?

Pour fixer les bugs tout en se protégeant, le scotch Durex est sans aucun doute la solution de choix (merci Gus' pour la référence !)

Du fait de la technicité de l'attaque - il est nécessaire de passer plusieurs heures pour rétro-ingénérer l'algorithme de placement dans le cache, qui est potentiellement différent pour chaque processeur - et des privilèges d'accès au mécanisme RDMA/DDIO de la carte réseau (sans compter les parasites liés à l'utilisation normale du cache par les autres processus et les autres connexions), Intel communique sur une dangerosité faible (note de 2,6 sur l'échelle CVSS). Ce qui se défend d'autant plus par le fait qu'il est nécessaire d'être sur le même réseau local que la cible : un routeur, une frontale et n'espérez pas utiliser ce vecteur pour subtiliser des données. À vous par la suite de vous faire un avis niveau gravité de la situation à la lumière de ces explications ! (Source : SecurityWeek (et merci à un ragoteur anonyme !))