Sie betrachten eine frühere Version dieses Sicherheitsberichts. Die aktuellste Version finden Sie unter: "Informationen zu Forschungsergebnissen zur spekulativen Ausführung bei Prozessoren".
Betreff: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754
Aktualisierung vom: 23.01.2018 11:30 Uhr PST
Hierbei handelt es sich um eine Aktualisierung zu diesem Problem.
Ein aktualisierter Kernel für Amazon Linux steht in den Amazon Linux-Repositorys zur Verfügung. EC2-Instances, die ab dem 13. Januar 2018 mit der Amazon Linux-Standardkonfiguration gestartet wurden, enthalten das aktualisierte Paket. Dieses umfasst die aktuellsten, stabilen Open-Source-Sicherheitsverbesserungen von Linux zur Behandlung von CVE-2017-5715 im Kernel und baut auf der zuvor zur Behandlung von CVE-2017-5754 umgesetzten KPTI (Kernel Page Table Isolation) auf. Kunden müssen auf den neuesten Amazon Linux-Kernel oder AMI upgraden, damit die Probleme zwischen Prozessen von CVE-2017-5715 und Probleme zwischen Prozessen und dem Kernel von CVE-2017-5754 in ihren Instances wirksam behoben werden. Weitere Informationen finden Sie unter "Processor Speculative Execution – Betriebssystemaktualisierung".
Unten finden Sie unter "PV Instance-Empfehlungen" weitere Informationen zu paravirtualisierten (PV) Instances.
Amazon EC2
Alle Instances in der Amazon EC2-Flotte sind vor allen bekannten Problemen zwischen Instances von CVE-2017-5715, CVE-2017-5753 und CVE-2017-5754 geschützt. Bei Problemen zwischen Instances wird davon ausgegangen, dass eine nicht vertrauenswürdige Nachbar-Instance den Speicher einer anderen Instance oder des AWS Hypervisors auslesen könnte. Dieses Problem wurde für AWS Hypervisors behoben. Keine Instance kann den Speicher einer anderen Instance lesen. Auch kann keine Instance den ASW Hypervisor-Speicher lesen. Wie zuvor bereits angegeben, haben wir keine spürbaren Auswirkungen auf die Leistung der großen Mehrheit aller EC2 Workloads festgestellt.
Wir haben eine kleine Anzahl von Instance- und Anwendungsabstürzen festgestellt, die durch die Aktualisierung des Intel-Mikrocodes verursacht wurden, und arbeiten direkt mit den betroffenen Kunden zusammen. Wir haben gerade Teile des neuen Intel-CPU-Mikrocodes für die Plattformen in AWS deaktiviert, auf denen wir diese Probleme beobachtet haben. Dies scheint das Problem für jene Instances gemindert zu haben. Alle Instances in der Amazon EC2-Flotte bleiben vor allen bekannten Bedrohungsüberträgern geschützt. Der deaktivierte Intel-Mikrocode bietet zusätzlichen Schutz vor theoretischen Bedrohungsüberträgern aus Ausgabe CVE-2017-5715. Wir gehen davon aus, diese zusätzlichen Schutzfunktionen (zusammen mit einigen zusätzlichen Leistungsoptimierungen, an denen wir gearbeitet haben) in naher Zukunft wieder zu aktivieren, sobald Intel einen aktualisierten Mikrocode zur Verfügung stellt.
Empfohlene Maßnahmen für AWS Batch, Amazon EC2, Amazon Elastic Beanstalk, Amazon Elastic Container Service, Amazon Elastic MapReduce und Amazon Lightsail
Es sind zwar alle Instances der Kunden wie oben beschrieben geschützt, wir empfehlen aber dennoch, dass die Kunden die Betriebssysteme ihrer Instances patchen, damit Probleme zwischen Prozessen oder Prozessen und dem Kernel behoben werden. Weitere Empfehlungen und Anweisungen für Amazon Linux und Amazon Linux 2, CentOS, Debian, Fedora, Microsoft Windows, Red Hat, SUSE und Ubuntu finden Sie unter "Processor Speculative Execution – Betriebssystemaktualisierung".
PV Instance-Empfehlungen
Aufgrund laufender Forschungen und detaillierter Analysen der verfügbaren Patches zu diesem Problem für die Betriebssysteme haben wir ermittelt, dass der Schutz der Betriebssysteme für Fehler zwischen Prozessen paravirtualisierter (PV) Instances unzureichend ist. PV Instances werden zwar von AWS Hypervisors wie oben beschrieben vor Problemen zwischen Instances geschützt, wir empfehlen aber Kunden, die um die Prozessisolation in ihren PV Instances besorgt sind (z. B. die Verarbeitung nicht vertrauenswürdiger Daten, die Ausführung von nicht vertrauenswürdigem Code, das Hosten nicht vertrauenswürdiger Benutzer), für langfristige Sicherheitsvorteile auf HVM Instance-Typen zu migrieren.
Weitere Informationen zu den Unterschieden zwischen PV und HVM (sowie die Dokumentation des Pfads für das Upgrade von Instances) finden Sie unter:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
Bitte wenden Sie sich an den Support, wenn Sie bei einem Upgrade-Pfad für PV Instances Unterstützung benötigen.
Aktualisierungen weiterer AWS-Services
Bei den folgenden Services war das Patchen von im Namen von Kunden verwalteten EC2 Instances erforderlich. Die Arbeiten sind jetzt abgeschlossen und es besteht kein Handlungsbedarf vonseiten der Kunden.
- Fargate
- Lambda
Sofern nicht anders angegeben besteht bei allen weiteren AWS-Services kein Handlungsbedarf vonseiten der Kunden.
ECS-optimiertes AMI
Wir haben die für Amazon ECS optimierte AMI-Version 2017.09.g entwickelt. Diese umfasst alle Schutzmaßnahmen in Bezug auf dieses Problem für Amazon Linux. Wir empfehlen allen Amazon ECS-Kunden das Upgrade auf diese neueste Version, die im AWS Marketplace erhältlich ist.
Kunden, die vorhandene, für ECS optimierte AMI Instances optimieren möchten, sollten den folgenden Befehl ausführen, damit sie das Aktualisierungspaket erhalten:
sudo yum update kernel
Wie bei jedem Update des Linux-Kernels ist nach Abschluss des yum-Updates standardmäßig ein Neustart erforderlich, damit die Updates wirksam werden.
Linux-Kunden, die das für ECS optimierte AMI nicht nutzen, wird empfohlen, sich für Aktualisierungen und Anweisungen an den jeweiligen Betriebssystem-, Software- oder AMI-Drittanbieter zu wenden. Anweisungen zu Amazon Linux erhalten Sie im Amazon Linux AMI-Sicherheitszentrum.
Wir haben die für Amazon ECS optimierte Windows AMI-Version 2018.01.10 veröffentlicht. Einzelheiten zur Anwendung von Patches auf ausgeführte Instances finden Sie unter "Processor Speculative Execution – Betriebssystemaktualisierung".
Elastic Beanstalk
Wir haben alle Linux-basierten Plattformen so aktualisiert, dass alle die Amazon Linux Schutzmaßnahmen für dieses Problem beinhalten. Siehe Versionshinweise für spezifische Plattformversionen. Kunden, die Elastic Beanstalk nutzen, empfehlen wir die Aktualisierung ihrer Umgebungen auf die neuesten verfügbaren Plattformversionen. Umgebungen mit verwalteten Aktualisierungen werden automatisch während des konfigurierten Wartungsfensters aktualisiert.
Windows-basierte Plattformen wurden auch so aktualisiert, dass alle Schutzmaßnahmen für EC2 Windows für dieses Problem eingeschlossen sind. Den Kunden wird empfohlen, Windows-basierte Elastic Beanstalk-Umgebungen auf die neueste verfügbare Plattformkonfiguration zu aktualisieren.
ElastiCache
Mit ElastiCache verwaltete Cache-Knoten von Kunden sind jeweils nur für die Ausführung einer Cache-Engine für einen einzigen Kunden dediziert. Sie haben keine vom Kunden aufrufbare Prozesse und die Kunden können auf der zu Grunde liegenden Instance keinen Code ausführen. Da AWS den Schutz der gesamten ElastiCache zu Grunde liegenden Infrastruktur abgeschlossen hat, sollten für die Kunden keine Probleme zwischen Prozessen und Kernel bzw. zwischen Prozessen untereinander auftreten. Für beide Cache Engines, die von ElastiCache unterstützt werden, sind zu diesem Zeitpunkt keine Probleme zwischen den Prozessen bekannt.
EMR
Amazon EMR startet Cluster von Amazon EC2 Instances, die auf Amazon Linux ausgeführt werden, im Namen von Kunden in deren Konto. Kunden, die um die Prozessisolierung innerhalb der Instances ihrer Amazon EMR-Cluster besorgt sind, sollten wie oben empfohlen ein Upgrade auf den neuesten Amazon Linux-Kernel durchführen. Wir haben den neuesten Amazon Linux-Kernel in die neuen Nebenversionen 5.11.1, 5.8.1, 5.5.1, und 4.9.3 integriert. Die Kunden können neue Amazon EMR-Cluster mit diesen Versionen erstellen.
Für aktuelle Amazon EMR-Versionen und dazugehörige ausgeführte Instances der Kunden empfehlen wir die Aktualisierung auf den neuesten Amazon Linux-Kernel wie oben empfohlen. Bei neuen Clusters können Kunden eine Bootstrap-Aktion zur Aktualisierung des Linux-Kernels verwenden und jede Instance neu starten. Bei ausgeführten Clusters können Kunden das Linux-Kernel-Update rollierend für jede Instance im Cluster ausführen und diese neu starten. Beachten Sie, dass sich der Neustart bestimmter Prozesse auf laufende Anwendungen im Cluster auswirken kann.
RDS
Mit RDS verwaltete Datenbank-Instances von Kunden sind jeweils nur für die Ausführung einer Datenbank-Engine für einen einzigen Kunden dediziert. Sie haben keine vom Kunden aufrufbare Prozesse und die Kunden können auf der zu Grunde liegenden Instance keinen Code ausführen. Da AWS den Schutz der gesamten RDS zu Grunde liegenden Infrastruktur abgeschlossen hat, sollten für die Kunden keine Probleme zwischen Prozessen und Kernel bzw. zwischen Prozessen untereinander auftreten. Für die meisten Datenbanken, die von RDS unterstützt werden, sind zu diesem Zeitpunkt keine Probleme zwischen den Prozessen bekannt. Weitere für die Datenbank-Engine spezifische Informationen finden Sie unten. Sofern nicht anders angegeben, besteht vonseiten der Kunden kein Handlungsbedarf.
Für RDS for SQL Server-Datenbank-Instances werden wir Betriebssystem- und Datenbankmodul-Patches veröffentlichen, sobald Microsoft diese zur Verfügung stellt, sodass Kunden zu einem Zeitpunkt ihrer Wahl ein Upgrade durchführen können. Wir werden diesen Bericht aktualisieren, sobald einer der beiden abgeschlossen ist. In der Zwischenzeit sollten Kunden, die CLR aktiviert haben (standardmäßig deaktiviert), die folgenden Microsoft-Richtlinien zum Deaktivieren der CLR-Erweiterung lesen: https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server.
RDS PostgreSQL und Aurora PostgreSQL: Bei DB Instances, die in der Standardkonfiguration ausgeführt werden, besteht vonseiten der Kunden derzeit kein Handlungsbedarf. Wir bieten den Benutzern von plv8-Erweiterungen entsprechende Patches, sobald diese erhältlich sind. In der Zwischenzeit sollten Kunden, die plv8-Erweiterungen aktiviert haben (standardmäßig deaktiviert), darüber nachdenken, diese zu deaktivieren und folgende V8-Empfehlungen beachten: https://github.com/v8/v8/wiki/Untrusted-code-mitigations.
RDS for MariaDB, RDS for MySQL, Aurora MySQL und RDS for Oracle Database Instances: Vonseiten der Kunden besteht derzeit kein Handlungsbedarf.
VMware Cloud on AWS
Laut VMware "ist die Abhilfemaßnahme wie in VMSA-2018-0002 dokumentiert seit Anfang Dezember 2017 in VMware Cloud on AWS vorhanden".
Weitere Einzelheiten finden Sie im VMware Security & Compliance Blog. Den aktuellen Status können Sie unter https://status.vmware-services.io einsehen.
WorkSpaces
Benutzer von Windows 7 Experience unter Windows Server 2008 R2:
Microsoft hat neue Sicherheitsupdates für Windows Server 2008 R2 in Bezug auf dieses Problem veröffentlicht. Für die erfolgreiche Bereitstellung dieser Aktualisierungen ist eine kompatible Antiviren-Software erforderlich, die auf dem Server wie im Sicherheitsupdate von Microsoft angegeben ausgeführt wird: https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software. WorkSpaces-Kunden müssen handeln, damit sie diese Aktualisierungen erhalten. Bitte befolgen Sie die Anweisungen von Microsoft unter: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.
Benutzer von Windows 10 Experience unter Windows Server 2016:
AWS hat Sicherheitsupdates auf WorkSpaces angewendet, auf denen Windows 10 Experience unter Windows Server 2016 ausgeführt wird. Windows 10 verfügt über die integrierte Antiviren-Software Windows Defender, die mit diesen Sicherheitsupdates kompatibel ist. Vonseiten der Kunden besteht kein weiterer Handlungsbedarf.
Kunden mit eigener Lizenz und geänderten Standardeinstellungen für die Aktualisierung:
Kunden, die WorkSpaces mit eigener Lizenz nutzen oder die Standardeinstellungen für die Aktualisierung in ihren WorkSpaces geändert haben, sollten die von Microsoft bereitgestellten Sicherheitsupdates manuell anwenden. Wenn das für Sie zutrifft, befolgen Sie bitte die Anweisungen von Microsoft Security Advisory unter https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002. Hier finden Sie Links zu Knowledge Base-Artikeln für sowohl Windows Server- als auch Client-Betriebssysteme mit weiteren spezifischen Informationen.
Aktualisierte WorkSpaces Bundles werden bald mit den Sicherheitsupdates verfügbar sein. Kunden, die individuelle Bundles erstellt haben, sollten diese Bundles selbst aktualisieren, damit sie die Sicherheitsupdates enthalten. Neue WorkSpaces, die von noch nicht aktualisierten Bundles ausgeführt werden, erhalten kurz nach dem Start Patches, sofern die Kunden die Standardeinstellung für die Aktualisierung in ihrem WorkSpace nicht geändert oder inkompatible Antiviren-Software installiert haben. In diesem Fall sollten Sie die obigen Schritte zum manuellen Anwenden der von Microsoft bereitgestellten Updates befolgen.
Amazon WorkSpaces Application Manager (WAM)
Wir empfehlen den Kunden, eine der folgenden Handlungsweisen zu wählen:
Option 1: Wenden Sie die Microsoft-Updates manuell auf ausgeführte Instances von WAM Packager und Validator an. Beachten Sie dazu die folgenden Schritte von Microsoft: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. Auf dieser Seite finden Sie weitere Anweisungen und relevante Downloads.
Option 2: Beenden Sie die vorhandenen Instances von Packager und Validator. Starten Sie die neuen Instances mithilfe unserer aktualisierten AMIs mit der Bezeichnung "Amazon WAM Admin Studio 1.5.1" und "Amazon WAM Admin Player 1.5.1".