Mise à jour : Nous avons ajouté des informations provenant de différents éditeurs et publiées après la parution de cet article. Découvrez-les à la fin de l’article (le dernier en date : 2018-01-05T00:30Z).
Remarque : Si vous recherchez des informations et des conseils concernant les produits Sophos en particulier, veuillez consulter notre Knowledgebase Article 128053.
Très prochainement, et à priori avant la fin du mois, Windows et Linux recevront des mises à jour de sécurité qui changeront la façon dont ces systèmes d’exploitation gèrent la mémoire au niveau des processeurs Intel.
Ces changements suscitent beaucoup d’intérêt, allant jusqu’à provoquer même une certaine effervescence : en effet, ils agissent à un très bas niveau et sont susceptibles d’affecter les performances.
Le ralentissement potentiel dépendra de nombreux facteurs, mais un rapport suggère que les serveurs de base de données, fonctionnant sur du hardware affecté, pourraient subir une baisse de performance d’environ 20%.
Le “hardware affecté” semble inclure la plupart des processeurs Intel commercialisés ces dernières années. Les processeurs AMD, apparemment, ont des structures internes différentes et sont protégés vis-à-vis de ce problème de cybersécurité.
Alors, que se passe-t-il vraiment ?
Sous Linux, les mises à jour de sécurité à venir sont connus sous le nom de KPTI, à savoir Kernel Page Table Isolation, bien qu’ils aient été désignés, en plaisantant, par les noms KAISER et F**CKWIT.
Le dernier est l’abréviation de “Forcemap Unmap Complete Kernel With Interrupt Trampolines“. Le premier, quant à lui, est l’abréviation de “Kernel Address Isolation to have Side-channels Efficiently Removed”.
Voici quelques explications.
Dans la plupart des systèmes d’exploitation modernes, vous trouverez un noyau avec des niveaux de privilèges, appelé kernel, qui gère l’ensemble du système : il démarre et arrête les programmes utilisateur, il applique les paramètres de sécurité, il gère la mémoire de sorte qu’un programme ne puisse pas en effacer un autre, il contrôle l’accès au hardware secondaire tel que les périphériques USB et les cartes réseau, et il gouverne et régule le roost.
Enfin tout le reste, désigné plus haut par les “programmes utilisateur”, fonctionne dans ce qu’on appelle un espace utilisateur (userland), dans lequel les programmes peuvent interagir les uns avec les autres, mais seulement par consentement.
En effet, si un programme pouvait lire (ou, pire encore, modifier) les données d’un autre programme, ou interférer avec son fonctionnement, nous aurions affaire à un sérieux problème de sécurité. La situation serait bien pire si un programme utilisateur pouvait avoir accès aux données du kernel, car cela risquerait d’interférer avec la sécurité et l’intégrité de l’ensemble de l’ordinateur.
L’une des missions du noyau consiste, justement, à séparer prudemment le noyau de l’espace utilisateur, afin que les programmes au sein de l’espace utilisateur ne puissent pas prendre le contrôle sur le noyau lui-même, et contourner la sécurité, par exemple en lançant des malwares, en volant des données, en surveillant le trafic sur le réseau, ou encore en s’immisçant au sein du hardware.
Le processeur fournit, lui-même, un support matériel pour ce type de séparation : les processeurs x86 et x64 fournissent ce que l’on appelle des niveaux de privilèges, implémentés et appliqués par la puce elle-même, qui peuvent être utilisés pour séparer le noyau des programmes utilisateur lancés.
Intel appelle ces niveaux de privilèges des anneaux, et il en existe quatre. La plupart des systèmes d’exploitation en utilisent principalement deux : Ring 0 (le niveau de privilèges le plus haut) pour le noyau, et Ring 3 (le niveau de privilèges le plus bas) pour l’espace utilisateur.
Autrement dit, les processus au sein du Ring 0 peuvent prendre le contrôle des processus et des ressources dans les anneaux de niveau supérieur, mais pas l’inverse.
En théorie, le processeur empêche les programmes du Ring 3 d’avoir accès à la mémoire du Ring 0, interdisant ainsi aux programmes utilisateur de jeter un coup d’œil dans l’espace d’adressage du noyau, ce qui pourrait révéler des détails très sensibles concernant le système lui-même.
En termes techniques, une séquence d’instructions en langage machine comme celle-ci, fonctionnant dans l’espace utilisateur, devrait être bloquée à l’étape 1 :
mov rax, [kernelmemory] ; this will get blocked - the memory is protected mov rbx, [usermemory] ; this is allowed - the memory is "yours"
De même, en échangeant les instructions, cette séquence serait bloquée à l’étape 2 :
mov rbx, [usermemory] ; this is allowed - the memory is "yours" mov rax, [kernelmemory] ; this will get blocked - the memory is protected
Aujourd’hui, les processeurs Intel et AMD modernes prennent en charge l’exécution spéculative, par le biais de laquelle le processeur détermine ce que les prochaines instructions sont supposées faire, en les divisant en sous-instructions plus petites et en les traitant ensuite avec un ordre différent que celui préconisé initialement par le programme.
Cette technique a pour but d’augmenter le débit. Ainsi, une opération lente qui n’affecte pas les résultats intermédiaires peut être démarrée plus tôt au niveau de la file d’attente, avec d’autres tâches traitées en “temps masqué”, en attendant que l’instruction lente soit achevée, si cette dernière se situe en fin de liste.
Au-dessus, par exemple, les deux instructions sont indépendantes d’un point de vue calcul, donc peu importe l’ordre dans lequel elles sont exécutées, et ce même si le fait de les permuter changera le moment où le processeur interviendra pour bloquer l’instruction incriminée (à savoir celle qui essaie d’avoir accès à la mémoire du noyau).
L’ordre a de l’importance !
En juillet 2017, un expert allemand en cybersécurité a fait des recherches pour voir si l’ordre avait réellement de l’importance.
Il s’est demandé quel serait l’impact potentiel si un processeur qui calculerait des résultats internes dans le cadre d’une instruction illégale X, et les utiliserait pour gérer une instruction légale Y, ne signalait X comme non autorisée uniquement après.
Même si X et Y étaient finalement annulées, existerait-il une trace du résultat interne de l’exécution spéculative de l’instruction illégale X ?
Si oui, peut-on tirer quelque chose de cette empreinte restante ?
L’exemple que l’expert a utilisé pour commencer était le suivant :
1. mov rax, [K] ; K is a kernel address that is banned 2. and rax, 1 3. mov rbx, [U+rax] ; U is a user address that is allowed
Ne vous inquiétez pas si vous ne parlez couramment l’assembler, ce code exécute les tâches suivantes :
- Charger le registre A depuis la mémoire du noyau.
- Mettre A à 0 s’il était pair, ou à 1 s’il était impair (ceci simplifie l’exercice intellectuel).
- Charger le registre B depuis l’emplacement mémoire U+0 ou U+1, en fonction de A.
En théorie, l’exécution spéculative signifie que le processeur pourrait finir en interne l’instruction 3, avant d’avoir terminé l’instruction 1, et ce même si toute la séquence d’instructions devait se trouver finalement invalidée et bloquée en raison de la violation de privilèges en 1.
Cependant, il se peut que les conséquences engendrées par l’instruction 3 puissent avoir laissé des traces ailleurs au sein du processeur ?
Après tout, le comportement du processeur aurait pu être légèrement différent selon que l’instruction 3, exécutée de manière spéculative, ait fait référence à l’emplacement mémoire U ou U+1.
Par exemple, cette différence peut simplement apparaître dans la mémoire cache du processeur, à savoir une liste d’adresses mémoire récemment référencées, incrémentées des valeurs qui sont conservées à l’intérieur du processeur pour des raisons de performances.
En d’autres termes, le cache peut agir comme une sorte de “mouchard”, appelé aussi canal secondaire (side channel), qui peut laisser échapper des informations secrètes situées à l’intérieur du processeur, que la valeur des privilèges de l’emplacement de mémoire K soit pair ou impair (pour reprendre notre exemple).
NB : L’accès à la mémoire dans le cache du processeur est environ 40 fois plus rapide que l’accès à partir des puces de mémoire existantes. Ainsi, en permettant ce type de “court-circuit” pour les valeurs couramment utilisées, l’impact en matière de performance peut être très important).
Pour résumer, l’expert en question n’a pas pu faire la différence entre A est pair et A est impair (ou, alternativement, est ce que le processeur a puisé dans U ou dans U+1) dans ce cas précis …
… mais l’exercice intellectuel a tout de même bien fonctionné.
L’expert a trouvé d’autres constructions de code similaires qui vous permettent d’obtenir des informations sur la mémoire du noyau, en utilisant des astuces de calcul d’adresses de ce type.
En d’autres termes, les processeurs Intel souffrent d’un problème de canal secondaire au niveau du hardware, qui pourrait laisser fuiter de la mémoire à privilèges vers des programmes sans privilèges.
Le reste appartient à l’histoire
Et le reste appartient effectivement à l’histoire.
Des mises à jour de sécurité vont bientôt arriver, du moins pour Linux et Windows, afin de mettre en place KAISER : Kernel Address Isolation to have Side-channels Efficiently Removed, ou KPTI, qui est son appellation politiquement correcte.
Vous avez maintenant une idée de l’origine du nom KAISER : ce patch permet de séparer davantage la mémoire du noyau et celle de l’espace utilisateur, de sorte que les conséquences liées à l’utilisation de diverses techniques malveillantes lors de l’exécution spéculative ne puissent plus être comparées.
Ces mises à jour de sécurité sont particulièrement importantes pour les ordinateurs multi-utilisateurs, tels que les serveurs exécutant plusieurs machines virtuelles, des utilisateurs individuels ou des systèmes d’exploitation invités peuvent utiliser cette astuce pour “atteindre” d’autres parties du système, telles que le système d’exploitation hôte ou d’autres invités sur le même serveur physique.
Cependant, étant donné que la mise en cache réalisée par le processeur est présente pour améliorer les performances, tout ce qui réduit l’efficacité de cette dernière risque de réduire les performances, voici la dure réalité de ce monde !
Parfois, il est vrai, une cybersécurité améliorée s’accompagne de quelques inconvénients. Par exemple, le 2FA est plus compliqué qu’un simple login, et la connexion HTTPS consomme plus de ressources que le HTTP.
Pour faire simple, préparez-vous à accepter quelques désagréments pour le bien de tous !
Et après ?
Une majeure partie des détails concernant ces mises à jour de sécurité est actuellement [2018-01-03T16: 30Z] cachée derrière le voile du secret !
Ce secret semble être dû aux clauses de non-divulgation imposées par divers éditeurs impliqués dans la préparation des mises à jour de sécurité, une précaution compréhensible étant donné le niveau d’intérêt général concernant les nouvelles façons de tirer parti des fuites de données et les exploits d’élévation de privilèges.
Nous espérons que ce secret sera levé à mesure que les mises à jour de sécurité seront officiellement disponibles.
Cependant, vous pouvez obtenir et essayer les correctifs Linux dès maintenant, si vous le souhaitez (ils ne sont pas encore finalisés, ainsi nous vous les recommandons uniquement à des fins de tests).
Pour le moment, les risques liés à cette faille semblent relativement modérés au niveau des serveurs dédiés tels que les appliances, et sur des appareils personnels tels que les ordinateurs portables : pour l’exploiter, un cybercriminel doit d’abord pouvoir exécuter du code sur votre ordinateur, ce qui signifie que vous seriez déjà en danger !
Sur les ordinateurs partagés tels que les serveurs dédiés multi-utilisateurs ou les services d’hébergement qui prennent en charge plusieurs machines virtuelles de différents clients sur le même support physique, les risques sont beaucoup plus grands : le noyau hôte est là pour séparer les utilisateurs les uns des autres, et pas seulement pour séparer les différents programmes utilisés par un utilisateur.
Ainsi, une faille comme celle-ci pourrait permettre à utilisateur malveillant d’espionner d’autres personnes connectées en même temps, ou d’influencer d’autres machines virtuelles hébergées sur le même serveur.
Cette faille existe depuis des années, et a été documentée depuis des mois au moins, donc il n’est pas nécessaire de paniquer. Néanmoins, nous vous recommandons de surveiller sérieusement la disponibilité des mises à jour de sécurité pour les systèmes d’exploitation que vous utilisez, à priori au cours du mois de janvier 2018, et surtout de les installer dès que possible !
MISES A JOUR
[2018-01-04T01:00Z]
L‘équipe de chasseurs de bugs du Project Zero de Google a publié une description détaillée concernant les coulisses de la recherche menée depuis plusieurs mois maintenant. Cette dernière est très technique et un peu lourde au niveau du jargon utilisé, mais les grandes lignes à retenir sont les suivantes :
- En théorie, divers processeurs Intel, AMD et ARM ont des fonctionnalités liées à l’exécution spéculative et à la mise en cache qui peuvent être exploitées comme nous l’avons décrit ci-dessus.
- Les puces AMD n’ont jusqu’ici été exploitées que sous Linux, avec une fonctionnalité du noyau de type “non-default” activée.
- Les puces Intel ont été exploitées afin qu’un utilisateur connecté, et sans privilège, puisse avoir accès aux données du noyau, lentement mais régulièrement.
- Les puces Intel ont été exploitées afin qu’un utilisateur root, au sein d’une machine virtuelle invitée, puisse lire les données du noyau hôte lentement mais régulièrement.
NB : “Lentement” signifie qu’un cybercriminel peut récupérer à peu près 1000 octets par seconde, soit environ 100 Mo par jour.
Même si vous partez du principe qu’un cybercriminel qui ne sait pas où concentrer son attention, peut néanmoins se contenter d’extraire des données au niveau noyau de manière aléatoire, vous pouvez considérer que ce problème est similaire à Heartbleed, où un cybercriminel très souvent se retrouvait avec des données totalement inutiles, mais pouvait parfois avoir de la chance et mettre la main sur des données confidentielles telles que des mots de passe et des clés de déchiffrement privées.
Contrairement à Heartbleed, le cybercriminel a déjà besoin d’avoir un pied dans un serveur vulnérable, par exemple en tant qu’utilisateur connecté avec un command shell ouvert, ou en tant que propriétaire d’une machine virtuelle (VM) fonctionnant sur un serveur d’hébergement (dans les deux cas, l’utilisateur doit être entièrement lié à son propre compte ou à sa propre machine virtuelle).
Intel a publié un bref commentaire officiel intitulé Intel responds to security research findings. Cette déclaration ne contient pas beaucoup d’informations, alors ne soyez pas trop enthousiastes. Néanmoins, les points importants sont les suivants :
- “Intel estime que ces exploits n’ont pas le potentiel de corrompre, modifier ou supprimer des données“. En effet, les attaques et les exploits signalés jusqu’à présent peuvent récupérer des données du noyau, mais ne peuvent pas injecter des données en retour dans l’espace kernel.
- “Les signalements récents qui font état d’exploits qui auraient été générés par un “bug” ou une “faille”, et qui seraient propres aux seuls produits Intel sont incorrects”. Nous avons utilisé le mot “faille” dans notre titre, et nous allons nous y tenir. À notre avis, une mise en œuvre idéale de l’exécution spéculative doit assurer qu’aucune trace détectable et encore présente après une exécution spéculative ne puisse être trouvée afin de contourner la sécurité en place.
- “Contrairement à certains signalements, les impacts sur les performances dépendent essentiellement de la charge de travail et, pour l’utilisateur moyen, ne devraient pas être significatifs“. A vous d’interpréter comme il se doit cette dernière déclaration !
[2018-01-04T17:40Z]
AMD a publié une déclaration intitulée An update on AMD processor security. Comme la déclaration d’Intel, elle ne nous éclaire pas vraiment plus, mais elle confirme que les processeurs AMD ne sont pas entièrement à l’abri vis-à-vis de ces attaques.
Il existe trois numéros de vulnérabilité CVE liées aux divers exploits F**CKWIT : CVE-2017-5753, CVE-2017-5715 et CVE-2017-5754.
AMD affirme qu’il est vulnérable vis-à-vis de -5733, immunisée contre -5754, et que bien qu’il soit en théorie en danger vis-à-vis de -5715, “les différences d’architecture AMD font qu’il existe un risque quasi-nul d’exploitation de cette variante”.
[2018-01-05T00:30Z]
Firefox vient de publier une mise à jour du navigateur pour atténuer ces attaques. Firefox passe maintenant à la version 57.0.4.
Cette mise à jour rend beaucoup plus difficile l’exécution de JavaScript au niveau du navigateur afin de mesurer précisément de courts intervalles de temps. En effet, il est nécessaire d’obtenir le timing des vitesses d’accès à la mémoire afin de déterminer quelles adresses mémoire ont été mises en cache.
Une adresse mémoire actuellement mise en cache doit avoir été consultée récemment. Il s’agit d’une astuce qui vous aide à comprendre la situation exacte lorsqu’une instruction a été exécutée de manière spéculative, et ce même si elle a été annulée après coup.
Billet inspiré de F**CKWIT, aka KAISER, aka KPTI – Intel CPU flaw needs low-level OS patches, sur Sophos nakedsecurity.
