Concerne : CVE-2017-5715, CVE-2017-5753, CVE-2017-5754
Mise à jour au : 05/03/2018 15:00 PST (heure du Pacifique)
Il s'agit d'une mise à jour pour ce problème.
Un noyau mis à jour pour Amazon Linux est disponible dans les référentiels Amazon Linux. Les instances EC2 lancées avec la configuration Amazon Linux par défaut le 13 janvier 2018 ou après comprendront automatiquement le package mis à jour. Celui-ci intègre les dernières améliorations de sécurité open source stables de Linux pour résoudre CVE-2017-5715 dans le noyau et s'appuie sur la fonction Kernel Page Table Isolation (KPTI) intégrée précédemment et qui corrigerait CVE-2017-5754. Les clients doivent effectuer la mise à niveau vers le dernier noyau ou la dernière AMI Amazon Linux pour atténuer efficacement les anomalies entre processus de CVE-2017-5715 et les anomalies entre processus et noyau de CVE-2017-5754 dans leurs instances. Pour plus d'informations, consultez « Exécution spéculative du processeur – Mises à jour du système d'exploitation ».
Consultez les informations de « Conseils sur les instances PV » ci-dessous en ce qui concerne les instances paravirtualisées (PV).
Amazon EC2
Toutes les instances de la flotte Amazon EC2 sont protégées contre les anomalies entre instances de CVE-2017-5715, CVE-2017-5753 et CVE-2017-5754. Les anomalies entre instances supposent qu'une instance voisine non approuvée pourrait lire la mémoire d'une autre instance ou de l'hyperviseur AWS. Ce problème a été résolu pour les hyperviseurs AWS et aucune instance ne peut lire la mémoire d'une autre ni celle de l'hyperviseur AWS. Comme indiqué précédemment, nous n'avons pas remarqué d'incidence significative sur les performances de la grande majorité des charges de travail EC2.
Le 12 janvier 2018, nous avons terminé les parties désactivation du nouveau microcode du processeur CPU pour les plateformes dans AWS sur lesquelles nous notons un petit nombre de défaillances et autres comportements imprévisibles dus aux mises à jour du microcode Intel. Ce changement a atténué les problèmes pour ce petit nombre d'instances.
Actions recommandées de la part du client pour AWS Batch, Amazon EC2, Amazon Elastic Beanstalk, Amazon Elastic Container Service, Amazon Elastic MapReduce et Amazon Lightsail
Bien que toutes les instances du client soient protégées comme indiqué ci-dessus, nous recommandons aux clients d'appliquer le correctif aux systèmes d'exploitation de leurs instances pour corriger les anomalies entre processus ou entre processus et noyau liées à ce problème. Consultez « Exécution spéculative du processeur – Mises à jour du système d'exploitation » pour d'autres conseils et instructions pour Amazon Linux et Amazon Linux 2, CentOS, Debian, Fedora, Microsoft Windows, Red Hat, SUSE et Ubuntu.
Conseils sur les instances PV
Après une recherche continue et une analyse détaillée des correctifs de système d'exploitation disponibles pour ce problème, nous avons conclu que les protections du système d'exploitation sont insuffisantes pour résoudre les anomalies entre processus dans les instances paravirtualisées (PV). Bien que les instances PV soient protégées par les hyperviseurs AWS contre toutes les anomalies entre instances comme indiqué ci-dessus, les clients soucieux de l'isolation des processus au sein de leurs instances PV (ex. données non approuvées des processus, exécution de code non approuvé, utilisateurs non approuvés d'hôte), sont fortement encouragés à migrer vers des types d'instances HVM pour profiter d'avantages à plus long terme en matière de sécurité.
Pour plus d'informations sur les différences entre PV et HVM (ainsi que la documentation sur le chemin de mise à niveau des instances), consultez :
https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/virtualization_types.html
Contactez le support si vous avez besoin d'assistance en ce qui concerne le chemin de mise à niveau d'instances PV.
Mises à jour d'autres services AWS
Les services suivants nécessitaient l'application de correctifs aux instances EC2 gérées au nom des clients. Toutes les opérations sont terminées et aucune action de la part des clients n'est nécessaire :
- Fargate
- Lambda
Sauf indication contraire ci-dessous, aucun des autres services AWS ne nécessite d'action de la part du client.
AMI optimisée pour ECS
Nous avons publié l'AMI optimisée pour Amazon ECS version 2017.09.g qui intègre toutes les protections Amazon Linux pour ce problème. Nous conseillons à tous les clients Amazon ECS d'effectuer la mise à niveau vers cette dernière version, qui est disponible sur AWS Marketplace.
Les clients qui décident plutôt de mettre à jour des instances existantes avec AMI optimisée pour ECS doivent exécuter la commande suivante pour veiller à recevoir le package mis à jour :
sudo yum update kernel
Comme c'est le cas pour chaque mise à jour du noyau Linux, une fois la mise à jour yum terminée, un redémarrage est nécessaire pour que les mises à jour prennent effet.
Nous recommandons aux clients Linux qui n'utilisent pas l'AMI optimisée pour ECS de consulter leur fournisseur de tout système d'exploitation, logiciel ou AMI autre/tiers en ce qui concerne les mises à jour et les instructions, si nécessaire. Les instructions concernant Amazon Linux sont disponibles dans le Centre de sécurité AMI Amazon Linux.
Nous avons publié l'AMI Windows optimisée pour Amazon ECS version 2018.01.10. Pour plus de détails sur l'application de correctifs à des instances en cours d'exécution, consultez « Exécution spéculative du processeur – Mises à jour du système d'exploitation ».
Elastic Beanstalk
Nous avons mis à jour toutes les plateformes basées sur Linux pour qu'elles comprennent toutes les protections Amazon Linux pour ce problème. Consultez les notes de mise à jour correspondant aux versions spécifiques des plateformes. Nous conseillons aux clients Elastic Beanstalk de mettre à jour leurs environnements à la dernière version disponible de la plateforme. Les environnements qui utilisent les mises à jour gérées seront mis à jour automatiquement pendant la fenêtre de maintenance configurée.
Les plateformes basées sur Windows ont également été mises à jour pour intégrer toutes les protections Windows EC2 pour ce problème. Nous conseillons aux clients de mettre à jour leurs environnements Elastic Beanstalk basés sur Windows à la dernière configuration disponible de la plateforme.
ElastiCache
Chaque nœud de cache client géré par ElastiCache est dédié à l'exécution d'un seul moteur de cache pour un seul client, sans aucun autre processus accessible par les clients et aucune possibilité pour les clients d'exécuter du code sur l'instance sous-jacente. Étant donné qu'AWS a terminé la protection de toute l'infrastructure sous-jacente d'ElastiCache, les anomalies entre processus et noyau ou entre processus de ce problème ne présentent aucun risque pour les clients. Les deux supports ElastiCache des moteurs de cache n'ont actuellement signalé aucune anomalie connue entre processus.
EMR
Amazon EMR lance des clusters d'instances Amazon EC2 qui exécutent Amazon Linux au nom de clients dans le compte des clients. Les clients soucieux de l'isolation des processus au sein des instances de leurs clusters Amazon EMR doivent effectuer la mise à niveau vers le dernier noyau Amazon Linux, comme recommandé ci-dessus. Nous avons intégré le dernier noyau Amazon Linux dans les nouvelles versions mineures 5.11.1, 5.8.1, 5.5.1 et 4.9.3. Les clients peuvent créer des clusters Amazon EMR avec ces versions.
Pour les versions Amazon EMR actuelles et les instances en cours d'exécution associées, nous recommandons aux clients d'effectuer la mise à jour vers le dernier noyau Amazon Linux comme indiqué ci-dessus. Pour les nouveaux clusters, les clients peuvent utiliser une action d'amorçage pour mettre à jour le noyau Linux et redémarrer chaque instance. Pour les clusters en cours d'exécution, les clients peuvent effectuer la mise à jour et le redémarrage du noyau Linux pour chaque instance de leur cluster en mode continu. Notez que le redémarrage de certains processus peut avoir une incidence sur les applications en cours d'exécution dans le cluster.
RDS
Les instances de base de données client gérées par RDS sont dédiées à l'exécution d'un seul moteur de base de données pour un seul client, sans aucun autre processus accessible aux clients et aucune possibilité pour les clients d'exécuter le code sur l'instance sous-jacente. Étant donné qu'AWS a terminé la protection de toute l'infrastructure sous-jacente de RDS, les anomalies entre processus et noyau ou entre processus inhérentes à ce problème ne présentent aucun risque pour les clients. À l'heure actuelle, aucune anomalie connue entre processus n'a été constatée pour la plupart des supports RDS des moteurs de base de données. Les autres détails spécifiques à un moteur de base de données figurent ci-dessous et, sauf indication contraire, aucune action de la part du client n'est nécessaire.
Pour les instances de base de données RDS pour SQL Server RDS, nous avons publié des correctifs du système d'exploitation et du moteur qui contiennent les correctifs de Microsoft dans les versions suivantes des moteurs :
SQL Server 2017 (14.00.3015.40.v1)
SQL Server 2016 (13.00.4466.4.v1)
SQL Server 2014 (12.00.5571.0.v1)
SQL Server 2012 (11.00.7462.6.v1)
SQL Server 2008 R2 (10.50.6560.0.v1)
Nous conseillons aux clients de prendre connaissance des conseils de Microsoft sur l'application de ces correctifs et de les appliquer au moment de leur choix :
https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server
Pour RDS PostgreSQL et Aurora PostgreSQL, les instances de base de données qui s'exécutent dans la configuration par défaut ne nécessitent actuellement aucune action de la part du client. Nous fournirons les correctifs appropriés pour les utilisateurs des extensions plv8 dès qu'ils seront disponibles. En attendant, les clients qui ont activé les extensions plv8 (désactivées par défaut) doivent envisager de les désactiver et consulter les conseils de V8 à l'adresse https://github.com/v8/v8/wiki/Untrusted-code-mitigations.
Aucune action de la part du client n'est actuellement nécessaire pour les instances de base de données RDS for MariaDB, RDS for MySQL, Aurora MySQL et RDS for Oracle.
VMware Cloud on AWS
Selon VMware, « La correction telle qu'elle est documentée dans VMSA-2018-0002 est présente dans VMware Cloud on AWS depuis début décembre 2017. »
Consultez le blog de VMware sur la sécurité et la conformité pour plus de détails et https://status.vmware-services.io pour obtenir un statut à jour.
WorkSpaces
Pour les clients utilisateurs de l'expérience Windows 7 sur Windows Server 2008 R2 :
Microsoft a publié de nouvelles mises à jour de sécurité pour Windows Server 2008 R2 pour ce problème. Le succès de la mise à disposition de ces mises à jour exige qu'un logiciel antivirus compatible s'exécute sur le serveur comme indiqué dans la mise à jour de sécurité de Microsoft : https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software. Les clients WorkSpaces doivent prendre des mesures pour obtenir ces mises à jour. Suivez les instructions fournies par Microsoft à l'adresse suivante : https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.
Pour les clients utilisateurs de l'expérience Windows 10 sur Windows Server 2016 :
AWS a appliqué les mises à jour de sécurité aux instances WorkSpace qui exécutent l'expérience Windows 10 sur Windows Server 2016. Windows 10 intègre le logiciel antivirus Windows Defender qui est compatible avec ces mises à jour de sécurité. Aucune autre action n'est nécessaire de la part du client.
Pour les clients BYOL et ceux dont les paramètres de mise à jour par défaut ont été modifiés :
Notez que les clients qui utilisent la fonctionnalité BYOL (Bring Your Own License) de WorkSpaces et ceux qui ont modifié les paramètres de mise à jour par défaut dans leurs instances WorkSpace doivent appliquer manuellement les mises à jour de sécurité fournies par Microsoft. Si cela s'applique à vous, suivez les instructions fournies par l'avis de sécurité Microsoft à l'adresse https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002. L'avis de sécurité comprend des liens vers des articles de base de connaissances pour les systèmes d'exploitation Windows client et serveur qui contiennent d'autres informations spécifiques.
Des offres WorkSpaces mises à jour seront bientôt disponibles avec les mises à jour de sécurité. Les clients qui ont créé des offres personnalisées doivent les mettre à jour afin qu'elles incluent les mises à niveau de sécurité proprement dites. Toute nouvelle instance WorkSpace lancée à partir d'offres qui ne comprennent pas les mises à jour recevra des correctifs rapidement après le lancement, sauf si les clients ont modifié le paramètre par défaut dans leurs instances WorkSpace ou installé un logiciel antivirus incompatible, auquel cas ils doivent suivre les étapes ci-dessus pour appliquer manuellement les mises à jour de sécurité fournies par Microsoft.
WorkSpaces Application Manager (WAM)
Nous recommandons aux clients de choisir une des procédures suivantes :
Option 1 : appliquer manuellement les mises à jour Microsoft sur les instances en cours d'exécution de WAM Packager et Validator en suivant les étapes fournies par Microsoft à l'adresse https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. Cette page propose des instructions complémentaires et des téléchargements pertinents.
Option 2 : arrêtez vos instances existantes de Packager et Validator. Lancez les nouvelles instances en utilisant nos AMI mis à jour et identifiés « Amazon WAM Admin Studio 1.5.1 » et « Amazon WAM Admin Player 1.5.1 ».