Quels sont les risques de ne pas patcher un serveur ou un hyperviseur pour Meltdown?
Selon les rumeurs, le patch pour Meltdown entraînerait une pénalité de performance de 30%, ce qui serait agréable à éviter si possible. Cela devient donc un problème d'évaluation des risques Sécurité vs Performance.
Je recherche une règle de base pour évaluer le risque de ne pas patcher un serveur ou un hyperviseur.
En lisant les livres blancs , je crois comprendre que vous devez absolument appliquer le patch si votre machine:
- est un poste de travail qui exécute un code aléatoire potentiellement malveillant - y compris, il s'avère , Java à partir de sites Web aléatoires,
- est un VM qui pourrait potentiellement exécuter du code malveillant (ce qui devient essentiellement le premier cas).
- est un hyperviseur qui exécute des machines virtuelles non fiables à côté de machines virtuelles sensibles (ce qui devient essentiellement le premier cas),
Je crois comprendre que le risque est (considérablement) plus faible dans les cas suivants:
- serveur fonctionnant sur du matériel dédié exécutant un ensemble de processus étroitement contrôlés dans un réseau étroitement contrôlé (y compris ne pas utiliser de navigateur Web pour visiter des sites non fiables)
- VM exécutant un ensemble de processus étroitement contrôlés sur une pile de virtualisation d'autres VM étroitement contrôlées, le tout dans un réseau étroitement contrôlé.
Est-ce que c'est logique, ou est-ce que je manque quelque chose?
MISE À JOUR: les premiers utilisateurs du correctif dans Azure ne signalent aucun ralentissement notable , donc tout cela peut être théorique.
Question connexe: Quels sont les risques de ne pas corriger un système d'exploitation de poste de travail pour Meltdown?
Fondamentalement, si vous exécutez du code à partir de sources non fiables sur une machine contenant des données auxquelles vous ne voulez pas que ce code ait accès, vous devez corriger. Les ordinateurs de bureau doivent être corrigés car ils ont la fâcheuse habitude de rencontrer du code non fiable; les serveurs d'hébergement partagé, en particulier les hôtes de serveurs privés virtuels, doivent être corrigés, car Meltdown permet à un utilisateur d'accéder aux données de tous les autres utilisateurs.
Notez que l'attaque Meltdown ne peut pas être utilisée pour sortir d'une machine virtuelle . Vous pouvez sortir d'un conteneur, d'un bac à sable ou d'un système paravirtualisé, mais l'exécution de l'attaque Meltdown dans un système entièrement virtualisé vous donne simplement accès à la mémoire du noyau de cette machine virtuelle, pas à la mémoire du noyau de l'hôte.
Ma compréhension du problème est qu'il s'agit d'une fuite d'informations locale, où local signifie que les informations sont divulguées "uniquement" aux processus sur le même matériel physique et non (directement) aux systèmes distants. Et, c'est une attaque qui s'est avérée réellement utilisable dans la pratique pour extraire des informations sensibles, même si elle n'est actuellement pas triviale à exploiter. Mais la facilité avec laquelle l'exploit est susceptible de changer rapidement, comme le montre Rowhammer , qui a évolué en peu de temps d'un problème principalement théorique à une exploitation plus fiable du problème en utilisant Javascript dans un navigateur ou à rooter Android téléphones.
Ainsi, s'il y a une chance que du code non fiable soit exécuté sur le serveur, vous devez corriger. C'est pourquoi tous les grands fournisseurs de cloud ont déjà corrigé leurs systèmes ou le feront bientôt. Et c'est pourquoi les correctifs ont été incorporés si rapidement au noyau Linux, ce qui est très inhabituel pour les modifications du sous-système de mémoire.
Notez que le code non approuvé peut non seulement être exécuté si vous avez des utilisateurs non approuvés sur le système. Cela peut également se produire si vous traitez des données provenant d'une source non fiable. Par exemple, un attaquant pourrait utiliser les fonctionnalités existantes de votre serveur Web pour télécharger une image qui est ensuite convertie sur votre serveur (c'est-à-dire mise à l'échelle ou similaire). Compte tenu de l'historique des bogues dans les bibliothèques graphiques, il ne serait pas improbable que cette conversation puisse entraîner l'exécution de code. Et étant donné la nature du problème, je doute que les bacs à sable, docker ou similaires arrêtent l'exploitation du bogue.