APIC/EPIC ! Les puces Intel divulguent des secrets que même le noyau ne devrait pas voir…

Voici le BWAIN de cette semaine, notre terme plaisant pour un Bug avec un nom impressionnant.

BWAIN est une récompense que nous décernons lorsqu'une nouvelle faille de cybersécurité s'avère non seulement intéressante et importante, mais apparaît également avec son propre logo, nom de domaine et site Web.

Celui-ci est surnommé Fuite ÆPIC, un jeu de mots sur les mots APIC ainsi que EPIC.

Le premier est l'abréviation de Contrôleur d'interruption programmable avancé, et ce dernier est simplement le mot "épique", comme dans géant, massif, extrême, méga, énorme.

La lettre Æ n'a pas été utilisée dans l'anglais écrit depuis l'époque saxonne. Son nom est æsc, prononcé frêne (comme dans l'arbre), et cela représente à peu près le son du A dans le mot moderne ASH. Mais nous supposons que vous êtes censé prononcer le mot ÆPIC ici soit comme "APIC-slash-EPIC", soit comme "ah!-eh?-PIC".

De quoi s'agit-il?

Tout cela soulève cinq questions fascinantes :

• Qu'est-ce qu'un APIC, et pourquoi en ai-je besoin ?
• Comment pouvez-vous avoir des données qui même le noyau je ne peux pas jeter un coup d'oeil ?
• Qu'est-ce qui cause cet échec épique en APIC ?
• Est-ce que Fuite ÆPIC m'affecte?
• Que faire à propos de ça?

Qu'est-ce qu'un APIC ?

Revenons en 1981, lorsque l'IBM PC est apparu pour la première fois.

Le PC comprenait une puce appelée le Contrôleur d'interruption programmable Intel 8259A, ou PIC. (Les modèles ultérieurs, à partir du PC AT, avaient deux PIC, enchaînés, pour prendre en charge davantage d'événements d'interruption.)

Le but du PIC était littéralement d'interrompre le programme en cours d'exécution sur le processeur central (CPU) du PC chaque fois qu'un événement urgent se produisait et nécessitait une attention immédiate.

Ces interruptions matérielles comprenaient des événements tels que : le clavier recevant une frappe ; le port série recevant un caractère ; et une minuterie matérielle répétitive.

Sans un système d'interruption matérielle de ce type, le système d'exploitation devrait être jonché d'appels de fonction pour vérifier régulièrement les frappes entrantes, ce qui serait un gaspillage de puissance CPU lorsque personne ne tape, mais ne serait pas réactif. assez quand ils l'ont fait.

Comme vous pouvez l'imaginer, le PIC a été bientôt suivi d'une puce améliorée appelée le APIC, un Avancée sorte de PIC intégré au CPU lui-même.

De nos jours, les APIC fournissent bien plus qu'un simple retour d'informations du clavier, du port série et de la minuterie système.

Les événements APIC sont déclenchés par (et fournissent des données en temps réel sur) des événements tels que la surchauffe, et permettent une interaction matérielle entre les différents cœurs des processeurs multicœurs contemporains.

Et les puces Intel d'aujourd'hui, si l'on peut simplifier grandement, peuvent généralement être configurées pour fonctionner de deux manières différentes, connues sous le nom de Mode xAPIC ainsi que Mode x2APIC.

Ici, xAPIC est le moyen "hérité" d'extraire des données du contrôleur d'interruption, et x2APIC est la manière la plus moderne.

En simplifiant encore plus, xAPIC s'appuie sur ce qu'on appelle MMIO, court pour entrée/sortie mappée en mémoire, pour lire les données de l'APIC lorsqu'il enregistre un événement d'intérêt.

En mode MMIO, vous pouvez découvrir ce qui a déclenché un événement APIC en lisant à partir d'une région spécifique de la mémoire (RAM), qui reflète les registres d'entrée/sortie de la puce APIC elle-même.

Ces données xAPIC sont mappées dans un bloc de mémoire de 4096 octets quelque part dans la RAM physique de l'ordinateur.

