Warning message

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

Attaques noyau « Side-Channel Kernel » - CVE-2017-5754 CVE-2017-5753 CVE-2017-5715

Public Date:
Updated -
Status
Ongoing
Impact
Important

Red Hat a été informé de plusieurs problèmes d'implémentations micro-architecturales (hardware) affectant les microprocesseurs modernes nécessitant des mises à jour des noyaux Linux, et/ou des composants associés à la virtualisation en relation à la mise à jour du microcode. Un attaquant sans privilège peut exploiter cette faille pour passer outre les restrictions d'accès conventionnelles à la mémoire, normalement inaccessible car pourvue de privilèges d'accès, et la lire. On compte 3 CVE connues liées à ce problème en combinaison aux architectures Intel, AMD, et ARM. Nous savons également qu'il existe d'autres failles de sécurité liées à d'autres architectures, comme System Z d'IBM, et POWER8 (Big-Endian et Little Endian) ou Power9 (Little Endian).

Contexte

On a découvert un problème qui touche l'industrie dans son ensemble sur la manière dont de nombreux microprocesseurs modernes implémentent, de par leur design, une exécution spéculative d'instructions (une technique d’optimalisation de performance souvent utilisée). Il existe trois principales variantes à ce problème qui diffèrent sur la façon dont l'exécution spéculative puisse être exploitée. Toutes les trois s'appuient sur le fait que les microprocesseurs modernes de haute performance implémentent à la fois l'exécution spéculative, et utilisent les caches de données de niveau 1 VIPT (Virtually Indexed, Physically Tagged) qui peuvent être assignés accompagnés de données dans l'espace d'adresse virtuelle du noyau dans de tels cas.

Les deux premières variantes tirent avantage de l'exécution spéculative en évitant divers contrôles de sécurité limitrophes (CVE-2017-5753), ou en faisant une injection de branchement cible (CVE-2017-5715), ce qui amène le code du noyau à coder à une adresse sous le contrôle de l'attaquant pour effectuer une exécution spéculative. On regroupe ces deux variantes sous le nom de « Spectre ». Elles dépendent d'une séquence d'instructions définie avec précision dans le code privilégié, et sur le fait que les accès à la mémoire peuvent entraîner des assignations de données dans le cache niveau 1 du microprocesseur, y compris pour des instructions exécutées de manière spéculative qui ne sont jamais réellement validées. Par conséquence, un attaquant non privilégié peut exploiter ces failles de sécurité pour lire une mémoire privilégiée par le biais d'attaques « Cache Side-channel ». Ces variantes peuvent être utilisées non seulement pour franchir les limites de sécurité syscall (variante #1 et variante #2) mais aussi les limites de sécurité d'hôtes/invités (variante #2).

La troisième variante (CVE-2017-5754) s'appuie sur le fait que, sur les microprocesseurs concernés, lors de l'exécution spéculative de failles de permissions (instructions), la génération d'une exception normalement déclenchée par un accès frauduleux est supprimée jusqu'à ce que le bloc d'instruction complet soit supprimé. Les chercheurs appellent cette faille « Meltdown ». De plus, les accès mémoire qui suivent peuvent entraîner une assignation de données dans le cache de données au niveau L1, même quand ils référencent des emplacements de mémoire normalement inaccessibles. Par conséquence, un attaquant local non privilégié peut utiliser cette faille pour lire la mémoire (y compris les emplacements de mémoire physique arbitraire sur un hôte) privilégiée (dans l'espace noyau) en opérant des attaques « Cache Side-channel » ciblées.

Remerciements

Red Hat remercie Google Project Zero d'avoir signalé ces incidents.

Références supplémentaires

Vous avez questions? Session de wébinaire à la demande.

Qu'est-ce que « Meltdown » et « Spectre » veulent dire ? Voici ce que vous devez savoir.

https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html 

https://meltdownattack.com/

Impacts de performance de la faille - Description et correctifs de sécurité pour CVE-2017-5754 CVE-2017-5753 et CVE-2017-5715

