Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

CVE-2018-12207 - Erreur de vérification machine lors du changement de format de page

Public Date: November 12, 2019, 6:00 pm
Updated -
Ongoing Status
Important Impact

Récapitulatif

Red Hat est conscient d'un problème d'implémentation micro-architectural (hardware) qui pourrait permettre à un attaquant local non privilégié de contourner les contrôles de sécurité système conventionnels pour provoquer un déni de service au niveau du système.


À l'heure actuelle, on sait que cette faille spécifique affecte les processeurs Intel au moins. Cette faille est matérielle et nécessite des mises à jour du noyau pour y remédier. Ce problème affecte toutes les versions de Red Hat Enterprise Linux 8 et antérieures.  

Détails techniques et contexte 

L’ erreur de vérification machine lors du changement de format de page a été assignée CVE-2018-12207 avec un impact de sévérité catégorisé Important.

Une faille a été trouvée dans le matériel informatique des microprocesseurs Intel lié à l'Instruction Translation Lookaside Buffer (ITLB) qui met en cache les traductions des adresses virtuelles des invités (et des hôtes) en adresses physiques, également appelé cache de traduction d'adresses, dédié aux instructions exécutables. Ceci fournit un niveau d'abstraction pour que les applications aient une vue simplifiée de la mémoire système. La fonctionnalité ITLB est transparente pour le logiciel et son utilisation améliore considérablement les performances.

Lorsque les instructions sont exécutées, leur adresse linéaire (ou virtuelle) est traduite à l'adresse physique correspondante. Ce mappage de l'adresse virtuelle à l'adresse physique, pour les instructions exécutables, est mis en cache dans l'ITLB.