Cela simplifie l'accès aux données, mais cela nécessite une interaction gênante, complexe (et, comme nous le verrons, potentiellement dangereuse) entre la puce APIC et la mémoire système.

En revanche, x2APIC vous oblige à lire directement les données APIC de la puce elle-même, en utilisant ce qu'on appelle Registres spécifiques au modèle (MSR).

Selon Intel, éviter la partie MMIO du processus "fournit une adressabilité du processeur considérablement accrue et certaines améliorations sur la livraison des interruptions."

Notamment, l'extraction des données APIC directement à partir des registres sur puce signifie que la quantité totale de données prises en charge et le nombre maximal de cœurs de processeur pouvant être gérés en même temps ne sont pas limités aux 4096 octets disponibles en mode MMIO.

Comment pouvez-vous avoir des données que même le noyau ne peut pas consulter ?

Vous l'avez probablement déjà deviné, les données qui se retrouvent dans la zone mémoire MMIO lorsque vous utilisez le mode xAPIC ne sont pas toujours gérées avec autant de soin qu'elles devraient l'être…

… et donc qu'une sorte de "fuite de données" dans cette zone MMIO est au cœur de ce problème.

Mais étant donné que vous ont déjà besoin de pouvoirs de niveau administrateur système pour lire les données MMIO en premier lieu, et donc vous pourriez presque certainement accéder à toutes les données en mémoire de toute façon…

…pourquoi le fait que les données d'autres personnes apparaissent par erreur dans la zone de données APIC MMIO représenterait une épique fuir?

Cela pourrait rendre certains types d'attaques de vol de données ou de grattage de RAM un peu plus faciles dans la pratique, mais cela ne vous donnerait sûrement pas plus de capacité d'espionnage de la mémoire que vous aviez déjà en théorie ?

Malheureusement, cette hypothèse n'est pas vraie si un logiciel du système utilise le SGX d'Intel, abréviation de Extensions de Software Guard.

---

EN SAVOIR PLUS SUR SGX

---

SGX est pris en charge par de nombreux processeurs Intel récents et permet au noyau du système d'exploitation de "sceller" un morceau de code et de données dans un bloc physique de RAM afin de former ce que l'on appelle une enclave.

Cela le fait se comporter, du moins temporairement, un peu comme les puces de sécurité spéciales des téléphones mobiles qui sont utilisées pour stocker des secrets tels que les clés de déchiffrement.

Une fois que le « verrou » SGX de l'enclave est défini, seul le code de programme s'exécutant à l'intérieur de la zone de mémoire scellée peut lire et écrire le contenu de cette RAM.

Par conséquent, les détails internes de tous les calculs effectués après l'activation de l'enclave sont invisibles pour tout autre code, thread, processus ou utilisateur du système.

Y compris le noyau lui-même.

Il existe un moyen d'appeler le code qui a été scellé dans l'enclave, et un moyen pour lui de renvoyer la sortie des calculs qu'il pourrait effectuer, mais il n'y a aucun moyen de récupérer, ou d'espionner, ou de déboguer, le code et ses données associées pendant son exécution.

L'enclave se transforme effectivement en une boîte noire à laquelle vous pouvez alimenter des entrées, telles que des données à signer avec une clé privée, et extraire des sorties, telles que la signature numérique générée, mais à partir de laquelle vous ne pouvez pas extraire les clés cryptographiques utilisé dans le processus de signature.

Comme vous pouvez l'imaginer, si des données censées être scellées à l'intérieur d'une enclave SGX devaient accidentellement être dupliquées dans la RAM MMIO utilisée pour « refléter » les données APIC lorsque vous utilisez le mode xAPIC « mappé en mémoire »…

… cela violerait la sécurité de SGX, qui stipule qu'aucune donnée ne devrait jamais émerger d'une enclave SGX après sa création, à moins qu'elle ne soit délibérément exportée par du code déjà exécuté à l'intérieur de l'enclave elle-même.

Qu'est-ce qui cause cet échec épique dans APIC ?