Contrôler l'impact du microcode et des correctifs de sécurité sur la performance des vulnérabilités CVE-2017-5754 CVE-2017-5715 et CVE-2017-5753 avec les paramètres ajustables Red Hat Enterprise Linux Tunables

Quel microcode de CPU est disponible via package microcode_ctl afin de mitiger la vulnérabilité CVE-2017-5715 (variante 2) ?

Références de produits Red Hat supplémentaires

Options pour résoudre CVE-2017-5753 sur XEN platform

Impact de CVE-2017-5754, CVE-2017-5753, et CVE-2017-5715 sur les produits de virtualisation de Red Hat

Impact de CVE-2017-5754, CVE-2017-5753, et CVE-2017-5715 sur Red Hat OpenStack

Satellite 6 Comment fournir des errata Meltdown/Spectre aux Hôtes de contenu (CVE-2017-5753, CVE-2017-5754, et CVE-2017-5715)

Produits affectés

Red Hat Product Security a évalué l'impact de sécurité à un niveau Important.

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 Atomic Host

  • Red Hat Enterprise MRG 2

  • Red Hat OpenShift Online v2

  • Red Hat OpenShift Online v3

  • Red Hat Virtualization (RHEV-H/RHV-H)

  • Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)

  • Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7

  • Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7

  • Red Hat OpenStack Platform 8.0 (Liberty)

  • Red Hat OpenStack Platform 8.0 (Liberty) director

  • Red Hat OpenStack Platform 9.0 (Mitaka)

  • Red Hat OpenStack Platform 9.0 (Mitaka) director

  • Red Hat OpenStack Platform 10.0 (Newton)

  • Red Hat OpenStack Platform 11.0 (Ocata)

  • Red Hat OpenStack Platform 12.0 (Pike)

Bien que les conteneurs Linux de Red Hat ne soient pas directement touchés par les problèmes de noyaux, leur sécurité dépend de l'intégrité de l'environnement du noyau de l'hôte. Red Hat 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 catalogue des Conteneurs Red Hat, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat. Pour protéger l'accès des conteneurs utilisés, vous devrez veiller à ce que l'hôte du conteneur ( comme Red Hat Enterprise Linux ou Atomic Host) ait bien été mis à jour pour éviter la possibilité de ces attaques. Red Hat a créé une mise à jour d'Atomic Host pour ce cas d'utilisation.

Description et impact de l'attaque

Les attaques décrites dans cet article s'appuient sur l'exploitation abusive de la fonction d'exécution spéculative des microprocesseurs modernes haute performance. Ces processeurs modernes procèdent à une optimisation, de par leur design, nommée OoO (Out-of-Order) du fait que les microprocesseurs commencent à exécuter des instructions indépendantes dès que leurs dépendances de données sont disponibles (le fameux modèle « data flow ») au lieu de toujours exécuter des instructions en suivant l'ordre déterminé par le programmeur via leurs binaires d'applications. L'illusion qu'une exécution séquentielle est maintenue au sein du processeur par le biais d'un réordonnancent des divers structures internes qui protègent ces états d'exécution intermédiaire du processeur et qui présentent les résultats dans l'ordre. L'exécution OoO (Out-of-Order) a été inventée par Robert Tomasulo en 1967 et s'appliquaient aux anciennes structures IBM. Dans les décennies qui ont suivi, cette fonctionnalité est devenue standard et s'applique à presque tous les microprocesseurs.

