La faille de sécurité
Deux failles de sécurité dans les processeurs connues depuis quelques temps - mais gardées secrètes en attendant de développer et déployer les correctifs - ont surgi au grand jour hier matin.
Intel’s processors have a security bug and the fix could slow down PCs https://t.co/lwyp28zHVd pic.twitter.com/p4zNIQeQjs
— The Verge (@verge) 3 janvier 2018
Les failles dans les logiciels, librairies et noyaux sont communes. Meltdown et Spectre, elles, sont des failles peu communes car issues d’erreur de conception du processeur. Ces failles permettent à un attaquant capable de contrôler une portion de code exécuté sur une machine d’accéder à l’ensemble de la mémoire de la machine, y compris les zones normalement confidentielles.
L’équipe de sécurité de Google qui a co-découvert la faille à réussi à lire de la mémoire d’un hôte KVM depuis une instance KVM : dans cette mémoire pourraient se trouver des mots de passe ou des certificats SSL.
Bwallez, l'anti-sèche est prêt... et il évoluera, d'où la date en bas à droite. Pas évident de caser des trucs compliqués dans une vue macro, alors on ne râle pas sur les détails, merci ;) #meltdown #Spectre pic.twitter.com/GL3GgYWQ40
— Rayna (@MaliciaRogue) 4 janvier 2018
Pour Meltdown, un travail du côté kernel a donc été lancé, et une protection nommée Kernel Page Table Isolation (ou KPTI) a été développée en fin 2017. Ce patch apporterait néanmoins certaines lenteurs. Ce fix permet de séparer les page tables, qui étaient jusque-là partagées par l'user et le kernel space. Un patch équivalent est bien entendu prévu pour les autres systèmes d’exploitation, la faille étant lié à l’architecture des processeurs et non pas à l’OS installé. Apple aurait déjà commencé à le déployer.
L’objectif de cet article n’est pas vulgariser ou d’expliquer cette faille, certains comme Nextinpact le font bien mieux que nous ou le site dédié à Meltdown et Spectre, mais d’en constater les effets sur AWS.
Quels impacts sur AWS ?
AWS a répondu rapidement à cette nouvelle avec une annonce rassurante. La majorité des hosts (hyperviseurs) sont déjà patchés, et seuls quelques hyperviseurs qui ne l’ont pas été hier le seront durant les prochaines heures.
S’il est impossible pour l’utilisateur de redémarrer lui-même le système, ce dernier aura (ou à déjà eu) lieu pendant sa fenêtre de maintenance planifiée et se termine généralement en quelques minutes. L'instance conserve son adresse IP et son nom DNS, et les données sur les volumes de stockage d'instance locaux sont conservées. Ce redémarrage vous sera notifié dans la console AWS et par mail.
Au niveau des OS des instances EC2, les patches pour l'AMI Amazon Linux ont déjà été poussés : "ALAS-2018-939", défini comme critique, est disponible depuis le 4 décembre à 7H, heure française. Pour l'appliquer, il suffit d'upgrader le kernel à l'aide de la commande yum update kernel
et de redémarrer l'instance. Les instances créées depuis le 2 janvier 10:45 PM (GMT) sont quant à elles déjà à jour.
Les downtimes suite à cette opération devraient donc être minimes s’ils n’ont pas déjà eu lieu.
Pour Windows comme pour les autres distributions non développées directement par AWS, les patches seront poussés lorsque les distributeurs auront proposés les nouvelles AMI, comme c'est le cas pour RedHat par exemple.
Vous trouverez un agrégat d'informations sur ce thread Reddit.
Alexandre KERVADEC, Adrien CUNIN, Aurélien JOGA
Découvrez les derniers articles d'alter way
- : Prowler : L'outil de sécurité multi-cloud indispensable pour renforcer votre infrastructure
- : Kubernetes : plateforme "star" de l'IT et levier d'innovation des entreprises
- AI_dev2024
- : DirectPV : Avoir du stockage bloc distribué facilement dans kubernetes
- : Simple comme GitOps : kluctl
- Conférence Wax 2024 @thecamp