Les attaques latérales du CPU sont-elles toujours une préoccupation sur les VPS
J'ai cherché à obtenir un VPS pour exécuter un serveur OpenVPN et quelques autres choses. Je parlai d'une entreprise d'hébergement et ils m'ont envoyé cette capture d'écran pour montrer qu'ils sont protégés contre tous les exploits actuellement connus sur leurs hyperviseurs:
Cependant, la protection contre les implémentations connues des exploits pourrait ne pas nécessairement signifier que je suis pleinement protégé. Y a-t-il encore une chance que les données VPS peuvent être compromises aujourd'hui ou deviennent-elles une chose du passé? Devrais-je être inquiet ou est-ce beaucoup moins susceptible que je pense?
Merci.
L'état actuel du spectre, de la fusion, de la L1TF, de SRDB, etc. sur la plupart des plates-formes , avec toutes les corrections appliquées et les mesures d'égalité par défaut activées, sont des attaques à travers la sécurité Les frontières (par exemple, le croix, le cross-vm, le processus croisé) sont impossibles ou très peu pratiques. Sur les hôtes virtualisés, une plate-forme de virtualisation à jour (par exemple ESXI, XEN) devrait appliquer des mesures fortes aux attaques croisées tant que des mises à jour du microcode CPU ont été effectuées.
En ce qui concerne la vérification de l'état de ces problèmes sur un hôte, cette phrase est vraiment le creux de celui-ci:
Cependant, la protection contre les implémentations connues des exploits pourrait ne pas nécessairement signifier que je suis pleinement protégé.
Votre fournisseur VPS semble exécuter son propre script de détection de Redhat. C'est probablement bien, mais je ne trouve pas de copie publique de ce script et Redhat nécessite un abonnement pour le télécharger. En tant que tel, il peut simplement vérifier les patchs de noyau.
Je vous recommanderais de demander à votre fournisseur d'hébergement à exécuter Spectre-Meltdown-Checker , qui vérifie l'état de la CPU sous une plate-forme-agnostique et recherche des correctifs et des atmosphérents du système d'exploitation. Les méthodes sont documenté publiquement . Avoir de bons résultats du script redhat et Le script Open Source est à peu près autant d'assurance que vous pouviez espérer.
Plus généralement parlant, vous devriez être principalement protégé contre les attaques de canal latéraux CPU connues sur une version à jour de Redhat. Le système d'exploitation appliquera des mesures d'atténuation par défaut et le fournisseur VPS devrait les éteindre pour vous laisser vulnérable - quelque chose qui n'est pas dans leurs intérêts à faire en tant que fournisseur d'hébergement virtualisé.
Un attaquant qui exécute un code non approuvé dans le contexte d'un processus peut toujours être en mesure d'exploiter certaines de ces attaques, à des degrés divers, mais ils ne seront généralement pas en mesure de récupérer des informations de ce processus. Les mises à jour de microcode offrent une certaine protection contre les attaques croisées et les correctifs du système d'exploitation atténuent le côté transversal de la vulnérabilité en veillant à des caches rincer lors des commutateurs de contexte entre les frontières de la sécurité. Dans un environnement de serveur, il existe peu de cas (le cas échéant) où le code non approuvé exécute dans le même processus que le code de confiance, et si un attaquant peut obtenir une exécution de code arbitraire sans restriction dans le contexte d'un processus sur le serveur, ils ne sont susceptibles de gêner avec une attaque secondaire.
Le scénario principal que les gens s'inquiètent de la fusion et du spectre, en dehors de l'espace VPS, sont des navigateurs, car vous avez plusieurs documents provenant de différentes origines en cours d'exécution de code non approuvé (par exemple JavaScript) à l'autre, souvent dans le même processus. Si un attaquant peut exploiter une attaque de canal latéral à partir de JavaScript (entièrement possible, et a été fait), ils peuvent l'utiliser pour avoir accès à la mémoire de processus. Si plusieurs documents issus de différentes origines sont chargés dans le même contexte d'exécution, ils peuvent accéder aux ressources de ces autres documents et violer la même politique d'origine (SOP). C'est pourquoi SharedArrayBuffer est restreint derrière COOP/COEP - Il est très utile en tant que primitif pour l'exploitation de ces problèmes, de sorte que les navigateurs exigent que toute ressource qui souhaite avoir accès à cette primitive doit être isolée. dans son propre processus.
Dans l'ensemble, je ne m'inquiéterais pas trop. Vos attaquants moyens n'ont pas tendance à utiliser ce genre de choses, et même les plus avancés (que vous ne devriez généralement pas vous inquiéter à moins que vous ne soyez une société MSP, ONG, CNI, TLA, Gaz et Oil Fournisseur) Ne vous embêtez pas à moins d'une raison majeure. Il n'y a que quelques scénarios étranges où des attaques de canal latéraux comme celle-ci sont pertinentes contre un serveur au lieu d'un navigateur client.
Le TL; DR - Essayez de s'assurer que les patchs sont appliqués, mais ne portez pas le temps et l'attention sur ce produit au détriment des vecteurs d'attaque plus susceptibles tels que les packages obsolètes, les bugs WebApp, les problèmes de configuration, l'exposition à l'information, les règles de pare-feu de mauvaise qualité , etc.