Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.
Récemment un Un chercheur en sécurité de Google a révélé, à travers un article de blog, le découverte d'une nouvelle vulnérabilité (CVE-2023-23583) sur les processeurs Intel, nom de code Reptar, qui affecte plusieurs processeurs Intel de bureau, mobiles et serveurs, mais surtout les systèmes cloud exécutant les machines virtuelles de différents utilisateurs.
Vulnérabilité "Reptar" permet au système de se bloquer ou de planter lors de l'exécution de certaines opérations sur des systèmes invités non privilégiés. Théoriquement, la vulnérabilité peut être utilisée pour élever les privilèges du troisième anneau de protection à zéro (CPL0) et échapper aux environnements isolés, mais ce scénario n'a pas encore été confirmé dans la pratique en raison de difficultés de débogage au niveau de la microarchitecture.
L'équipe d'ingénierie en matière de sécurité des informations de Google a signalé la vulnérabilité à Intel, qui l'a divulguée aujourd'hui. Grâce à une collaboration minutieuse entre Google, Intel et les partenaires industriels, des mesures d'atténuation ont été mises en œuvre et les employés de Google et nos clients sont protégés.
Selon le chercheur, La vulnérabilité est présente dans un grand nombre de familles de processeurs Intel et le problème apparaîtrait sur les processeurs Intel Core de XNUMXe génération et les processeurs Xeon Scalable de XNUMXe génération, ainsi que sur les processeurs Xeon E/D/W.
À propos de Reptar
Il est mentionné que la vulnérabilité est dû au fait que l'exécution d'une instruction "REP MOVSB" codée avec un préfixe "REX" Redondant (un préfixe à un octet) entraîne un comportement indéfini. Le préfixe REX peut fournir des bits supplémentaires à l'instruction suivante à utiliser comme opérandes, permettant ainsi de coder les 16 registres à usage général possibles, et ces bits facultatifs donnent la possibilité de coder des registres plus généraux dans l'instruction suivante.
En août, notre processus de validation a produit une affirmation intéressante. Il a découvert un cas dans lequel l'ajout de préfixes REX redondants à une opération optimisée de "rep movs" FSRM semblait provoquer des résultats imprévisibles.
Nous avons observé un comportement très étrange lors des tests. Par exemple, des branchements vers des emplacements inattendus, des branchements inconditionnels qui sont ignorés et le processeur n'enregistre plus avec précision les instructions d'appel du pointeur d'instruction xsaveo.
Fait intéressant, en essayant de comprendre ce qui se passait, nous voyions un débogueur signaler des états impossibles.
Le problème a été découvert lors de tests de préfixes redondants, ce qui en théorie devrait être ignoré, mais qui en pratique provoquait des effets étranges, tels que l'ignorance des branches inconditionnelles et l'interruption de la sauvegarde du pointeur dans xsave et des instructions d'appel. Une analyse plus approfondie a montré que l'ajout d'un préfixe redondant à l'instruction « REP MOVSB » entraîne une corruption du contenu du tampon ROB (ReOrder Buffer) utilisé pour commander les instructions.
Une caractéristique intéressante du x86 est que le décodage des instructions est généralement assez détendu. Si vous utilisez un préfixe qui n'a pas de sens ou qui entre en conflit avec d'autres préfixes, il ne se passera pas grand-chose, il sera généralement simplement ignoré.
Ce fait est parfois utile ; Les compilateurs peuvent utiliser des préfixes redondants pour compléter une seule instruction jusqu'à une limite d'alignement souhaitable.
L'erreur serait due à un calcul incorrect de la taille de l'instruction "MOVSB". avec un préfixe excessif, ce qui entraîne une violation de l'adressage des instructions écrites dans le tampon ROB après MOVSB et un déplacement du pointeur d'instruction.
Cette désynchronisation peut se limiter à l'interruption des calculs intermédiaires avec restauration ultérieure de l'état intégral. Mais si vous bloquez plusieurs cœurs ou threads SMT en même temps, cela peut causer suffisamment de dommages à l’état de la microarchitecture pour provoquer son crash.
Un examen interne d'Intel a également montré que la vulnérabilité pourrait être exploitée pour élever les privilèges sous certaines conditions.
Enfin, il convient de mentionner que pour tester l'intégrité des systèmes, un utilitaire a été publié ce qui crée les conditions pour la manifestation de vulnérabilités, en plus du fait que la vulnérabilité en question a été corrigée dans la mise à jour du microcode 20231114.
Si vous intéressé à en savoir plus, vous pouvez vérifier les détails dans le lien suivant.