Une extension du modèle d'exécution dé-séquentialisée OoO (Out-of-Order) ajoute des algorithmes de prédiction de branche très sophistiqués qui visent à prédire si un chemin donné (branche) du code logiciel sera exécuté. Une branche peut être considérée comme changeant le flux d'instructions qui sont exécutées par le processeur en réponse à un "if", déclaration de la forme : "si cela est vrai, alors faire A, sinon faire B". La condition selon laquelle une branche est prise ou non prise dépend souvent de données qui ne sont pas immédiatement disponibles (par exemple, parce qu'elles nécessitent un téléchargement de mémoire (RAM) plus lent dans la hiérarchie interne du cache de microprocesseur). Étant donné que l'état de la branche peut ne pas être prêt en temps opportun, le processeur peut commencer à exécuter le chemin le plus probable de manière spéculative, en fonction de l'entrée du prédicteur de la branche. Les résultats de cette exécution sont stockés de telle manière que le chemin d'accès entier peut être écarté si la direction de branche spéculée s'avère plus tard être incorrecte. Ainsi, l'exécution spéculative est normalement complètement invisible au programmeur, ou à d'autres utilisateurs du même système.

Les attaques décrites dans cet article sont basées sur une effraction de la boîte noire qui correspond à l'état interne du microprocesseur lors de l'exécution spéculative. Plus particulièrement, les attaques s'appuient sur une technique connue sous le nom de « Cache Side-channel Analysis ». Pendant l'exécution spéculative, un processeur ne rendra pas les résultats intermédiaires disponibles en mémoire ou les registres visibles au programmeur, à d'autres processeurs, ou à d'autres applications en cours d'exécution. Pourtant, afin d'accéder à la mémoire dans les chemins de code spéculatifs, il doit mettre les données dans le cache du processeur. La technique de « Cache Side-channel Analysis » permet à un attaquant d'observer les allocations spéculatives (charges) dans les caches du système, même ceux qui proviennent de chemins d'exécution qui ont finalement été écartés. Un programme spécialement conçu peut ensuite être créé pour effectuer des charges dans le cache à partir d'emplacements de mémoire privilégiée de manière spéculative, et surveiller les résultats qui peuvent être utilisés pour déduire le contenu de cette mémoire privilégiée.

La façon de déclencher l'exécution spéculative du CPU est par les branches. Un attaquant peut commencer par former le prédicteur de branche afin qu'il croie qu'une branche particulière du code de noyau est prisée (ou non). La fois suivante, lorsque la branche exécute, le processeur commencera à exécuter le code dans la direction choisie par l'attaquant. Si l'attaquant choisit un chemin d'accès qui charge une valeur en provenance de la mémoire, une telle charge sera exécutée de manière spéculative. Les attaques contre la prédiction de la branche peuvent (dans certaines implémentations de microprocesseurs affectées) être étendues autour du noyau/hyperviseur, permettant aux systèmes d'exploitation d'invités non privilégiés d'exercer une influence sur l'exécution de l'hyperviseur et, combinée à une « Side-channel Analysis », extraire la mémoire confidentielle de l'hyperviseur.

Les effets de l'exécution spéculative peuvent être, en fait, encore plus étendus. Étant donné que l'état interne du microprocesseur n'est pas visible au programmeur, ou à d'autres utilisateurs ou applications fonctionnant sur le système, le processeur peut procéder à des accès de données spéculatifs avant même de vérifier s'ils sont autorisés. Les contrôles d'autorisation se produiront en parallèle et finiront par mettre fin à la spéculation avant de retirer les instructions spéculatives et de rendre leurs résultats d'exécution visibles à l'extérieur du processeur. Si le processeur utilise de façon spéculative des données mises en cache dans la mémoire avant de terminer les vérifications d'autorisation, il est alors possible d'observer ces données en les utilisant dans les accès mémoire qui vont suivre.

Les vérifications d'accès de page de l'unité de gestion de la mémoire (MMU) représentent un des exemples de contrôle d'autorisation. La pagination, également connue sous le nom de mémoire virtuelle, est une fonction standard des microprocesseurs de haute performance. Elle permet au système d'exploitation de contrôler le mappage des adresses virtuelles dans les adresses physiques de la mémoire RAM du système, et limite également les accès aux adresses virtuelles par le biais de bits de contrôle d'accès. Par exemple, une page peut être marquée comme étant « en lecture seule » (de sorte que les écritures provoquent une exception de défaut de page) ou « mémoire du noyau » (de sorte que les accès en mode utilisateur provoquent une exception de défaut de page).

Étant donné que les contrôles d'autorisation du processeur font que les applications utilisateur ne peuvent pas accéder à la mémoire du noyau, il est pratique courante dans l'industrie que les noyaux du système d'exploitation (y compris Linux) mappent les adresses de mémoire virtuelle du noyau dans le même espace d'adressage que celui des applications utilisateur. Cela crée un avantage de performance important car les applications utilisent fréquemment les appels système fournis par le noyau, et changer d'espaces d'adressage à chaque appel système entraînerait une surcharge de performances significative. Chaque changement nécessiterait le vidage (invalidant) du contenu de nombreuses structures de CPU internes, telles que les TLB (Translation Lookaside buffers) qui cachent des traductions de mémoire virtuelle à physique et accélèrent l'utilisation de la mémoire virtuelle.

Aussi, le partage des tables de pages entre le noyau et les applications utilisateur permet un autre type d'attaque contre l'exécution spéculative. Dans ce cas, pendant la phase préparatoire, l'attaquant incite le noyau à charger une adresse virtuelle "intéressante" dans le cache de données de niveau 1 (L1) du processeur. Le cache de données L1 est généralement organisé selon une technique connue sous le nom de VIPT (Virtually Indexed, Physically Tagged), qui permet la traduction d'adresses virtuelles en adresses physiques et les contrôles d'autorisation se produisent en parallèle à l'accès. En présence d'un espace d'adressage virtuel partagé, les adresses virtuelles privilégiées du noyau peuvent être accédées de manière spéculative par le biais du cache L1 par le code utilisateur non fiable pendant l'exécution spéculative, et les valeurs chargées peuvent être utilisées alors par le chemin d'accès exécuté de façon spéculative. Un deuxième accès à la mémoire de façon spéculative peut ainsi remplir le cache d'une manière qui dépend du contenu de la mémoire privilégiée, et on peut observer les effets de dérivation de ces contenus.

Ces attaques « Side-Channel » de microprocesseur peuvent permettre à un utilisateur non fiable d'accéder à une machine pour extraire des informations confidentielles contenues dans la mémoire du noyau ou d'un hyperviseur privilégié, ainsi que d'autres applications ou machines virtuelles fonctionnant sur le même système. La solution de diminution de risque comprend un certain nombre d'étapes individuelles, qui peuvent oui ou non être requises selon la marque et le modèle exacts du microprocesseur, qui pourra, selon le cas, être plus ou moins vulnérable à une variante spécifique de l'attaque.

  • Séparation des espaces d'adressage virtuels de l'utilisateur et du noyau : cette opération est effectuée en raison d'une modification du design du noyau du système d'exploitation, connue sous le nom de KPTI (Kernel Page Table Isolation), mais on utilise parfois l'ancien nom « KAISER ».
  • Désactivation de la prédiction de branchement indirectement au moment de l'entrée dans le noyau ou dans l'hyperviseur : on a ajouté de nouvelles fonctionnalités à de nombreux microprocesseurs dans toute l'industrie grâce au microcode, au millicode, au firmware et à d'autres mises à jour. Ces nouvelles fonctionnalités sont exploitées par les mises à jour de Red Hat Enterprise Linux qui contrôlent leur utilisation.
  • Protéger des charges spéculatives certains emplacements de la mémoire : de telles charges doivent être annotées par de petites modifications au noyau Linux, qui ont été intégrées aux mises à jour de Red Hat.

Ces solutions logicielles, combinées au mises à jour de firmware, microcode, millicode, peuvent atténuer les attaques décrites dans cet article. Cependant, les solutions de mitigation ont un certain coût sur la performance système. Selon le système spécifique, la fabrication et le modèle des microprocesseurs, ainsi que les caractéristiques des charges de travail, l'impact performance peut être important. Red Hat prend une position proactive qui favorise la sécurité sur les performances, tout en permettant aux utilisateurs d'évaluer, à leur guise, leur propre environnement et de faire les compromis appropriés par activation (ou non) sélective des solutions proposées.

L'équipe d'ingénierie Red Hat Performance Engineering a créé un article dans la base de connaissances qui signale l'impact observé sur les performances pour un certain nombre de charges de travail représentatives et décrit les options qui se présentent aux utilisateurs pour désactiver certaines parties des correctifs de sécurité en vue de rétablir le niveau de performance désiré, si le client est rassuré sur le fait que ses ordinateurs sont bien physiquement isolés/protégés. D'autres données de performance seront publiées au fur et à mesure que les effets de cet incident se développeront.

Les équipes Red Hat Performance Engineering et Product Engineering ont produit un article de base de connaissance détaillant les paramètres ajustables pour activer ou non ces fonctionnalités de sécurité de manière sélective.

Détection & Diagnostique

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

Red Hat a créé une app Labs pour aider à la détection de l'exposition des systèmes à ces vulnérabilités. Les abonnés peuvent utiliser le lien suivant link pour accéder à notre outil Labs.

Déterminer si votre système est vulnérable. Utiliser le script de détection pour déterminer si votre système est actuellement vulnérable à cette faille de sécurité. Pour vérifier le légitimité du script, vous pouvez télécharger la signature GPG détachée également. La version du script en cours est 2.1.

Pour les abonnés exécutant les produits Red Hat Virtualization, il existe un article de base de connaissance qui a été créé pour vérifier que le microcode/firmware fourni par OEM ait bien été appliqué.

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. Tous les produits affectés doivent être corrigés pour les 3 variantes; CVE-2017-5753 (variante 1), CVE-2017-5754 (variante 2), et CVE-2017-5715 (variante 3).

REMARQUES

  • Meltdown est maintenant le nom officiel pour CVE-2017-5754 (variante 3)
  • Spectre est maintenant le nom officiel pour les deux variantes CVE-2017-5753 (variante 1) & CVE-2017-5715 (variante 2) combinées.
  • En raison de la nature des changements requis, un kpatch pour les clients opérant sur Red Hat Enterprise Linux 7.2 ou version supérieure de sera PAS mis à disposition.
  • La variante 2 peut être exploitée à la fois localement (avec le même SE) et via les limites de l'invité de virtualisation. Les correctifs nécessitent d'activer le microcode / firmware du CPU. Les abonnés sont priés de bien vouloir contacter leur fournisseur de matériel OEM afin d'obtenir le microcode / firmware qui conviennent pour leur processeur. Un article de base de connaissance supplémentaire, contenant davantage d'informations est disponible.
  • Bien lire l'Errata de sécurité. Les solutions n'ont pas été été publiées initialement pour toutes les architectures. Les solutions pour les architectures x86_64 mitigations n'incluent pas le noyaux 32 bits de Red Hat Enterprise Linux 6.
  • Pour les clients qui utilisent Red Hat Openstack Platform, un article de base de connaissances supplémentaire est également disponible.
  • Pour les clients qui utilisent Red Hat Satellite 6, un article de base de connaissances supplémentaire est également disponible. REMARQUE : veuillez utiliser le tableau ci-dessous pour pouvoir identifier rapidement l'ID RHSA que vous devez appliquer à vos systèmes.

Mises à jour pour les produits concernés

ProduitPackageAlerte / Mise à jourApplicable à la variante
Red Hat Enterprise Linux 7 (z-stream)noyauRHSA-2018:00071,2,3
Red Hat Enterprise Linux 7kernel-rtRHSA-2018:00161,2,3
Red Hat Enterprise Linux 7libvirtRHSA-2018:00292
Red Hat Enterprise Linux 7qemu-kvmRHSA-2018:00232
Red Hat Enterprise Linux 7dracutRHBA-2018:00422
Red Hat Enterprise Linux 7.3 Support Mise à jour Prolongé EUS**noyauRHSA-2018:00091,2,3
Red Hat Enterprise Linux 7.3 Support Mise à jour Prolongé EUS**libvirtRHSA-2018:00312
Red Hat Enterprise Linux 7.3 Support Mise à jour Prolongé EUS**qemu-kvmRHSA-2018:00272
Red Hat Enterprise Linux 7.3 Support Mise à jour Prolongé EUS**dracutRHBA-2018:00432
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé AUS***,****noyauRHSA-2018:00101,2,3
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé AUS***,****libvirtRHSA-2018:00322
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé AUS***,****qemu-kvmRHSA-2018:00262
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé AUS***,****dracutRHBA-2018:00622
Red Hat Enterprise Linux 6 (z-stream)noyauRHSA-2018:00081,2,3
Red Hat Enterprise Linux 6libvirtRHSA-2018:00302
Red Hat Enterprise Linux 6qemu-kvmRHSA-2018:00242
Red Hat Enterprise Linux 6.7 Support Mise à jour Prolongé EUS**noyauRHSA-2018:00111,2,3
Red Hat Enterprise Linux 6.7 Support Mise à jour Prolongé EUS**libvirtRHSA-2018:01082
Red Hat Enterprise Linux 6.7 Support Mise à jour Prolongé EUS**qemu-kvmRHSA-2018:01032
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé AUS***,****noyauRHSA-2018:00171,2,3
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé AUS***,****libvirtRHSA-2018:01092
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé AUS***,****qemu-kvmRHSA-2018:01042
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé AUS***noyauRHSA-2018:00221,2,3
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé AUS***libvirtRHSA-2018:01102
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé AUS***qemu-kvmRHSA-2018:01052
Red Hat Enterprise Linux 6.4 Support Mise à jour Avancé AUS***noyauRHSA-2018:00181,2,3
Red Hat Enterprise Linux 6.4 Support Mise à jour Avancé AUS***libvirtRHSA-2018:01112
Red Hat Enterprise Linux 6.4 Support Mise à jour Avancé AUS***qemu-kvmRHSA-2018:01062
Red Hat Enterprise Linux 6.2 Support Mise à jour Avancé AUS***noyauRHSA-2018:00201,2,3
Red Hat Enterprise Linux 6.2 Support Mise à jour Avancé AUS***libvirtRHSA-2018:01122
Red Hat Enterprise Linux 6.2 Support Mise à jour Avancé AUS***qemu-kvmRHSA-2018:01072
Red Hat Enterprise Linux 5 Support Mise à jour Prolongé ELS*noyauen attente1,2,3
Red Hat Enterprise Linux 5 Support Mise à jour Prolongé ELS*libvirten attente2
Red Hat Enterprise Linux 5 Support Mise à jour Prolongé ELS*qemu-kvmen attente2
Red Hat Enterprise Linux 5.9 Support Mise à jour Avancé AUS***noyauen attente1,2,3
Red Hat Enterprise Linux 5.9 Support Mise à jour Avancé AUS***libvirten attente2
Red Hat Enterprise Linux 5.9 Support Mise à jour Avancé AUS***qemu-kvmen attente2
RHEL Atomic HostnoyauImages produites le 5 janvier 20181,2,3
Red Hat Enterprise MRG 2kernel-rtRHSA-2018:00211,2,3
Red Hat Virtualization 4 (RHEV-H/RHV-H)redhat-virtualization-hostRHSA-2018:00471,2,3
Red Hat Virtualization 4 (RHEV-H/RHV-H)rhvm-applianceRHSA-2018:00451,2,3
Red Hat Virtualization 4 (RHEV-H/RHV-H)qemu-kvm-rhevRHSA-2018:00252
Red Hat Virtualization 4 (RHEV-H/RHV-H)vdsmRHSA-2018:00502
Red Hat Virtualization 4 (RHEV-H/RHV-H)ovirt-guest-agent-dockerRHSA-2018:00472
Red Hat Virtualization 4 (RHEV-H/RHV-H)rhevm-setup-pluginsRHSA-2018:00512
Red Hat Virtualization 3 (RHEV-H/RHV-H)redhat-virtualization-hostRHSA-2018:00441,2,3
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H)rhev-hypervisor7RHSA-2018:00461,2,3
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H)qemu-kvm-rhevRHSA-2018:00282
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H)vdsmRHSA-2018:00482
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H)rhevm-setup-pluginsRHSA-2018:00522
Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno) for RHEL7qemu-kvm-rhevRHSA-2018:00542
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7qemu-kvm-rhevRHSA-2018:00552
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7director imagesRHBA-2018:00641,2,3
Red Hat OpenStack Platform 8.0 (Liberty)qemu-kvm-rhevRHSA-2018:00562
Red Hat OpenStack Platform 8.0 (Liberty)director imagesRHBA-2018:00651,2,3
Red Hat OpenStack Platform 9.0 (Mitaka)qemu-kvm-rhevRHSA-2018:00572
Red Hat OpenStack Platform 9.0 (Mitaka)director imagesRHBA-2018:00691,2,3
Red Hat OpenStack Platform 10.0 (Newton)qemu-kvm-rhevRHSA-2018:00582
Red Hat OpenStack Platform 10.0 (Newton)director imagesRHBA-2018:00671,2,3
Red Hat OpenStack Platform 11.0 (Ocata)qemu-kvm-rhevRHSA-2018:00592
Red Hat OpenStack Platform 11.0 (Ocata)director imagesRHBA-2018:00681,2,3
Red Hat OpenStack Platform 12.0 (Pike)qemu-kvm-rhevRHSA-2018:00602
Red Hat OpenStack Platform 12.0 (Pike)director imagesRHBA-2018:00661,2,3
Red Hat OpenStack Platform 12.0 (Pike)ConteneursRHBA-2018:00701,2,3


