Baisse de performance de tous les pc : une situation préoccupante

Une faille de conception fondamentale dans les puces de processeurs d’Intel a forcé une refonte significative des noyaux Linux et Windows pour résoudre le problème de sécurité au niveau de la puce.

Les programmeurs se bousculent pour refondre le système de mémoire virtuelle du noyau Linux open-source. En attendant, Microsoft devrait introduire publiquement les changements nécessaires à son système d’exploitation Windows dans un prochain Patch : ces changements ont été lancés à des bêta-testeurs exécutant des builds Windows Insider rapides en novembre et décembre.

Ces mises à jour à la fois Linux et Windows entraînera une baisse des performances sur les produits Intel. Les effets sont encore étalonnés, mais nous observons un chiffre approximatif de 5 à 30% de ralentissement, selon la tâche et le modèle de processeur. Les puces Intel plus récentes ont des fonctionnalités  telles que PCID  pour réduire les pertes de performances. 

Des systèmes d’exploitation similaires, tels que MacOS 64 bits d’Apple, devront également être mis à jour, la faille est dans le matériel Intel x86-64, et il semble qu’une mise à jour de microcode ne peut pas y remédier. Il doit être fixé dans le logiciel au niveau de l’OS, ou aller acheter un nouveau processeur sans la faute de conception.

Les détails de la vulnérabilité dans le silicium d’Intel sont sous-jacents: un embargo sur les détails devrait être levé au début du mois, peut-être à temps pour le correctif de Microsoft mardi prochain. En effet, les corrctifs pour le noyau Linux sont disponibles pour tous, mais les commentaires dans le code source ont été rédigés pour obscurcir le problème.

Cependant, certains détails de la faille ont fait surface, et c’est ce que nous savons.

Impact

 

Il est entendu que le bug est présent dans les processeurs Intel modernes produits dans la dernière décennie. Il permet aux programmes utilisateur normaux  des applications de base de données au JavaScript dans les navigateurs Web, de discerner dans une certaine mesure la disposition ou le contenu des zones de mémoire du noyau protégées.

La solution consiste à séparer complètement la mémoire du noyau des processus utilisateur en utilisant ce qu’on appelle l’isolation de la table du noyau, ou KPTI. À un moment donné, Force Unmap complète du noyau avec des trampolines d’interruption, alias FUCKWIT, a été étudiée par l’équipe du noyau Linux, vous donnant ainsi une idée de l’énervement que cela a causé aux développeurs.

Chaque fois qu’un programme en cours doit faire quelque chose d’utile comme écrire dans un fichier ou ouvrir une connexion réseau, il doit temporairement transférer le contrôle du processeur au noyau pour effectuer le travail. 

Pour faire la transition du mode utilisateur au mode noyau et revenir au mode utilisateur aussi rapidement et efficacement que possible, le noyau est présent dans tous les espaces d’adresses de mémoire virtuelle de tous les processus, bien qu’il soit invisible pour ces programmes. 

Lorsque le noyau est nécessaire, le programme passe un appel système, le processeur passe en mode noyau et entre dans le noyau. Lorsque cela est fait, le processeur est dit de revenir en mode utilisateur, et de rentrer dans le processus. En mode utilisateur, le code et les données du noyau restent hors de vue mais présents dans les tables de pages du processus.

 

Ces correctifs KPTI déplacent le noyau dans un espace d’adressage complètement séparé, donc ce n’est pas seulement invisible pour un processus en cours d’exécution, il n’est même pas là du tout. Vraiment, cela ne devrait pas être nécessaire, mais il y a clairement une faille dans le silicium d’Intel qui permet aux protections d’accès au noyau d’être contournées d’une manière ou d’une autre.

L’inconvénient de cette séparation

C’est qu’il est relativement coûteux, dans le temps, de continuer à basculer entre deux espaces d’adressage distincts pour chaque appel système et pour chaque interruption du matériel. 

