Attaque de noyau Side-channel via Speculative Store Bypass - CVE-2018-3639

Red Hat Product Security a été informé d'une vulnérabilité qui se trouve dans les microprocesseurs modernes et qui exige des mises à jour du noyau Linux, des composants liés à la virtualisation, et une mise à jour du microcode. Un attaquant non privilégié peut utiliser cette faille pour contourner des restrictions pour obtenir un accès en lecture à la mémoire privilégiée. Le numéro suivant a été assigné CVE-2018-3639 et la vulnérabilité est également appelée « Variante 4 » ou « Speculative Store Bypass ». Nous savons que ce problème affecte les CPU de diverses microarchitectures : les processeurs AMD, ARM, IBM POWER8, POWER9, SystemZ series, et Intel. Toutes les versions actuellement prises en charge de Red Hat Enterprise Linux, Red Hat OpenShift, Red Hat Virtualization et Red Hat OpenStack Platform sont affectées.

Un utilisateur malveillant non privilégié peut exploiter cette vulnérabilité pour lire la mémoire système privilégiée et/ou la mémoire à l'extérieur d'un environnement sandboxed à la manière d'un navigateur Web ou des temps d'exécution JIT.

Afin d'atténuer les effets de cette vulnérabilité, les administrateurs système doivent appliquer à la fois des mises à jour matérielles "microcode" et des correctifs logiciels qui permettent d'activer de nouvelles fonctionnalités. Actuellement, le microprocesseur microcode sera livré par les fabricants individuels, mais à une date ultérieure, Red Hat publiera les mises à jour testées et signées, au fur et à mesure que nous les recevrons.

Ce problème a été rendu public le 21 mai 2018.

Contexte

CVE-2018-3639 (aka “Speculative Store Bypass”) ouvre une nouvelle voie (comme la misprédiction de branche) qui peut être exploitée par l'intermédiaire d'une exécution spéculative Side Channel basée sur le cache pour contourner les mesures de sécurité et accéder à une mémoire privilégiée. Cette question est semblable à celle de la vulnérabilité CVE-2017-5753 (aka “Spectre v1”), sauf qu'elle tire parti de l'optimisation de la mémoire de contournement par la fonction Speculative Store Bypass à la place de la misprédiction de branche de Spectre v1.

Les processeurs informatiques modernes sont des systèmes très complexes. Ils exécutent une séquence d'instructions (un programme) dans le cœur, et stockent les résultats en mémoire.

Pour maximiser le nombre d'instructions exécutées ou pour améliorer les performances, les processeurs ajoutent plusieurs cœurs d'exécution, une mémoire cache plus rapide et utilisent diverses techniques telles que l'exécution hors commande, la prédiction de branche, l'exécution spéculative, le pré-extraction de données, le ré-ordonnancement de l'accès à la mémoire, la désambiguïsation de mémoire, etc.

Au fur et à mesure que les instructions sont exécutées, le processeur charge (en lecture) et stocke (en écriture) des données depuis / vers la mémoire principale. Avant que les instructions de chargement et de stockage puissent accéder aux données, l'adresse donnée par leur opérande doit être résolue, ex.

mov    [rbx + rcx], 0x0  :  stocke zéro(0) dans l'emplacement mémoire [rbx + rcx]
mov    rax, [rdx + rsi]   :  charge des données de l'emplacement mémoire [rdx + rsi] dans le registre RAX

Dans les deux cas, les adresses [rbx + rcx] et [rdx + rsi] sont résolues dans un emplacement mémoire avant que l'on puisse accéder aux données.

Un programme typique a beaucoup d'instructions d'actions de chargement (en lecture) et de stockage (en écriture) ; et parfois, les deux actions fonctionnent sur la même adresse mémoire. Pour maintenir l'état cohérent de la mémoire, les processeurs utilisent la mémoire tampon load-store-queue pour traiter les instructions de chargement (en écriture) et de stockage (en écriture). Lorsque les instructions de chargement et de stockage sont mises en file d'attente, l'instruction de chargement ne s'exécute pas tant que les adresses de toutes les instructions de stockage de la file d'attente ne sont pas connues.