*Un abonnement ELS actif est exigé pour pouvoir accéder à ce correctif. Veuillez contacter l'équipe de vente de Red Hat ou bien, votre représentant commercial particulier pour obtenir plus d'informations si votre compte n'a pas d'abonnement ELS actif.

**Un abonnement EUS actif est requis. Veuillez contacter  l'équipe de ventes de Red Hat ou votre représentant commercial personnel pour plus d'informations si votre compte n'a pas d'abonnement EUS actif en cours actuellement.

Qu'est-ce qu'un abonnement à Red Hat Enterprise Linux Support Mise à jour Prolongé EUS (Extended Update Support) ?

***Un abonnement AUS (Advanced Update Support) actif est exigé pour pouvoir accéder à ce correctif dans RHEL AUS.

Qu'est-ce qu'un abonnement AUS (Advanced Update Support) pour missions critiques ?

***Un abonnement TUS actif est exigé pour pouvoir accéder à ce correctif dans RHEL TUS.

*****Les abonnés doivent contacter leur fournisseurs de matériel OEM afin d'obtenir les versions de microcode / firmware de CPU les plus récents.

Mitigation

Il n'y a pas de solution connue d'atténuation des risques, sinon d'appliquer les mises à jour logiciel des fournisseurs, combinées au firmware / microcode CPU des OEM. Tous les clients de Red Hat doivent appliquer les solutions proposées par leur fournisseur pour corriger leurs CPU, et mettre à jour le noyau et les packages associés dès que les correctifs sont disponibles.

On conseille à nos clients de prendre une approche basée risque pour résoudre ce problème. Les systèmes qui exigent des niveaux de sécurité et de confiance élevés doivent être réglés en premier, et doivent être isolés des systèmes suspects jusqu'à ce qu'ils puissent être traités afin de réduire le risque d'exploitation.

Les clients qui exécutent des hyperviseurs XEN doivent être mis au courant des limitations techniques de ce logiciel ne pouvant pas complètement éliminer la variante 2 de la faille de sécurité, ni la variante 3 sur les invités para virtualisés. Red Hat a préparé un article de base de connaissance qui donne des informations détaillées sur la situation de XEN et des options disponibles pour les utilisateurs d'hyperviseurs XEN.

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.