Ceci est une version antérieure de ce bulletin de sécurité. Pour obtenir la dernière version, veuillez consulter « Divulgation de recherche sur l'exécution spéculative du processeur ».

Concerne : CVE-2017-5715, CVE-2017-5753, CVE-2017-5754

Mise à jour à partir du 13/01/2018 à 13 h 00 PST (heure du Pacifique)

Ceci est une mise à jour concernant ce problème.

Une deuxième version du noyau pour Amazon Linux est désormais disponible. Elle corrige les bogues KPTI et améliore les mesures d'atténuations pour CVE-2017-5754. Pour atténuer efficacement les problèmes de vulnérabilité CVE-2017-5754 entre processus au sein de leurs instances, les clients doivent procéder à une mise à niveau vers le dernier noyau ou AMI Amazon Linux. Consultez « AMI Amazon Linux » plus loin pour en savoir plus.  

Veuillez consulter « Directives sur les instances paravirtualisées » plus loin pour en savoir davantage sur les instances paravirtualisées (PV).

Amazon EC2

Toutes les instances de la flotte Amazon EC2 sont protégées contre toutes les vulnérabilités et expositions courantes (CVE) entre instances précédemment énumérées. La présence de vulnérabilités entre instances entraîne le risque qu'une instance voisine non approuvée puisse lire la mémoire d'une autre instance ou de l'hyperviseur AWS. Ce problème a été résolu pour les hyperviseurs AWS si bien que désormais, 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 quasi totalité des charges de travail d'EC2.

Nous avons identifié un petit nombre de plantages de l'application et de l'instance consécutifs aux mises à jour du microcode et travaillons à leur résolution directement avec les clients concernés. Nous venons de terminer la désactivation de certaines parties du nouveau microcode du processeur Intel pour les plateformes AWS où nous avons constaté ces problèmes. Cette désactivation a permis d'atténuer le problème pour ces instances. Toutes les instances de la flotte Amazon EC2 restent protégées contre tous les vecteurs de menace connus. Le microcode Intel désactivé a fourni des protections supplémentaires contre les vecteurs de menace potentiels due à la vulnérabilité CVE-2017-5715. Nous comptons réactiver ces protections supplémentaires (ainsi que certaines optimisations de performances supplémentaires sur lesquelles nous avons travaillé) dans un avenir proche, notamment dès qu'Intel aura fourni un microcode à jour.

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

Nonobstant la protection de toutes leurs instances comme décrite ci-dessus, nous recommandons aux clients d'appliquer le correctif aux systèmes d'exploitation de leurs instances pour isoler le logiciel qui s'exécute au sein de la même instance et atténuer la vulnérabilité CVE-2017-5754 entre processus. Pour plus de détails, reportez-vous aux directives spécifiques du fournisseur sur la disponibilité et le déploiement des correctifs.

Directives spécifiques du fournisseur :

Pour les systèmes d'exploitation non répertoriés, les clients doivent consulter le fournisseur de leur système d'exploitation ou de leur AMI pour les mises à jour et les instructions.

Directives sur les instances paravirtualisées

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 vulnérabilités entre processus au sein des instances PV. Bien que les instances PV soient protégées par les hyperviseurs AWS contre toutes les vulnérabilités entre instances comme indiqué ci-dessus, les clients soucieux de l'isolation des processus au sein de leurs instances PV (par ex. données non approuvées des processus, exécution de code non approuvé, utilisateurs non approuvés d'hôtes) sont fortement encouragés à migrer vers des types d'instances HVM pour tirer parti 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), veuillez consulter :

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html

Veuillez contacter le Support si vous avez besoin d'assistance en ce qui concerne le chemin de mise à niveau des instances PV.

Mises à jour vers d'autres services AWS

Les services suivants nécessitaient l'application de correctifs aux instances EC2 gérées au nom des clients. Toutes ces opérations sont désormais terminées et aucune action n'est requise de la part des clients :

  • Fargate
  • Lambda

Sauf indication contraire ci-dessous, aucun des autres services AWS ne nécessite d'action de la part du client.

AMI Amazon Linux (ID de bulletin : ALAS-2018-939)

Un noyau mis à jour pour Amazon Linux est disponible au sein des référentiels d'Amazon Linux. Les instances EC2 lancées avec la configuration par défaut d'Amazon Linux le 8 janvier 2018 ou après cette date incluent automatiquement le package mis à jour qui corrige les bogues KPTI et améliore les atténuations pour CVE-2017-5754.

REMARQUE : les clients doivent effectuer une mise à niveau vers le dernier noyau ou AMI Amazon Linux pour atténuer efficacement la vulnérabilité CVE-2017-5754 au sein de leur instance. Nous continuerons à fournir les améliorations d'Amazon Linux et les mises à jour des AMI Amazon Linux notamment en intégrant, au fur et à mesure qu'elles sont disponibles, les contributions de la communauté Linux open source qui corrigent cette vulnérabilité.