Les chercheurs derrière le Papier ÆPIC Leak a découvert qu'en s'arrangeant pour lire les données APIC via une séquence rusée et inhabituelle d'accès à la mémoire…

… ils pourraient inciter le processeur à remplir l'espace APIC MMIO non seulement avec des données fraîchement reçues de l'APIC lui-même, mais également avec des données qui viennent d'être utilisées récemment par le CPU à d'autres fins.

Ce comportement est un effet secondaire du fait que bien que la page mémoire APIC MMIO ait une taille de 4096 octets, la puce APIC en mode xAPIC ne produit pas réellement 4096 octets de données, et le CPU ne neutralise pas toujours correctement les parties inutilisées de la région MMIO en la remplissant d'abord de zéros.

Au lieu de cela, les anciennes données restantes dans le cache du processeur ont été écrites avec les nouvelles données reçues de la puce APIC elle-même.

Comme l'ont dit les chercheurs, le bogue se résume à ce qu'on appelle un lecture mémoire non initialisée, où vous réutilisez accidentellement les données restantes de quelqu'un d'autre dans la RAM parce que ni eux ni vous ne l'avez d'abord vidé de ses secrets précédents.

Est-ce que la fuite ÆPIC m'affecte ?

Pour une liste complète des puces concernées, voir Avis d'Intel.

Pour autant que nous sachions, si vous avez un processeur Intel de 10e ou 11e génération, vous êtes probablement concerné.

Mais si vous avez un tout nouveau processeur de 12e génération (le tout dernier au moment de la rédaction), il semble que seules les puces de classe serveur soient affectées.

Ironiquement, dans les puces pour ordinateurs portables de 12e génération, Intel a abandonné SGX, donc ce bogue ne s'applique pas car il est impossible d'avoir des enclaves SGX "scellées" qui pourraient fuir.

Bien sûr, même sur une puce potentiellement vulnérable, si vous ne comptez sur aucun logiciel utilisant SGX, le bogue ne s'applique pas non plus.

Et le bug, surnommé CVE-2022-21233, ne peut être exploité que par un attaquant qui dispose déjà d'un accès local de niveau administrateur (root) à votre ordinateur.

Utilisateurs réguliers ne peut pas accéder au bloc de données APIC MMIO, et n'a donc aucun moyen d'y jeter un coup d'œil, sans parler des données secrètes qui auraient pu fuir d'une enclave SGX.

Aussi, les machines virtuelles invitées (VM) s'exécutant sous le contrôle d'un système d'exploitation hôte dans un hyperviseur tel que HyperV, VMWare ou VirtualBox ne peuvent certainement pas utiliser cette astuce pour piller les secrets d'autres invités ou de l'hôte lui-même.

En effet, les machines virtuelles invitées n'ont généralement pas accès aux véritables circuits APIC du processeur hôte ; à la place, chaque invité obtient son propre APIC simulé qui est unique à cette machine virtuelle.

Que faire?

Pas de panique.

Sur un ordinateur portable ou de bureau, vous ne courez peut-être aucun risque, soit parce que vous avez un ordinateur plus ancien (ou, chanceux, tout neuf !), soit parce que vous ne comptez pas sur SGX de toute façon.

Et même si vous êtes à risque, toute personne qui entre dans votre ordinateur portable en tant qu'administrateur/root a probablement assez de puissance pour vous causer déjà un monde de problèmes.

Si vous avez des serveurs vulnérables et que vous comptez sur SGX dans le cadre de votre sécurité opérationnelle, consultez l'avis de sécurité d'Intel INTEL-SA-00657 pour obtenir des informations sur la protection et l'atténuation.

Selon les chercheurs qui l'ont écrit, "Intel [has] a publié des mises à jour du microcode et du kit de développement logiciel SGX pour résoudre le problème."

L'équipe du noyau Linux semble également travailler en ce moment sur un patch qui vous permettra de configurer votre système pour qu'il utilise toujours x2APIC (qui, comme vous vous en souviendrez plus tôt, ne transmet pas les données APIC via la mémoire partagée), et empêchera gracieusement le retour forcé du système en mode xAPIC après le démarrage.

---