Quand les maliciels iront se cacher dans les enclaves d’exécution sécurisée

Les chercheurs de l’université technique de Graz, en Autriche, continuent leurs recherches sur les processeurs. Pour mémoire, c’est à des cerveaux de cette université que l’on doit certains travaux préliminaires à la découverte des vulnérabilités Spectre et Meltdown. Mais pas uniquement, car certains s’étaient déjà penchés sur les enclaves d’exécution sécurisée des processeurs.

Ainsi, début 2017, Daniel Gruss, Clémentine Maurice, Stefan Mangard, Michael Schwartz et Samuel Weiser ont montré comment il était possible d’élaborer une attaque mettant en défaut les mécanismes de protection SGX des processeurs Intel.

Apparus avec la famille Skylake, lancée à l’été 2015, ces mécanismes visaient à renforcer la sécurité des environnements virtualisés en assurant, au niveau du processeur, une isolation robuste des machines virtuelles, au-delà de ce que peut permettre un hyperviseur. Car SGX permet de construire, par le matériel, des zones de mémoire chiffrées qui sont isolées du système d’exploitation sur lequel s’exécute l’hyperviseur.

Ce positionnement est hautement stratégique. Microsoft met à profit ce concept pour proposer des enclaves sécurisées dédiées au traitement de données hautement sensibles dans Azure, avec Confidential Computing. Fujitsu présentait déjà, début 2016, sa Sealed Applications Solutions (SAS) où l’application s’exécute dans un conteneur sécurisé dédié, mais sans en avoir conscience, car elle utilise le système d’exploitation pour accéder aux données.

Il y a deux ans, les cinq chercheurs expliquaient avoir mis au point un maliciel utilisant lui-même SGX pour se cacher et attaquer le système hôte, ainsi qu’extraire des secrets cachés dans d’autres enclaves. Une situation sérieuse puisque « le code du logiciel malveillant est complètement invisible du système d’exploitation et ne peut pas être analysé du fait de la protection apportée par SGX ».

Summary: Take an exploit, encrypt it, put it in an SGX enclave, decrypt only after remote trigger signal, run exploit via ROP chain on host app, remove traces of ROP immediately + continue regular host execution, repeat on other victims.

— Daniel Gruss (@lavados) February 12, 2019

Mais à l’époque, Simon Crosby, alors directeur technique de Bromium, reconnaissait l’élégance de l’exercice : « il est certain que si un logiciel malveillant parvient à détourner SGX, les choses tournent très mal ». Mais il en soulignait également les limites : « pour être honnête, le nombre de processeurs Skylake ou plus récent est très réduit », et la taille limitée des enclaves SGX « restreint les cas d’usage ».

Mais Michael Schwartz, Samuel Weiser, et Daniel Gruss n’en démordent pas : le risque est réel. Et d’en faire la démonstration avec, en résumé : « prenez un exploit, chiffrez-le, placez-le dans une enclave SGX, ne déchiffrez qu’après un signal déclencheur à distance, lancez l’exploit via une chaîne ROP [programmation orientée retour, NDLR] sur une application de l’hôte, supprimez immédiatement les traces, et continuez l’exécution normale de l’hôte ; recommencez sur d’autres victimes ».

Au final, les chercheurs essaient d’interpeler sur le modèle de menace associé aux enclaves sécurisées : il part du principe que l’on peut faire confiance à ce qui s’y trouve. Mais pour eux, la démonstration faite montre que « au lieu de protéger les utilisateurs, SGX constitue une menace de sécurité, facilitant la création de super-maliciels avec des exploits prêts à frapper », et simplement dormants. Un point que les entreprises ont probablement tout intérêt à prendre en compte dans le cadre d’achats d’équipements afin de se protéger contre les attaques visant leur chaîne logistique.