La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.
La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque...
La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).
[^] # Re: Meltdown, seulement Intel ?
Posté par jeberger (site web personnel) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
En fait l'article décrit trois attaques :
La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.
La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque...
La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).