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.
Vous trouverez des recommandations supplémentaires pour les abonnés utilisant des systèmes basés AMD dans cet article de base de connaissance.
Comments