Pour recevoir le package mis à jour, les clients disposant d'instances AMI Amazon Linux existantes doivent exécuter la commande suivante :

sudo yum update kernel

Une fois que la mise à jour de yum est terminée, un redémarrage est nécessaire pour que les mises à jour prennent effet, comme c'est le cas pour toute mise à jour du noyau Linux.

Vous trouverez davantage d'informations concernant ce bulletin dans le centre de sécurité de l'AMI Amazon Linux.

Pour Amazon Linux 2, veuillez suivre les instructions pour Amazon Linux décrites ci-dessus.

EC2 pour Windows

Nous avons mis à jour les AMI pour AWS Windows. Les clients ont désormais accès à ces mises à jour, les correctifs nécessaires pour les AMI pour AWS Windows ont été installés et les clés de registre ont été activées.

Microsoft a fourni des correctifs Windows pour les serveurs 2008R2, 2012R2 et 2016. Les correctifs sont accessibles par le biais du service intégré Windows Update pour Server 2016. Nous attendons que Microsoft nous communique des informations concernant la disponibilité des correctifs pour Server 2003, 2008SP2 et 2012RTM.

Les clients AWS qui exécutent des instances Windows sur EC2 et qui ont activé l'option « Automatic Updates » (Mises à jour automatiques) doivent exécuter les mises à jour automatiques afin de télécharger et d'installer la mise à jour requise pour Windows lorsque celle-ci est disponible.

Veuillez noter que les correctifs des serveurs 2008R2 et 2012R2 sont actuellement indisponibles par le biais de Windows Update et doivent être téléchargés manuellement. Microsoft avait promis que ces correctifs seraient disponibles le mardi 9 janvier. Cependant, nous attendons toujours des informations quant à leur disponibilité.

Les clients AWS qui exécutent des instances Windows sur EC2 et qui n'ont pas activé « Automatic Updates » (Mises à jour automatiques) doivent installer manuellement la mise à jour nécessaire lorsque celle-ci est disponible en suivant les instructions données ici : http://windows.microsoft.com/en-us/windows7/install-windows-updates.

Veuillez noter que pour Windows Server, Microsoft exige des étapes supplémentaires pour activer les fonctions de protection de leur mise à jour pour ce problème. Ces exigences sont décrites ici : https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.

AMI optimisée pour ECS

Nous avons publié la version 2017.09.f de l'AMI optimisée pour Amazon ECS qui intègre toutes les protections d'Amazon Linux pour ce problème, notamment la deuxième mise à jour du noyau Amazon Linux mentionnée ci-dessus. Nous conseillons à tous les clients d'Amazon ECS d'exécuter la mise à niveau vers la dernière version qui est disponible sur AWS Marketplace. Nous allons poursuivre l'intégration des améliorations d'Amazon Linux au fur et à mesure qu'elles seront disponibles.

Les clients qui décident plutôt de mettre à jour les instances existantes avec AMI optimisée pour ECS doivent exécuter la commande suivante pour s'assurer qu'ils reçoivent le package mis à jour :

sudo yum update kernel

Une fois que la mise à jour de yum est terminée, un redémarrage est nécessaire pour que les mises à jour prennent effet, comme c'est le cas pour toute mise à jour du noyau Linux.

Nous recommandons aux clients Linux qui n'utilisent pas l'AMI optimisée pour ECS de consulter si nécessaire leur fournisseur de tout autre système d'exploitation, logiciel ou AMI pour ce qui concerne les mises à jour et les instructions. Les instructions concernant Amazon Linux sont disponibles dans le Centre de sécurité de l'AMI Amazon Linux.

Nous travaillons actuellement sur la mise à jour de l'AMI Windows optimisée pour Amazon ECS et mettrons à jour ce bulletin dès que la mise à jour sera disponible. Microsoft fournit les correctifs pour Windows Server 2016. Pour en savoir plus sur la manière d'appliquer ces correctifs aux instances en cours d'exécution, consultez https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.

Elastic Beanstalk

Nous avons mis à jour toutes les plateformes basées sur Linux en y incluant toutes les protections Amazon Linux pour ce problème. Consultez les notes de publication pour connaître les versions spécifiques des plateformes. Nous conseillons aux clients utilisant Elastic Beanstalk d'effectuer la mise à jour de leurs environnements vers la dernière version disponible de la plateforme. Les environnements qui utilisent les mises à jour gérées seront automatiquement mis à jour pendant la fenêtre de maintenance configurée.

