Intel se retrouve avec (encore) une faille de plus : CacheOut

Depuis l’affaire Meltdown et Spectre, le web regorge de ressources relatant l’une des failles les plus graves de la décennie, remettant en cause le traitement de données non sûres par le processeur par le biais du mécanisme de spéculation. Depuis, des rustines matérielles et logicielles ont vu le jour — aux impacts variés sur les performances — basées sur l’effacement des caches après les opérations sensibles. Il devient ainsi impossible de retrouver par canal auxiliaire quel endroit de ce cache avait été touché par l’exécution spéculative, et donc bloquait la faille.

Mais c’était sans compter les travaux de chercheurs de l’Université du Michigan et de l’Université d’Adelaide. Grâce à ces trouvailles, il est possible de retransférer les données évincées manuellement du cache par les patchs du microcode pour retrouver l’état originel, ce qui permet de retrouver les traces de l’exécution spéculative et ainsi réutiliser l’idée de Spectre, Meltdown et leurs variantes.

Nommé CacheOut (CVE-2020-0549 pour les intimes), cette vulnérabilité se base sur la présence d’une mémoire tampon appelée Fill Buffer en amont du cache, permettant de masquer les transferts entre à la fois le CPU et le L1, mais aussi entre le L1 et le L2. Or, si des effacements du cache pourraient être utilisé comme correctifs à Spectre, ce n'est souvent pas le cas pour des raisons de coût. Il alors est possible d’utiliser les extensions de gestion de mémoires transactionnelles en avortant sciemment une section afin d'éjecter un morceau de données du cache puis récupérer son contenu en manipuler le comportement de ce Fill Buffer. En clair, effacer des données du L1 pour les repositionner par la suite... Caramba, un correctif pour rien !

Et un logo de plus, un !

Bien entendu, nous retrouvons une contagion possible similaire à Spectre : pas de cloisonnement entre hyperthreads, threads, processus, VM, mode utilisateur ou noyau, et même à l’intérieur des enclaves SGX. Autant dire qu’une partie du travail logiciel est à reprendre... Au niveau des CPU impactés, la casse est limitée aux processeurs héritant de Skylake — présence des extensions TSX oblige —, jusqu’à la 10ème génération nommée Amber Lake-Y en passant par Coffee Lake. Notez tout de même que les récentes rustines concernant la faille TAA pallient en partie Cacheout (puisqu’il est possible de désactiver les extensions TSX. Youpi...), et que l’opération est loin d’être aussi simple que cela : passer outre les protections du noyau prend également un temps précieux (quelques dizaines de secondes tout de même, sans compter l’écriture du virus !), tout comme sortir d’un hyperviseur ou entrer dans une enclave protégée par SGX. Pour une évaluation plus pratique, il faut environ 15 secondes pour récupérer le contenu d’une ligne de cache de 64 octets, et  le taux de succès pour fuiter une clef AES a été de 2 pour 1000 sans traitement statistique ultérieur des données.

Pour en revenir aux autres moyens de colmater la brèche, il faudra désactiver l’HyperThreading, vider complètement la partie du cache L1 dédiée aux données puis vérifier que tel est bien le cas via une instruction spécifique, sachant qu’un microcode devrait arriver prochainement à ce sujet. Par ailleurs, du fait du TSX non présent sur ses modèles, AMD ressort une fois de plus indemne de ces attaques : l’avantage de ne pas s’être aventuré dans une nouvelle fonctionnalité.

Néanmoins, cette faille est tout aussi préoccupante pour les serveurs de calcul, en particulier pour des usages typés cloud où des données confidentielles ne doivent en aucun cas tomber entre de mauvaises mains. De quoi s’attendre à des pertes de performances supplémentaires chez les bleus, ce qui n’est pas sans nous inquiéter quant à la pérennité son activité de concepteur de processeurs !