AMD enquête sur de graves failles dans ses processeurs Ryzen et Epyc

Dans un communiqué de presse laconique, AMD vient d’indiquer enquêter sur les affirmations de CTS Labs selon lesquelles certains de ses processeurs présenteraient de graves vulnérabilités.

Fondé en 2017 par Yaron Luk-Zilberman, Ilia Luk-Zilberman et Ido Li On, trois anciens de l’unité 8200 de l’armée israélienne, CTS Labs était jusqu’ici largement inconnue. Mais l’entreprise assure avoir découvert 13 vulnérabilités critiques affectant les processeurs Ryzen et Epyc d’AMD, et réparties en quatre classes : Ryzenfall, Masterkey, Fallout, et Chimera.

Sur un site créé pour l’occasion, les équipes de CTS Labs pointent en particulier des vulnérabilités affectant l’enclave sécurisée des puces AMD, le Secure Processor. Celles-ci permettraient de contourner les dispositifs de sécurité de Windows basés sur la micro-virtualisation, mais également, et surtout, d’exécuter du code malveillant dans l’enclave, en s’y assurant une persistance remarquable, voire même de provoquer des dommages physiques sur les machines concernées.

Certaines vulnérabilités sont liées au microcode des processeurs, leur firmware. Mais pas uniquement : Chimera recouvrirait deux portes dérobées dans les puces Ryzen et Ryzen Pro, l’une présente dans le firmware, mais l’autre directement dans le hardware. De quoi injecter du code malveillant dans la puce et prendre une position d’attaquant permettant « d’échapper virtuellement à toute solution de sécurité du poste de travail sur le marché ».

Les auteurs ne fournissent pas de détails techniques sur les vulnérabilités évoquées, une démarche qu’ils justifient par un souci de « sûreté du public ».

Certaines personnes semblent toutefois avoir été en mesure de se pencher sur les travaux de CTS Labs. Ainsi, Gadi Evron, fondateur de Cymmetria, qui a eu l’occasion de croiser Ilia Luk-Zilberman par le passé, assure que les affirmations sont bien réelles et « confirme » l’existence de démonstrateurs d’exploitation des vulnérabilités. Il précise au passage que ces dernières ne nécessitent pas d’accès physiques aux machines, mais la capacité d’exécuter du code avec les droits d’administrateur. Pour les puces susceptibles de contenir des portes dérobées, il évoque les contrôleurs référencés ASM1042, 1142 et 1143.

So this https://t.co/vYktqat10K business... CTS Labs asked us to review their research last week, and sent us a full technical report with PoC exploit code for each set of bugs.

— Dan Guido (@dguido) March 13, 2018

Dan Guido, Pdg de Trail of bits, assure avoir également eu l’occasion d’examiner les détails techniques et les démonstrateurs de CTS Labs. Pour lui, « les bugs sont réels, précisément décrits dans le rapport technique (qui n’est pas public, à ma connaissance), et le code d’exploitation fonctionne ».

Mais Kevin Beaumont, dans un billet de blog, souligne en particulier deux points : « tous les bugs nécessitent un accès administrateur ou root pour accéder à l’exploitation […] Tous les bugs requièrent la capacité d’exécuter du code ». Deux points qui constituent, selon lui, une base de protection « significative » contre l’exploitation des vulnérabilités.

En fait, pour Tavis Ormandi, du projet Zéro de Google, rien dans les vulnérabilités mentionnées par CTS Labs « rien dans ces vulnérabilités ne compte tant que l’attaquant n’a pas gagné au point que la partie est déjà finie ».

4. you can use the vunerability to bypass cloud features in AMD such as Secure Encrypted Virtualization, and potentially read customers' data. [2/2]

— Gadi Evron (@gadievron) March 13, 2018

Toutefois, Gadi Evron appelle à la prudence : malgré ces restrictions, les vulnérabilités n’en sont potentiellement pas moins critiques. De fait, la possibilité d’accéder à l’enclave sécurisée du processeur d’un système est particulièrement préoccupante. Microsoft y recourt pour proposer un environnement d’exécution de confiance pour le code manipulant des données sensibles en clair, dans Azure. L’approche, annoncée en septembre dernier, n’est pas nouvelle : Fujitsu la présentait déjà début 2016 avec sa Sealed Applications Solution.

Matthew Garrett, contributeur au code du noyau Linux, entend bien l’argument de Tavis Ormandi, soulignant en particulier que la mise à profit de chacune des vulnérabilités évoquées par CTS Labs nécessite qu’une autre ait été exploitée au préalable.

But there are many other people who don't want to make that assumption - root shouldn't be able to replace your system firmware with malware, root shouldn't be able to extract secrets from your credential VM, root shouldn't be able to trojan your chipset

— Matthew Garrett (@mjg59) March 13, 2018

Alors si l’on considère que la partie est totalement perdue une fois que l’attaquant a obtenu les droits d’administrateur, « ces vulnérabilités n’ont rien d’intéressant ». Mais dans le cas contraire, « elles sont critiques ».

Et Matthew Garrett de souligner qu’il y a beaucoup de personnes qui estiment que l’administrateur ne devrait pas être capable « de remplacer le firmware de votre système par un maliciel », ni « d’extraire des secrets de votre machine virtuelle stockant vos identifiants », ni encore d’installer dans le chipset comme un cheval de Troie.