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

Aktualisierung vom: 05.03.2018 15:00 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 – Betriebssystem-Aktualisierungen“.

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 AWS Hypervisor-Speicher lesen. Wie zuvor bereits angegeben, haben wir keine spürbaren Auswirkungen auf die Leistung der großen Mehrheit aller EC2 Workloads festgestellt.

Mit Stand vom 12. Januar 2018 haben wir die Deaktivierung der Teile des neuen Microcodes für Intel-CPUs der Plattformen in AWS abgeschlossen, bei denen eine geringe Anzahl von Abstürzen und andere unvorhergesehene Verhaltensweisen durch die Aktualisierung des Intel-Microcodes verursacht wurden. Diese Änderung verringerte die Probleme bei diesen wenigen Instances.

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 – Betriebssystem-Aktualisierungen“.

PV Instance-Empfehlungen

Anhand laufender Forschungen und detaillierter Analysen der für dieses Problem verfügbaren Patches der Betriebssysteme haben wir ermittelt, dass der Schutz der Betriebssysteme für die Probleme zwischen Prozessen in paravirtualisierten (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. in Bezig auf die Verarbeitung von nicht vertrauenswürdigen Daten, die Ausführung von nicht vertrauenswürdigem Code, das Hosten von nicht vertrauenswürdigen Benutzern), 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.

Updates weiterer AWS-Services

Die folgenden Services, bei denen das Patchen von im Namen von Kunden verwalteten EC2-Instances erforderlich war, haben alle Arbeiten 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, werden empfohlen, sich für Updates und Anweisungen an den jeweiligen Betriebssystem-, Software- oder AMI-Drittanbieter zu wenden. Anweisungen zu Amazon Linux erhalten Sie im Sicherheitszentrum für Amazon Linux AMI.

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 – Betriebssystem-Aktualisierungen“.

Elastic Beanstalk

Wir haben alle Linux-basierten Plattformen so aktualisiert, dass sie alle 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 den 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. Für neue Cluster können Kunden eine Bootstrap-Aktion zur Aktualisierung des Linux-Kernels verwenden und jede Instance neu starten. Für ausgeführte Cluster können Kunden das Linux-Kernel-Update rollierend für jede Instance im Cluster ausführen und diese neu starten. Bitte beachten Sie, dass sich der Neustart bestimmter Prozesse auf laufende Anwendungen im Cluster auswirken kann.

RDS

Die RDS verwaltete Datenbank-Instances von Kunden werden jeweils nur dafür reserviert, eine Datenbank-Engine für einen einzigen Kunden auszuführen. Diese Instances 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 Datenbank-Engines, 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 des Kunden kein Handlungsbedarf.

Für RDS for SQL Server Database Instances haben wir in den folgenden Engine-Versionen Betriebssystem- und Engine-Patches veröffentlicht, die Patches von Microsoft enthalten:

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)

Die Kunden sollten die Empfehlungen zur Anwendung dieser Patches von Microsoft befolgen und diese zu einem für sie passenden Zeitpunkt anwenden:

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), sich überlegen, diese zu deaktivieren, und den folgenden V8-Leitfaden lesen: https://github.com/v8/v8/wiki/Untrusted-code-mitigations.

RDS for MariaDB, RDS for MySQL, Aurora MySQL und RDS for Oracle Database Instances: Vonseiten des Kunden besteht derzeit kein Handlungsbedarf.

VMware Cloud on AWS

Laut VMware „sind die in VMSA-2018-0002 beschriebenen Korrekturmaßnahmen 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

Für Kunden, die die Windows 7-Oberfläche unter Windows Server 2008 R2 verwenden:

Microsoft hat neue Sicherheits-Updates für Windows Server 2008 R2 in Bezug auf dieses Problem veröffentlicht. Für eine erfolgreiche Bereitstellung dieser Aktualisierungen ist eine kompatible Antiviren-Software erforderlich, die wie im Sicherheits-Update von Microsoft angegeben auf dem Server ausgeführt wird: https://support.microsoft.com/de-de/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software. WorkSpaces-Kunden müssen selbst Maßnahmen ergreifen, um diese Aktualisierungen zu erhalten. Führen Sie die folgenden Anweisungen von Microsoft aus: https://support.microsoft.com/de-de/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.

Für Kunden, die die Windows 10-Oberfläche unter Windows Server 2016 verwenden:

AWS hat Sicherheits-Updates auf WorkSpaces angewendet, auf denen die Windows 10-Oberfläche unter Windows Server 2016 ausgeführt wird. Windows 10 verfügt über die integrierte Antiviren-Software Windows Defender, die mit diesen Sicherheits-Updates kompatibel ist. Vonseiten der Kunden besteht kein 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 WorkSpaces geändert haben, müssen die von Microsoft bereitgestellten Sicherheits-Updates manuell anwenden. Wenn das auf Sie zutrifft, führen Sie die folgenden Anweisungen von Microsoft Security Advisory aus: https://portal.msrc.microsoft.com/de-de/security-guidance/advisory/ADV180002. Hier finden Sie Links zu Knowledge Base-Artikeln für Windows Server- und Client-Betriebssysteme, die detailliertere Informationen enthalten.

Aktualisierte WorkSpaces-Pakete werden bald mit den Sicherheitsupdates verfügbar sein. Kunden, die benutzerdefinierte Pakete erstellt haben, müssen diese Pakete selbst aktualisieren, damit sie die Sicherheits-Updates enthalten. Neue WorkSpaces, die von noch nicht aktualisierten Paketen 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 müssen Sie die obigen Schritte zum manuellen Anwenden der von Microsoft bereitgestellten Updates befolgen.

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. Führen Sie dazu die Anweisungen von Microsoft aus: https://support.microsoft.com/de-de/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".