Vor ziemlich genau einem Jahr, am 3. Januar 2018, wurde die IT Welt mit den Schlagwörtern «Spectre» und «Meltdown» aufgeschreckt. Aber was haben diese offenbar schwerwiegenden Sicherheitslücken mit Cloud Computing zu tun und wie haben die grossen Public Cloud Anbieter darauf reagiert?
Das «Gespenst» und die «Kernschmelze»
Unter den Namen «Spectre» und «Meltdown» wurden am 3. Januar 2018 zwei verwandte Sicherheitslücken der weit verbreiteten x86-Prozessorarchitektur veröffentlicht. Die Sicherheitslücken wurden im Sommer 2017 durch unabhängige Personen und Gruppen gefunden und gemeldet, daran beteiligt waren Google Project Zero (Team von Sicherheitsanalysten bei Google) und Einzelpersonen bzw. Arbeitsgruppen diverser Universitäten.
Bei beiden Sicherheitslücken geht es um die Funktion «Speculative Execution» in heutigen Prozessorarchitekturen. Diese Funktion wurde von den Herstellern entwickelt, um Prozessoren schneller zu machen und bedeutet, dass ein Prozessor mögliche logische Zweige eines Programms bereits ausführt, ohne zu wissen ob sie später überhaupt verwendet werden, also «spekuliert».
Beispiel: Ein Programm sagt: «Wenn A wahr ist, führe Funktion X aus, wenn A falsch ist, führe Funktion Y aus». Der Prozessor kann beide Funktionen X und Y bereits ausführen, bevor das Programm sagt, ob A wahr oder falsch ist und hat somit das Resultat beider Funktionen bereit.
Wenn die Resultate solcher spekulativen Ausführungen nicht gebraucht werden resp. nicht mehr länger im Zwischenspeicher vorgehalten werden können, landen sie in einem ungeschützten Bereich und können dort durch einen «Side Channel» ausgelesen werden.
Der Angriff auf die Schwachstellen besteht darin, den Prozessor gezielt zum Auslagern von sensitiven Informationen in den ungeschützten Bereich zu bringen, um die Daten von dort auszulesen.
Das folgende YouTube-Video der Firma RedHat erklärt die Schwachstellen auf verständliche Weise:
Die Auswirkung und die Reaktionen im Public Cloud Umfeld
Die Tatsache, dass sich mehrere Kunden die gleiche technische Infrastruktur teilen, trägt massgeblich dazu bei, dass im Public Cloud Umfeld in der Regel Implementationen günstiger sind als bei den anderen Arten der Bereitstellung von Cloud-Diensten. Dazu werden Technolgien der Hardware-Virtualisierung verwendet, was ermöglicht, dass mehrere virtuelle Maschinen auf der gleichen Hardware laufen. (Hardware-)Virtualisierung ist keine neue Technologie und wird auch nicht nur im Cloud Umfeld eingesetzt. Im Umfeld von Public Cloud Diensten bedeutet sie demzufolge aber, dass sich mehrere, eigentlich durch diverse Technologien „isolierte“ Kunden, nun den selben verwundbaren Prozessor teilen.
Hanno Boeck, freier Journalist, hat das Problem mit dem folgenden Tweet am 03. Januar 2018 auf den Punkt gebracht:
«We have build this Internet around the idea that one can safely execute code on a machine and isolate it from other code on the same machine. This is an incredibly fragile assumption.»
Bei den grossen Entwicklungen der IT in den letzten Jahren, zu denen die verschiedenen Formen der Virtualisierung gehören, haben wir also immer angenommen, dass die darunterliegende Hardware „sicher“ ist und wir mit dieser Annahme darauf aufbauen können, die Hardware optimal auszunutzen. Der 3. Januar 2018 hat uns eines besseren belehrt.
Aber wie haben nun die grossen Anbieter von Public Cloud Infrastrukturen, namentlich AWS, Google und Microsoft darauf reagiert?
Die Veröffentlichung von Sicherheitslücken bedeutet automatisch auch immer, dass sich diverse Akteure an die Arbeit machen und Code schreiben, um zu versuchen die Sicherheitslücken auszunutzen. Deshalb ist im Normalfall eine bestimmte Gruppe von Personen und Firmen bereits zuvor unter Geheimhaltung über noch nicht veröffentlichte Schwachstellen aufgeklärt und versucht diese zu beheben.
So hatten bei «Spectre» und «Meltdown» auch die drei genannten Anbieter bereits vor der Veröffentlichung Zeit, die Schwachstellen in ihren Umgebungen zu beheben. Jedoch kann diversen Quellen entnommen werden, dass sich die involvierten Parteien auf den Veröffentlichungstag vom 9. Januar 2018 geeinigt hatten und deshalb die unerwartete, frühere Veröffentlichung die genannten Cloud Provider zu Notfallübungen zwang.
AWS
AWS hat die Öffentlichkeit unter dem Security Bulletin «AWS-2018-013» informiert. In der ersten Version vom 03.01.2019 infomiert AWS mit folgendem Statement:
«… All but a small single-digit percentage of instances across the Amazon EC2 fleet are already protected. The remaining ones will be completed in the next several hours, with associated instance maintenance notifications.
While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems. Updates for Amazon Linux have been made available, and instructions for updating existing instances are provided further below along with any other AWS-related guidance relevant to this bulletin. …»
An den folgenden Tagen hat AWS das Bulletin mit detaillierten Informationen zu den eigenen Services, sowie Betriebssystemen von Drittherstellern aktualisiert und die Kunden regelmässig über die wichtigen Schritte auf Kundenseite instruiert. Die letzte Version des Bulletins ist Version 19 vom 5. März 2018.
Diverse Kunden von AWS, darunter auch «Solarwinds», welche basierend auf AWS SaaS Lösungen für ihre Kunden bereitstellt, haben den Einfluss der AWS Massnahmen auf die Performance und Verfügbarkeit gespürt und ausführlich dokumentiert.
Google schreibt am 3. Januar in ihrem Blog folgendes:
«… All G Suite applications have already been updated to prevent all known attack vectors. G Suite customers and users do not need to take any action to be protected from the vulnerability.
GCP has already been updated to prevent all known vulnerabilities. Google Cloud is architected in a manner that enables us to update the environment while providing operational continuity for our customers. We used our VM Live Migration technology to perform the updates with no user impact, no forced maintenance windows and no required restarts. …»
Gemäss diesen Aussagen, war Google und die «Google Cloud Platform (GCP)» am besten auf die frühere Veröffentlichung der Sicherheitslücken vorbereitet und musste nicht informieren, dass gewisse Teile der Infrastruktur erst in den nächsten Stunden «gepatcht» werden. Ebenfalls macht Google ein klares Statement, dass sie die «VM Live Migration» Technologie eingesetzt haben und gibt somit Microsoft einen Seitenhieb, da Microsoft die Kunden zum Neustart von VMs auffordern musste.
Microsoft
Microsoft hat ebenfalls am 3. Januar seine Cloud Kunden mit dem Security Blog «Securing Azure customers from CPU vulnerability» infomiert:
«… The majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect. Many of you have received notification in recent weeks of a planned maintenance on Azure and have already rebooted your VMs to apply the fix, and no further action by you is required.
With the public disclosure of the security vulnerability today, we are accelerating the planned maintenance timing and will begin automatically rebooting the remaining impacted VMs starting at 3:30pm PST on January 3, 2018. The self-service maintenance window that was available for some customers has now ended, in order to begin this accelerated update. …»
Die Aussagen von Microsoft erklären einerseits, wieso Kunden bereits vorher zu einem Neustart ihrer Systeme aufgefordert wurden, andererseits sieht man auch deutlich, dass Microsoft mit der Veröffentlichung der Sicherheitslücken erst später gerechnet hat.
Sind die Sicherheitslücken nun geschlossen?
Nein. Anders als bei einer Sicherheitslücke im Code einer Applikation, bei der der Hersteller einfach die Lücke in Form eines Updates schliessen kann, sprechen wir hier über Sicherheitslücken in der grundlegenden Architektur der heutigen Prozessor-Generationen.
Die «Patches» diverser Hersteller von Betriebssystemen und Applikationen müssen in diesem Zusammenhang wirklich nur als «Pflaster» angesehen werden, bei denen versucht wird, die bekannten Angriffe auf die Sicherheitslücken zu verhindern. Da die eigentlichen Sicherheitslücken nicht einfach geschlossen werden können, werden laufend neue mögliche Angriffe gefunden und publiziert, so zum Beispiel am 14. November 2018.