Saisir Speculative Store Bypass :

Les processeurs modernes peuvent exécuter des instructions de chargement/stockage de façon désordonnée et spéculativement (lorsque les instructions de chargement (lecture) et d'écriture (écriture) sont présentes dans la file d'attente du magasin de chargement).

Le désambiguiseur de mémoire (MD) (Memory Disambiguator) prédit quel chargement ne dépend pas d'une instruction de stockage antérieure. De telles instructions de chargement (lecture) sont ensuite exécutées spéculativement pour charger des données à partir du cache de données L1, même lorsque l'adresse du magasin précédent n'est pas connue, contournant ainsi l'instruction de stockage (Store). Ceci renforce la performance globale en évitant la latence de la charge. Ainsi, si la prédiction était fausse et qu'un conflit entre les instructions de chargement et les instructions d'écriture était détecté, toutes les instructions qui suivront (et y compris) la charge spéculative seront ré-exécutées.

Remerciements

Red Hat souhaite remercier Ken Johnson du Microsoft Security Response Center (MSRC) et Jann Horn de Google Project Zero (GPZ).

Références supplémentaires

Vous avez questions ? Regardez cette vidéo de Red Hat sur SSBD

Red Hat Blog: Tout ce que vous voulez savoir sur Speculative Store Bypass​

Comment patcher mon environnement RHEV contre les attaques de noyau Side-Channel via la méthode Speculative Store Bypass CVE-2018-3639 ?

Le microcode du CPU est-il disponible via le package microcode_ctl ?

Site Google Project Zero Variant 4

Intel Advisory 

Analyse d'Intel de l'Exécution spéculative Side Channels

Mitigation pour l'Exécution spéculative Side Channel

Produits concernés

Red Hat Product Security a évalué l'impact de sécurité de CVE-2018-3639 au 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 Virtualization (RHEV-H/RHV-H)

• Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)

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

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director pour 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 noyau, 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

À la manière de la variante Spectre-1, le scénario Speculative Store Bypass ouvre un canal latéral (Side Channel). Cela permet à l'instruction de chargement (en lecture) d'accéder à une ancienne valeur à partir d'un emplacement mémoire, où une opération de stockage n'est pas encore validée. Si un attaquant est capable de contrôler l'ancienne valeur à l'emplacement de la mémoire, il peut ainsi lire la mémoire système privilégiée s'il le souhaite. Cela peut également être exploité par des processus exécutant dans des environnements d'exécution sandboxed, comme un navigateur web, JVM ou des moteurs d'exécution qui analysent et compilent le code source juste à temps (JIT) avant son exécution.

Impact sur la performance

Speculative Store Bypass ou Memory Disambiguation (MD) sont des méthodes d'optimisation employées pour améliorer l'efficacité du moteur d'exécution spéculative. Comme cela permet d'exécuter des instructions de chargement (lecture) sans attendre des instructions d'écriture antérieures, la latence de la chargement est ainsi réduite et cela améliore les performances.

En activant la solution de mitigation de la fonction Speculative Store Bypass, vous désactivez donc l'optimisation de la désambiguïsation de la mémoire (MD). Cela peut avoir un impact sur les performances du système. L'impact net sur les performances variera en fonction de la charge de travail du système.

En ce qui concerne les configurations par défaut, la position de Red Hat favorise la sécurité par rapport à la performance, tout en permettant aux utilisateurs d'évaluer leur propre environnement et de faire des compromis appropriés, en activant et désactivant sélectivement les diverses mesures d'atténuation. Red Hat travaille sur d'autres changements afin de réduire l'impact de la solution de mitigation initiale sur le rendement.

Des données supplémentaires sur le rendement seront publiées au fur et à mesure qu'elles seront disponibles.

Diagnostiquer votre vulnérabilité

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

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. La version du script en cours est 1.0.