Ces commutateurs de contexte ne se produisent pas instantanément et forcent le processeur à vider les données mises en cache et à recharger les informations de la mémoire. Cela augmente les frais généraux du noyau et ralentit l’ordinateur.

Votre machine à processeur Intel sera plus lente en conséquence.

Comment peut-on abuser de ce trou de sécurité?

Au mieux, la vulnérabilité pourrait être exploitée par des logiciels malveillants et des pirates informatiques pour exploiter plus facilement d’autres bogues de sécurité.

Au pire, les programmes et les utilisateurs connectés pourraient en abuser pour lire le contenu de la mémoire du noyau. Autant dire que ce n’est pas génial.

 L’espace mémoire du noyau est caché des processus et des programmes utilisateur car il peut contenir toutes sortes de secrets, tels que des mots de passe, des clés de connexion, des fichiers mis en cache sur le disque, etc. 

Imaginez un morceau de JavaScript exécuté dans un navigateur ou un logiciel malveillant exécuté sur un serveur de cloud public partagé, capable de détecter des données sensibles protégées par le noyau.

Plus précisément, en termes de scénario optimal, il est possible que le bogue soit utilisé pour vaincre KSLR: randomisation de mise en page d’espace d’adresse du noyau. 

C’est un mécanisme de défense utilisé par divers systèmes d’exploitation pour placer les composants du noyau dans des emplacements aléatoires dans la mémoire virtuelle. Ce mécanisme peut contrecarrer les tentatives d’abus d’autres bogues dans le noyau: typiquement, le code d’exploitation,en particulier les exploits de programmations orientés retour repose sur la réutilisation d’instructions informatiques dans des emplacements connus en mémoire.

Si vous randomisez la mise en mémoire du code du noyau, les exploits ne peuvent pas trouver les gadgets internes dont ils ont besoin pour compromettre complètement un système. La faille du processeur pourrait être potentiellement exploitée pour déterminer où en mémoire le noyau a positionné ses données et son code, d’où la vague de correctifs logiciels.

Cependant, il se peut que la vulnérabilité dans les puces d’Intel soit pire que le contournement d’atténuation ci-dessus. Dans un e-mail envoyé à la liste de diffusion du noyau Linux à Noël, AMD a déclaré qu’il n’est pas affecté. La formulation de ce message, cependant, donne plutôt le jeu quant à ce que le cockup sous-jacent est:

Les processeurs AMD ne sont pas soumis aux types d’attaques contre lesquels la fonction d’isolation de la table de pages du noyau protège. La microarchitecture AMD n’autorise pas les références de mémoire, y compris les références spéculatives, qui accèdent à des données à privilèges plus élevés lorsqu’elles s’exécutent dans un mode privilégié inférieur lorsque cet accès entraîne une erreur de page.

Un mot clé ici est « spéculatif ». Les processeurs modernes, comme Intel, effectuent une exécution spéculative. Afin de garder leurs pipelines internes amorcés avec des instructions pour obéir, les cœurs du CPU essaient de deviner quel code va être exécuté, le récupérer et l’exécuter.

Il semble, d’après ce que suggérait Tom Lendacky, ingénieur logiciel chez AMD, que les processeurs d’Intel exécutent de manière spéculative du code potentiellement sans effectuer de contrôles de sécurité. Il semble qu’il soit possible de créer un logiciel de manière à ce que le processeur commence à exécuter une instruction qui serait normalement bloquée, comme la lecture de la mémoire du noyau en mode utilisateur et termine cette instruction avant la vérification du niveau de privilège.

Cela permettrait au code utilisateur ring-3-level de lire les données du noyau ring-0-level. Et ce n’est pas bon.

Les spécificités de la vulnérabilité doivent encore être confirmées, mais considérez ceci: les changements apportés à Linux et Windows sont importants et sont poussés à grande vitesse. Cela suggère que c’est plus grave qu’une dérivation KASLR.

En outre, les mises à jour pour séparer les espaces d’adresses de noyau et d’utilisateur sur Linux sont basées sur un ensemble de correctifs appelés patchs KAISER , qui ont été créés par eggheads à Graz University of Technology en Autriche. 

