Encore des vulnérabilités sur les microprocesseurs : BranchScope, RyzenFall, MasterKey, Fallout, Chimera

Suite aux découvertes des vulnérabilités Spectre et Meltdown touchant les microprocesseurs, plusieurs travaux de recherche ont été lancés et bien entendu, de nombreuses vulnérabilités ont été découvertes.

Comme bien souvent en sécurité, quand un nouveau terrain de recherche est découvert, cela ouvre la voie à de nombreuses nouvelles trouvailles.

Correctif Microsoft pour Spectre et Meltdown

Pour rappel, Spectre et Meltdown sont des groupes de vulnérabilités publiées en janvier, permettant de contourner l’isolation de la mémoire des microprocesseurs modernes et donc d’en casser la sécurité. Pour faire simple, cela permet de lire la mémoire protégée du système d’exploitation depuis un processus dans privilèges spécifiques ou pire, de lire la mémoire d’une machine virtuelle depuis une autre machine virtuelle sur le même hyperviseur.

Les différents éditeurs de système d’exploitation et d’hyperviseurs ont publié des correctifs et certains les ont retirés du fait de problèmes d’instabilités.
En avril 2018, Microsoft a publié un nouveau correctif (KB4088878 et KB4088875) pour Windows 7 corrigeant une problématique sur son premier correctif car le remède était pire que le mal : il était possible, depuis n’importe quel processus, d’avoir un accès complet en lecture et écriture à toute la mémoire.

AMD

Les microprocesseurs (ou CPU) du fondeur AMD sont vulnérables à toute une série de vulnérabilités assez critiques.

Ce sont les familles de CPU EPYC et Ryzen qui sont touchées par ces problématiques.
A la suite de la publication du site web des chercheurs et d’un document assez laconique, de nombreuses critiques ont été formulées par la communauté. Certains ont enquêté afin de comprendre qui étaient les gens derrière ces découvertes : https://www.gamersnexus.net/industry/3260-assassination-attempt-on-amd-by-viceroy-research-cts-labs

Pour résumer :

  • Les vulnérabilités sont présentées de façon alarmiste et agressive ;
  • Leur avertissement indique clairement qu’ils ont un intérêt économique à publier ces vulnérabilités ;
  • Un des fondateurs est lié à un fond d’investissement ;
  • Les vidéos ont été filmées sur un fond vert ;
  • Le blog Viceroy (qui est clairement orienté) semble lié aux chercheurs.
    Cette affaire ressemble donc fortement à une tentative d’influencer le cours de l’action AMD, mais avec des vulnérabilités réelles.

Tout ceci a poussé les chercheurs à publier un second papier, détaillant un peu plus les vulnérabilités : https://safefirmware.com/Whitepaper+Clarification.pdf

Ils n’y donnent pas vraiment plus de détails techniques :

  • Les vulnérabilités RyzenFall et Fallout sont des exécutions de code au niveau du microcode du CPU, permettant de contrôler totalement l’ordinateur, sans que le système d’exploitation ne puisse le détecter ;
  • Les vulnérabilités Masterkey permettent d’exécuter du code au niveau d’AMD Platform Security Processor (PSP), un équivalent d’Intel Management Engine, permettant de gérer le démarrage sécurisé de l’ordinateur et toute sa sécurité. A priori il s’agit d’un problème de vérification de signature permettant de contourner cette mesure de sécurité ;
  • Les vulnérabilités Chimera seraient un ensemble de portes dérobées permettant, là encore, de prendre le contrôle de l’ordinateur.

BranchScope

Cette vulnérabilité est assez similaire à la vulnérabilité Spectre et permet à un processus (un logiciel 😉) d’accéder à la mémoire d’un autre processus s’il s’exécute sur le même cœur du CPU : http://www.cs.ucr.edu/~nael/pubs/asplos18.pdf

L’attaque repose sur l’historique de la prédiction de branchement. Le principe est d’arriver à générer des collisions dans l’historique de la prédiction de branchement d’un autre processus, c’est à dire de générer des prédictions de branchement similaires. Ceci permet de trouver les adresses de la mémoire utilisée par le processus ciblé. Cela peut être particulièrement gênant dans un environnement virtualisé comme un hébergeur Cloud de type AWS ou Azure.

Spectre Next Generation

Huit nouvelles vulnérabilités du même type que Spectre ont été découvertes par des chercheurs allemands et ont une portée assez importante car elles permettent de contourner l’isolation que peut apporter la virtualisation en lisant la mémoire d’une machine virtuelle depuis une autre.
https://thehackernews.com/2018/05/intel-spectre-vulnerability.html

CVE-2018-8897

Nick Peterson (chercheur en sécurité) et Nemanja Mulasmajic (développeur chez Riot Games) ont trouvé une vulnérabilité du même ordre que Meltdown, mais pire, touchant toutes les architectures de microprocesseur : Intel, AMD et même IA-32 😊.

Cette vulnérabilité permet tout simplement une élévation de privilège grâce aux instructions MOV SS ou POP SS. Pour faire simple, lorsque les données ou le pointeur de la pile (stack segment) est modifié, jusqu’à la prochaine instruction, les interruptions du BIOS (les appels réels aux périphériques : lecture/écriture, affichage…) sont différées, c’est-à-dire qu’il est possible d’injecter ses propres instructions qui seront ensuite exécutées avec les privilèges les plus élevés.

Ce n’est à priori pas une faille de sécurité mais une fonctionnalité permettant d’écrire en même temps sur le pointeur de la pile et les données de la pile.
Voici un article détaillant la technique et présentant un code d’exploitation : https://blog.can.ac/2018/05/11/arbitrary-code-execution-at-ring-0-using-cve-2018-8897/

Un code d’exploitation (de démonstration) vient d’être publié : https://github.com/can1357/CVE-2018-8897.

Voici le document détaillant la vulnérabilité : http://everdox.net/popss.pdf.

Là encore, toujours les mêmes reflexes :

  • Analyser les risques à corriger/ne pas corriger pour chaque composant (si le correctif est disponible) ;
  • Planifier le plan de déploiement des correctifs, si possible en débutant par une plateforme de test/dev/intégration et en passant ensuite des tests fonctionnels pour valider la non-régression ;
  • Déployer les correctifs.

Voici un processus que nous avions mis en place pour un client du luxe :

processus-vulnerabilites

Voici quelques correctifs que j’ai pu trouver :

Dans le majorité des cas, le correctif est inclus dans la mise à jour automatisée du composant.

Tout ceci me rappelle l’interview de Jean-Jacques Quisquater sur NoLimitSecu où il révèle qu’une bonne partie de ces vulnérabilités est connue depuis des décennies, ce qui est peu rassurant quant aux probables exploitations qui ont été réalisées depuis : https://www.nolimitsecu.fr/interview-de-jean-jacques-quisquater/.

Sale temps pour la sécurité des microprocesseurs...