Les plateformes basées sur Windows ont également été mises à jour pour inclure toutes les protections EC2 pour Windows pour ce problème. Nous recommandons aux clients d'effectuer la mise à jour de leurs environnements Elastic Beanstalk basés sur Windows vers la dernière configuration de plateforme disponible.

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 au client 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 vulnérabilités inhérentes à ce problème et qui concernent le processus et le noyau ou les processus entre eux-mêmes ne présentent pas de risque pour les clients. À l'heure actuelle, aucune vulnérabilité connue entre processus n'a été constatée pour les deux supports ElastiCache des moteurs de cache.

EMR

Amazon EMR lance des clusters d'instances Amazon EC2 qui exécutent Amazon Linux au nom de clients dans le compte du client. 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 travaillons actuellement à l'intégration du dernier noyau Linux d'Amazon dans une nouvelle version mineure sur la branche 5.11.x et la branche 4.9.x. Les clients pourront créer de nouveaux clusters Amazon EMR avec ces versions. Nous mettrons à jour ce bulletin dès que ces versions seront prêtes.

Pour les versions actuelles d'Amazon EMR et toutes les instances associées en cours d'exécution que les clients sont susceptibles d'avoir, nous recommandons la mise à jour vers le dernier noyau Amazon Linux comme recommandé 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 faciliter la mise à jour et le redémarrage du noyau Linux pour chaque instance de leur cluster de manière continue. Veuillez noter que le redémarrage de certains processus peut avoir une incidence sur les applications en cours d'exécution au sein du cluster.

RDS

Chaque instance de base de données client gérée par RDS est dédiée à l'exécution d'un moteur de base de données pour un seul client, sans aucun autre processus accessible au client et sans possibilité pour les clients d'exécuter du code sur l'instance sous-jacente. Étant donné qu'AWS a terminé la protection de l'infrastructure sous-jacente de RDS, les vulnérabilités inhérentes à ce problème et qui concernent le processus et le noyau ou les processus entre eux-mêmes ne présentent pas de risque pour les clients. À l'heure actuelle, aucune vulnérabilité connue entre processus n'a été constatée pour la plupart des supports RDS des moteurs de base de données. Des détails supplémentaires spécifiques aux moteurs de la base de données figurent ci-dessous et, sauf indication contraire, aucune action du client n'est requise.

Pour les instances de base de données RDS for SQL Server, nous publierons les correctifs du système d'exploitation et du moteur de base de données au fur et à mesure que Microsoft les mettra à disposition, ce qui permettra aux clients d'effectuer la mise à niveau quand ils le désireront. Nous mettrons à jour ce bulletin dès que l'une de ces conditions sera remplie. En attendant, les clients qui ont activé l'extension CLR (désactivée par défaut) devraient consulter les directives de Microsoft concernant la désactivation de l'extension CLR ici : https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server.

Pour RDS PostgreSQL et Aurora PostgreSQL, aucune action de la part du client n'est actuellement requise pour les instances de base de données s'exécutant dans la configuration par défaut. 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) devraient penser à les désactiver et consulter les directives relatives à V8 ici : https://github.com/v8/v8/wiki/Untrusted-code-mitigations.

Aucune action de la part du client n'est actuellement requise 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 que documentée dans VMSA-2018-0002 est présente dans VMware Cloud on AWS depuis début décembre 2017 ».

Veuillez consulter 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 qui utilisent 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 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. Veuillez suivre les instructions fournies par Microsoft ici : https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.

Pour les clients qui utilisent Windows 10 sur Windows Server 2016 :

AWS a appliqué les mises à jour de sécurité aux instances WorkSpaces qui exécutent 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 qui utilisent le modèle BYOL et ceux dont les paramètres de mise à jour ont été modifiés :

Veuillez noter que les clients utilisant le modèle « licence à fournir » (BYOL) et ceux qui ont modifié le paramètre de mise à jour par défaut dans leur WorkSpaces doivent appliquer manuellement les mises à jour de sécurité fournies par Microsoft. Si tel est votre cas, veuillez suivre les instructions fournies par l'avis de sécurité Microsoft ici : https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002. L'avis de sécurité comprend des liens vers des articles de la base de connaissances pour les systèmes d'exploitation Windows Server et Client qui contiennent des informations spécifiques supplémentaires.

Les offres groupées WorkSpaces mises à jour seront bientôt disponibles avec les mises à jour de sécurité. Les clients qui ont créé des offres groupées personnalisées doivent les mettre à jour pour y inclure les mises à jour de sécurité elles-mêmes. Toute nouvelle instance WorkSpace lancée à partir des offres groupées qui ne comprennent pas les mises à jour recevra des correctifs peu après le lancement, sauf si les clients ont modifié le paramètre de mise à jour par défaut de leurs instances WorkSpaces ou installés 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 l'une des options 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 indiquées par Microsoft ici : 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 Packager et Validator existantes. Lancez de nouvelles instances en utilisant nos AMI mis à jour étiquetées « Amazon WAM Admin Studio 1.5.1 » et « Amazon WAM Admin Player 1.5.1 ».