Une étude récente, citée par VMware dans la kb2080735, met en évidence un risque de sécurité lié au Transparent Page Sharing (TPS) utilisé par VMware.
En l’occurrence, il s’agit de la possibilité de récupérer, depuis une machine virtuelle A, la clé AES utilisée par SSL sur une machine virtuelle B. Bien que la situation semble difficile à reproduire en conditions réelles, le risque est bien réel, suffisamment en tous cas pour que VMware se décide à désactiver le Transparent Page Sharing par défaut sur toutes les versions d’ESX futures d’ESX, ainsi que lors des prochaines mises à jour de type update pour les versions existantes.
Par exemple, la 5.5 est actuellement en update 2, TPS sera donc désactivé par défaut en U3. Plus précisément, le TPS inter-vm sera désactivé par défaut (TPS pourra toujours dédupliquer les pages mémoires d’une même machine, mais avec bien sûr un bénéfice moindre).
Dans l’attente de ces nouvelles versions, des patchs permettent déjà à ceux qui le souhaitent de désactiver le TPS en 5.5 et en 5.1. Le patch pour la 5.0 est à venir.
Analyse d’impact
Petit retour en arrière. Depuis l’introduction de processeurs disposant d’une MMU hardware (Intel EPT, AMD RVI… en 2006), le support des “Large Pages” (pages mémoire de 2 Mo, au lieu de 4 ko) a été recommandé, puis activé par défaut avec ESXi. La combinaison des MMU hardware avec les “Large Pages” permet en effet d’améliorer considérablement les performances de certains workloads, sans en impacter d’autres négativement (ce qui est le cas lorsqu’on combine MMU hardware et “Small Pages”). Ces pages mémoire de 2 Mo ne sont pas sujettes au TPS (il n’y a presque aucune chance d’en trouver deux identiques).
Ainsi, sur un système ESXi (relativement) récent, il n’y a déjà plus de TPS actif, sauf en cas de contention mémoire sur l’hôte : dans ce cas ESXi éclate ces pages mémoires de 2 Mo en pages de 4 ko afin d’activer le TPS et de récupérer de la mémoire, au prix donc d’un certain impact sur les performances.
Pour tous les environnements non contraints en mémoire, le risque réel est donc inexistant, et la mise à jour d’ESXi aux prochaines versions, désactivant le TPS, n’aura pas d’impact. Pour ces environnements, autant ne pas se poser de question et laisser alors le TPS désactivé pour de bon !
Attention cependant : le TPS n’est pas utilisé dans votre environnement, mais qu’en est-il en cas de panne d’un serveur ? Êtes-vous sûr que vous avez de ressources pour absorber la charge des machines redémarrées par HA sans devoir réactiver le TPS ?
Quoi qu’il en soit, pour les environnements qui s’appuient sur le TPS pour augmenter leur taux de consolidation (et c’est parfois impressionnant, avec jusqu’à 50% de consolidation supplémentaire !), la question va se poser : faut-il réactiver le TPS après la prochaine mise à jour (VMware le désactivera par défaut mais laissera la possibilité de le réactiver manuellement) ?
Proposons ici quelques éléments de réponse, en fonction des cas.
Etude de cas
Cas 1. Environnement d’entreprise
Dans ce cas, l’environnement VMware héberge les serveurs d’une seule et même entreprise. Les applications sont gérées par l’équipe informatique de cette entreprise et ont un usage interne.
On peut alors se poser la question suivante : pourquoi déployer des efforts importants pour obtenir les accès à une machine permettant ensuite d’attaquer une machine cible, plutôt que d’obtenir tout de suite les accès à la machine cible ? En effet, selon toute vraisemblance les machines de ce scénario partagent une base de compte commune (Active Directory par exemple). Accéder à serveur avec un compte administrateur permet très certainement d’accéder aux autres serveurs également. Autrement dit, dans ce scénario le risque réel lié à l’attaque permise par TPS est très faible.
Cependant, très faible n’est pas nul, et rien ne dit que le mécanisme de cette attaque ne sera pas amélioré à l’avenir pour présenter un risque plus élevé.
Par conséquent dans ce cas nous proposerions l’approche suivante : dans la mesure où le risque réel est très faible, on laissera le TPS activé. Éventuellement, si certaines machines particulières présentent un risque particulier (DMZ, application critique), on pourrait utiliser le “salting”* pour isoler ces machines du TPS inter-vm, mais cette configuration est assez lourde à l’heure actuelle.
Dans tous les cas, l’environnement doit tendre vers la désactivation du TPS à moyen terme, et l’on planifiera les investissements nécessaires (en mémoire vive, donc, ou en nouveaux serveurs dimensionnés à cet effet, lors d’un renouvellement). Cela permettra à moindre de coût de ne plus se soucier de ce risque à l’avenir.
Cas 2. Environnement partagé
Nous sommes typiquement dans le cas d’un hébergeur, mais cela pourrait être également être le cas d’une entreprise qui offre des services d’infrastructure à des entreprises filles ou des départements disposant de leur propre environnement virtualisé, isolé d’un point de vue réseau et s’appuyant sur des mécanismes d’authentification propres, mais pouvant se retrouver sur le même serveur physique.
Dans ce cas, malgré la difficulté technique liée à l’exploitation du risque de sécurité, il est clair que le TPS doit être désactivé. Vous ne pouvez pas vous permettre de laisser ce risque de sécurité identifié dans votre infrastructure, ne serait-ce que pour des raisons contractuelles (où vous vous engagez à maintenir un certain niveau de sécurité).
L’approche suivante doit donc être envisagée : réaliser le plus rapidement possible les investissements qui permettront de désactiver le TPS sans impact sur les performances. Ce ne devrait pas être un investissement coûteux (mémoire vive) et vous mettra à l’abri du risque potentiel. Et si vous pouvez le désactiver immédiatement, faites-le !
Cas 3. Le cas particulier du VDI
Historiquement, le VDI est le cas d’usage idéal pour le TPS : sur un même serveur ESXi, plusieurs dizaines de machines virtuelles quasi identiques, avec le même OS, les mêmes applications… C’est là où l’on tire le plus parti des économies permises par le TPS. Faut-il vraiment le désactiver ?
On est typiquement dans le cas où le risque de sécurité est extrêmement faible : dans l’environnement VDI encore plus que dans l’environnement serveur, l’accès à une machine permet généralement l’accès aux autres machines du même pool. Il y a donc peu d’intérêt à vouloir exploiter une faille complexe, plutôt que d’accéder directement à la cible. Par ailleurs, les cibles potentielles sont des postes client, donc typiquement sans données critiques ou applications sensibles.
L’exception à cette règle serait un environnement où des serveurs sont hébergés sur les mêmes ESXi que les postes clients VDI, et où, donc, un poste client pourrait théoriquement accéder à des clés AES du serveur. Mais là, la bonne solution ne serait pas de désactiver le TPS, mais plutôt de séparer l’exécution des serveurs de celle des machines VDI !
Cas particulier du cas VDI : une plateforme VDI partagée par plusieurs entreprises ou services indépendants (scénario de type hébergeur). Dans ce cas, il serait dommage de se priver du TPS, mais vous ne pouvez pas vous permettre non plus le risque de récupérations de clés AES entre vos différents clients. C’est pour l’instant un bon cas d’usage du “salting”* : en configurant un sel commun pour chaque client, le TPS sera activé par client, et le risque de sécurité contenu. La configuration pourra être lourde, mais l’automatisation est possible !
Dans le scénario VDI, l’idée principale est donc de continuer raisonnablement à exploiter les bénéfices du TPS, avec salting si besoin, en gardant un œil sur de possibles évolutions futures du risque !
Conclusion
Il ne fait aucun doute que le TPS présente un risque de sécurité réel. Une première faille a été mise en évidence avec un cas précis, mais le mécanisme pourrait être utilisé à d’autres fins que la récupération de clés AES. Il faut donc être conscient du risque, et tout particulièrement lorsqu’on exploite un environnement partagé (multi-tenant), auquel cas une action s’impose dans de brefs délai.
Dans beaucoup d’autre cas, le TPS n’est déjà plus aujourd’hui qu’un mécanisme de secours lorsque la mémoire du système ESXi est insuffisante. Il n’est donc plus systématiquement utilisé, hors cas particulier (défaillance HA). De plus, dans beaucoup d’environnements, l’exploitation de la faille est beaucoup plus complexe, pour des résultats bien maigres, que des approches plus basiques. On peut donc se permettre une réaction prudente.
Pour réagir de façon appropriée à ce nouveau risque, il s’agit donc en premier lieu de bien analyser l’environnement. Et de garder à l’esprit que le TPS, tel que nous l’avons connu jusqu’à présent, n’est plus une solution d’avenir !
* salting : dans les patchs livrés récemment pour remédier au problème (et probablement également dans les versions futures d’ESXi), on peut activer le TPS pour un groupe précis de VM grâce à un attribut de machine virtuelle : le “salt” (sel). Toutes les machines virtuelles qui ont le même “sel” pourront partager leur mémoire. Par défaut, le “sel” sera basé sur l’identifiant de la VM et donc unique : le TPS inter-vm sera désactivé. En configurant un même sel pour un groupe de VMs que l’on juge sûr, on réactivera le TPS inter-vm. Malin !