Le rêve de tous les cybercriminels : une vulnérabilité permettant de hacker n'importe quel système, ou presque. Fort heureusement ça n'existe pas pensez-vous... Vous avez tort. La vulnérabilité existe. Elle est répertoriée CVE-2018-8897 et le CERT met en garde contre elle. Cette vulnérabilité a été découverte par les chercheurs Nick Peterson d'Everdox Tech et Nemanja Mulasmajic de Triplefault.io. Il la présenteront lors de Black Hat 2018, et, en attendant, ils en expliquent l'essentiel dans ce document technique.

Windows, les principales distributions Linux, les systèmes BSD (FreeBSD et DragonFly BSD, mais semble-t-il pas NetBSD et OpenBSD), macOS, sont tocuhés. Les systèmes virtualisés sont touchés également, Xen, KVM et VMware étant vulnérables selon le CERT. De son côté VMware précise que ses hyperviseurs ne sont pas touchés, mais que certains de ses produits, tels que  VMware vCenter Server, VMware Data Protection,  VMware vSphere Integrated Containers ou encore VMware vRealize Automation le sont effectivement.

En quoi consiste cette faille ?

Red Hat explique : Les processeurs modernes fournissent une infrastructure de débogage, utilisée par les concepteurs de systèmes et les développeurs d'applications pour déboguer leur logiciel. Elle comprend un ensemble de registres de débogage (DR0 ... DR7) et d'autres registres spécifiques à la machine (MSR). Un utilisateur peut configurer ces registres pour surveiller les événements, y compris l'accès à la mémoire (lecture ou écriture), l'exécution des instructions et l'accès aux ports d'Entrées/Sorties. Lorsqu'un tel événement se produit pendant l'exécution du programme, le processeur déclenche une exception de débogage (#DB) pour transférer le contrôle d'exécution au logiciel de débogage (par exemple, gdb). Celui-ci intercepte l'exception de débogage et permet à un développeur d'examiner l'état d'exécution du programme. Par exemple, pour surveiller l'accès à la mémoire en lecture / écriture à l'adresse '0x4007c7', l'utilisateur stocke l'adresse '0x4007c7' dans l'un des registres de débogage DR0 ... DR3, et le processeur lève #DB quand l'emplacement de mémoire '0x4007c7' est accédé pendant l'exécution de programme. Cet adressage dans le registre de débogage s'appelle Breakpoint.

        Mov% DR0, 0x4007c7

Généralement, les exceptions sont levées à la limite de l'instruction. Toutes les instructions précédant celle causant l'exception peuvent être complétées et celle causant l'exception est bloquée, de sorte qu'il est possible reprendre l'exécution une fois l'exception traitée. Dans quelques cas où l'instruction provoque un changement de tâche ou un changement de pile, ces exceptions sont déclenchées après l'instruction; notamment, l'instruction provoquant l'exception est alors autorisée à se terminer, comme cela se produit avec MOV SS ou POP SS.

Le CERT précise : Si l'instruction suivant l'instruction MOV SS ou POP SS est une instruction comme SYSCALL, SYSENTER, INT 3, etc. qui transfère le contrôle au système d'exploitation au niveau de privilège actuel (CPL) <3, une exception de débogage est délivrée après la fin du transfert à CPL <3. De telles exceptions #DB différées par MOV SS et POP SS peuvent entraîner un comportement inattendu.

Par conséquent, dans certaines circonstances, une exception de débogage pointant vers des données dans un anneau inférieur (pour la plupart des systèmes d'exploitation, niveau noyau 0 Ring) est disponible pour les composants du système d'exploitation dans Ring 3 Cela peut permettre à un attaquant d'utiliser les API du système d'exploitation pour accéder aux informations sensibles de la mémoire ou contrôler les fonctions de bas niveau du système d'exploitation. 

En l'occurrence, une élévation de privilège est possible sous Windows (ce que Microsoft confirme) ou macOS, ou un invité KVM. Il est possible de faire planter des systèmes Linux.

A qui la faute ?

Aux développeurs, aux fabricants de processeurs Intel et AMD ? Plutôt aux fabricants. Selon le CERT qui soulignent que les développeurs d'OS ont pu mal interpréter une documentation potentiellement peu claire ainsi que des exemples d'utilisation de ces instructions peu clairs également. Tous les développeurs auraient donc été ainsi trompés. Néanmoins, les découvreurs de la faille ne dédouanent pas totalement les développeurs pour autant. Dans le document mentionné ci-dessous, ils écrivent : C'est une faille de sécurité sérieuse et un oubli de la part des fournisseurs de systèmes d'exploitation en raison d'une documentation floue et peut-être même incomplète sur les règles d'exception de l'instruction POP SS et de son interaction avec la sémantique des interruptions

Est-ce grave docteur ?

Ca l'a été même si, à priori, il fallait être connecté à un système pour pouvoir l'attaquer par cette vulnérabilité, ce qui limitait malgré tout les possibilités. Fort heureusement, tous les éditeurs de systèmes ont publiés des correctifs, qu'ils convient d'appliquer immédiatement, comme le bon sens le suggère.