Ces boffins ont découvert qu’il était possible de vaincre KASLR en extrayant des informations de disposition de la mémoire du noyau dans une attaque par canal latéral sur le système de mémoire virtuelle du CPU. L’équipe a proposé de séparer le noyau et les espaces utilisateurs afin d’empêcher cette fuite d’information, et leurs recherches ont déclenché cette série de correctifs.

Leur travail a été examiné par Anders Fogh.Il décrit ses tentatives de lire la mémoire du noyau à partir du mode utilisateur en abusant de l’exécution spéculative. Bien que Fogh ait été incapable de trouver un code de preuve de concept, il a noté:

Mes résultats démontrent que l’exécution spéculative continue en effet malgré les violations de l’isolation entre le mode noyau et le mode utilisateur.

Il semble que le travail de KAISER soit lié à la recherche de Fogh, et en plus de développer un moyen pratique pour casser KASLR en abusant des mises en page de mémoire virtuelle, l’équipe peut avoir prouvé Fogh correctement – l’exécution spéculative sur les puces Intel x86 peut être exploitée pour accéder au noyau Mémoire.

Systèmes partagés

Le bug aura un impact sur les grands noms des environnements de cloud computing , y compris Amazon EC2, Microsoft Azure et Google Compute Engine, a déclaré un développeur de logiciels de blogging comme Python Sweetness.

Il existe actuellement un bogue de sécurité sous embargo affectant apparemment toutes les architectures de processeurs [Intel] contemporaines qui implémentent la mémoire virtuelle, nécessitant des modifications matérielles pour une résolution complète. 

Le développement urgent d’une stratégie d’atténuation de logiciels est en cours et a récemment été effectué dans le noyau Linux, et une atténuation similaire a commencé à apparaître dans les noyaux NT en novembre. Dans le pire des cas, le correctif logiciel provoque d’énormes ralentissements dans les charges de travail typiques.

Il y a des indices que l’attaque affecte des environnements de virtualisation communs, y compris Amazon EC2 et Google Compute Engine …

Le cloud Azure de Microsoft, qui exécute beaucoup de Linux et de Windows, sera soumis à des opérations de maintenance  le 10 janvier, vraisemblablement pour déployer les correctifs ci-dessus.

Amazon Web Services a également averti les clients de s’attendre à une mise à jour majeure de la sécurité vendredi, sans entrer dans les détails.

Il y avait des rumeurs d’un bug d’hyperviseur sévère, peut-être dans Xen, faisant les tours fin 2017. Il se peut que cette faille matérielle soit ce bug rumeur: les hyperviseurs peuvent être attaqués via cette pile d’accès mémoire du noyau, et doivent donc être corrigé, en forçant un redémarrage en masse des machines virtuelles invitées.

Un porte-parole d’Intel n’était pas disponible pour commenter. 

Mis à jour pour ajouter

La faille du processeur Intel est réelle. Un étudiant de doctorat au groupe des systèmes et la sécurité du réseau à Vrije Universiteit Amsterdam a mis au point un programme de preuve de concept qui exploite la faille Chipzilla :

Le registre a également vu un code d’exploit de preuve de concept qui laisse échapper une infime quantité de mémoire du noyau pour les processus utilisateur.

Enfin, macOS a été corrigé pour contrer la bévue de conception de la puce depuis la version 10.13.2, selon l’expert du noyau du système d’exploitation Alex Ionescu. Et il semble que les noyaux ARM Linux 64 bits recevront également un ensemble de patches KAISER, séparant complètement le noyau et les espaces utilisateur, pour bloquer les tentatives de vaincre KASLR. Nous suivrons cette semaine.

Mise à jour finale

Gardez à l’esprit qu’il y a deux défauts en jeu ici: un appelé Meltdown qui affecte principalement Intel, et ce que l’article ci-dessus est tout au sujet, et un autre appelé Spectre qui affecte les cœurs Intel, AMD, et Arm.