Un logiciel privilégié (système d'exploitation ou Virtual Machine Monitor (VMM)) peut modifier la taille de la page (ex. 4KB, 2MB, 1GB) et/ou d'autres attributs dans les structures de pagination. En règle générale, ces modifications de structure de pagination doivent être suivies de l'invalidation des entrées ITLB mises en cache correspondant aux pages modifiées. Toutefois, cette invalidation de l'ITLB peut être retardée. Ce délai offre une fenêtre temporelle pendant laquelle un attaquant peut invoquer la récupération d’instructions, ce qui fait que le processeur utilise une traduction d'adresse mise en cache non valide depuis ITLB pour accéder à une adresse physique non valide, entraînant ainsi une exception d'erreur de vérification machine, et amène le système à passer à un état «hang» (suspendu).

Un attaquant privilégié à l'intérieur d'une machine virtuelle invitée peut contrôler les entrées de table de sa page invitée et créer un module de noyau malveillant capable d'exécuter des instructions spécifiques pour créer des entrées ITLB incohérentes sans vider correctement les entrées ITLB mises en cache, de sorte que lorsque les instructions qui suivent sont compromises par un certain nombre d’entrées ITLB incompatibles. Une telle condition déclenchera une erreur de vérification machine irrécupérable qui placera le processeur dans un état de suspension irrécupérable, résultant en un scénario DoS à l'échelle du système.

Les mises à jour de ces caches nécessitent une synchronisation avec les structures de données internes du processeur nécessitant l'utilisation d'instructions spécifiques du processeur (modifications INVLPG et CR3 en microcode). Un attaquant peut instruire un invité malveillant de demander un mappage pour un emplacement particulier, changer la taille de la page et réémettre une nouvelle requête avec la nouvelle taille de page sans émettre la séquence d'invalidation correcte requise pour invalider l'état du cache interne du CPU.

Remerciements

Le problème a été découvert en interne par Intel. Intel aimerait remercier Deepak Gupta.

Références supplémentaires

Qu'est-ce que l'IU

Qu'est-ce qu'une page de mémoire ?

Politique de mise à jour des errata Red Hat​​​​​​

Mise à jour de la plate-forme Intel Novembre 2019

Intel-SA-00210 

Il manque des informations sur le microcode ? Consulter KCS spécifique au microcode

Vous manquez d'information sur TSX ? Consulter KCS spécifique TSX



Produits d'impact

Les versions de produits Red Hat suivants sont affectées :

Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 8
Red Hat Atomic Host
Red Hat Enterprise MRG 
OpenShift Container Platform
Red Hat OpenShift Online
Red Hat Virtualization (RHV-H)
Red Hat OpenStack Platform (noyau d'envoi d'images)

Bien que les conteneurs Linux de Red Hat ne soient pas directement affectés par les problèmes du noyau, leur sécurité dépend de l'intégrité de l'environnement du noyau hôte. Red Hat vous recommande d'utiliser les versions les plus récentes de vos images de conteneurs. L'index de santé des conteneurs (Container Health Index), qui fait partie du Red Hat Container Catalog, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat. Pour protéger la confidentialité des conteneurs utilisés, vous devrez veiller à ce que l'hôte du conteneur (tel que Red Hat Enterprise Linux ou Atomic Host) ait bien été mis à jour pour éviter la possibilité de ces attaques. Red Hat a publié une mise à jour de Red Hat Enterprise Linux Atomic Host pour ce cas d'utilisation.



Diagnostiquer votre vulnérabilité

Utiliser le script de détection ci-dessous pour déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également.

Déterminer si votre système est vulnérable

Version en cours : 1.0

Action

Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles. On conseille aux clients d'appliquer les mises à jour qui conviennent immédiatement.

Mises à jour des produits concernés

ProduitPackageAlerte / Mise à jour
Red Hat Enterprise Linux 8 (z-stream)kernelRHSA-2019-3832
Red Hat Enterprise Linux 8 kernel-rtRHSA-2019-3833
Red Hat Enterprise Linux 8 kpatch


Red Hat Enterprise Linux 7 (z-stream)kernelRHSA-2019-3834
Red Hat Enterprise Linux 7kernel-rtRHSA-2019-3835
Red Hat Enterprise Linux 7kpatch
Red Hat Enterprise Linux 6 (z-stream)kernelRHSA-2019-3836
Red Hat Enterprise MRG 2kernel-rtRHSA-2019-3844
Red Hat Enterprise Linux 5 (z-stream)kernelAffecté (wontfix, hors support)
Red Hat Virtualization 4 pour Red Hat Enterprise Linux 7redhat-virtualization-host    

RHSA-2019-3860
Red Hat Virtualization 4.2 pour Red Hat Enterprise Linux 7.6redhat-virtualization-host    RHSA-2019-3860
Red Hat Enterprise MRG 2kernel-rtRHSA-2019:3844
Red Hat OpenShift Container Platform 4.1machine-os-content-container
Red Hat OpenShift Container Platform 4.2machine-os-content-container

Impact

Impact sur la performance :

  • Sur RHEL-7 et RHEL-8, nous avons mesuré que l'impact était principalement de l'ordre de 0 à 4 %.  Les applications sensibles à la latence avec de petites empreintes textuelles (p. ex., références réseau) et les applications à empreintes volumineuses (p. ex., les charges de travail des bases de données) avaient tendance à se situer dans cette plage. 

  • Sur RHEL-7 et RHEL-8, lorsque les mesures de mitigation sont actives, KVM convertira également les pages exécutables de 4Ko en pages volumineuses non exécutables en arrière-plan, pour récupérer la performance des pages qui ne contiennent plus de code. Ce processus de recouvrement peut provoquer de rares courtes pauses (~10-100 de microsecondes ou plus) chez l'invité ; si l'invité exécute une charge de travail sensible à la latence ou en temps réel, Red Hat recommande de désactiver le recouvrement de pages volumineuses par le paramètre kvm.nx_huge_page_recovery_ratio=0 nouvellement introduit.

  • Sur RHEL-6, l'impact sur les performances peut être plus sévère car les pages volumineuses de texte et de données sont décomposées en pages de 4K.

Système hôte/bare metal :

Les applications non privilégiées s'exécutant sur le système bare metal, sans virtualisation, peuvent ne pas être en mesure de modifier (ou de contrôler) les entrées de structure de pagination. Par exemple, un logiciel système non privilégié peut ne pas être en mesure de mettre à jour l'attribut de taille de page dans les structures de pagination et d'induire une exception d'erreur de vérification machine, ce qui entraîne le scénario DoS mentionné ci-dessus.

Hyperviseur/environnement invité virtuel :

Le vecteur d'attaque le plus important pour ce scénario DoS est un invité virtuel induisant une erreur de vérification de machine (MCE) sur le système hôte (ou hyperviseur), ce qui provoque la DoS sur de nombreuses machines virtuelles invitées fonctionnant sur l'hôte. C'est extrêmement grave pour les environnements cloud, où l'on ne peut pas faire confiance aux invités et au code s'exécutant à l'intérieur des invités.

Les mesures de mitigation de ce problème se présentent sous deux formes.

1. Une mise à jour du microcode matériel d'Intel permet d'activer le nouveau bit (6) du registre spécifique de machine (MSR de l’anglais Machine Specific Register) dans IA32_ARCH_CAPABILITIES MSR.

IA32_ARCH_CAPABILITIES[PSCHANGE_MC_NO=6]

La présence et l'état (0/1) de ce bit(6) indique si le CPU est vulnérable à ce problème de DoS ou non, et si les atténuations algorithmiques logicielles dans le noyau/hypervisor sont nécessaires ou non.

2. Les mises à jour logicielles du module Kernel/KVM prévoient les mesures d'atténuation suivantes pour prévenir ce problème

  • Rendre de grandes (ou énormes) pages (> 4KB) non exécutables. C'est-à-dire que le processeur ne sera pas capable d'exécuter une instruction résidant dans une page volumineuse (c'est-à-dire 2 Mo, 1 Go, etc.) sans provoquer un piège dans le noyau/hypervisor hôte."
  • Si une page volumineuse n'est pas exécutable et qu'une instruction est exécutée sur la page, KVM divise la page volumineuse en 4KB pages et donne la permission exécutable aux pages de 4KB.
  • Un nouveau paramètre de démarrage en ligne de commande kvm.nx_huge_pages=force/off/auto est introduit dans RHEL-7 et RHEL-8 pour activer/désactiver cette mesure de mitigation.
    • kvm.nx_huge_pages=offdésactive les mesures de mitigation, rend les grandes pages exécutables
      • L'option "mitigations=off" de la ligne de commande du noyau désactivera également ce CVE au démarrage du noyau.
    • kvm.nx_huge_pages=autoactive les mesures de mitigation, seulement si le CPU est affecté
    • kvm.nx_huge_pages=force   active les mesures de mitigation
    • Les pages /sys/module/kvm/parameters/nx_huge_pages peuvent être utilisées pour activer ou désactiver ce CVE à l'exécution, par exemple
      • echo off > /sys/module/kvm/parameters/nx_huge_pages
      • echo auto > /sys/module/kvm/parameters/nx_huge_pages
      • echo off > /sys/module/kvm/parameters/nx_huge_pages
  • Un nouveau paramètre de démarrage kvm en ligne de commande kvm.nx_huge_pages=0/1 est introduit dans RHEL-6 pour activer/désactiver cette mesure de mitigation.
    • kvm.no_huge_pages=0 désactive la mesure de mitigation
    • kvm.no_huge_pages=1 enable mitigation
    • L'atténuation est désactivée par défaut et ne peut pas être activée au moment de l'exécution.

3. La mise à jour Kernel/KVM introduit également l'interface sysfs ci-dessous pour que les utilisateurs puissent interroger le système sur la vulnérabilité et savoir si les mesures d'atténuation sont activées ou non.

$ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit
- Non affecté
- Mesure d’atténuation KVM : Diviser les pages volumineuses
- Vulnérabilité KVM : aucune mesure de mitigation activée

Mesure de mitigation

La seule mesure de mitigation connue pour les produits Red Hat impactés par cette faille est l'application d'une mise à jour du paquet du noyau ou un kpatch.

Red Hat a créé des correctifs dans la technologie de virtualisation KVM qui empêchent les systèmes d'exploitation invités de tirer parti de cette faille. D'autres fournisseurs de virtualisation ont peut-être mis au point des correctifs spécifiques. Veuillez consulter le support de votre fournisseur de virtualisation pour obtenir des informations sur les mises à jour ou les atténuations.