Une vulnérabilité a été identifiée dans le noyau Linux 6.2 (CVE-2023-1998), entraînant la désactivation de la protection contre les attaques de type Spectre v2, permettant d'accéder à la mémoire d'autres processus s'exécutant dans différents threads SMT ou Hyper-Threading, mais sur un même cœur physique du processeur. Cette vulnérabilité, entre autres, peut être exploitée pour organiser des fuites de données entre des machines virtuelles dans des systèmes cloud. Ce problème ne concerne que le noyau Linux 6.2 et est causé par une mise en œuvre incorrecte des optimisations destinées à réduire les surcharges importantes liées à l'application de la protection contre Spectre v2. La vulnérabilité a été corrigée dans la branche expérimentale du noyau Linux 6.3.
Dans l'espace utilisateur, pour se protéger contre les attaques de type Spectre, les processus peuvent désactiver sélectivement l'exécution spéculative des instructions à l'aide de prctl PR_SET_SPECULATION_CTRL ou utiliser le filtrage des appels système basé sur le mécanisme seccomp. Selon les chercheurs ayant identifié le problème, une optimisation incorrecte dans le noyau 6.2 a laissé sans défense machines virtuelles au moins un grand fournisseur de cloud, malgré l'activation du mode de blocage des attaques spectre-BTI via prctl. La vulnérabilité se manifeste également sur des systèmes ordinaires serveurs avec le noyau 6.2, lors du démarrage desquels la configuration «spectre_v2=ibrs» est utilisée.
L'essence de la vulnérabilité réside dans le fait qu'en choisissant les modes de protection IBRS ou eIBRS, les optimisations introduites désactivaient l'application du mécanisme STIBP (Single Thread Indirect Branch Predictors), nécessaire pour bloquer les fuites lors de l'application de la technologie de multithreading simultané (SMT ou Hyper-Threading). Dans ce cas, seule la protection contre les fuites entre les threads est assurée par le mode eIBRS, mais pas par le mode IBRS, car dans ce dernier, le bit IBRS, qui protège contre les fuites entre les cœurs logiques, est vidé pour des raisons de performance lors du retour du contrôle vers l'espace utilisateur, ce qui rend les threads dans l'espace utilisateur non protégés contre les attaques de type Spectre v2.
Source : opennet.ru
