Meltdown und Spectre

Am 4. Januar 2018 wurden Informationen über zwei Angriffe auf aktuelle Prozessor-Architekturen veröffentlicht, genannt „Meltdown“ und „Spectre“, welche auch uns und unsere Kunden betreffen. Während die unterliegenden Probleme ähnlich sind, handelt es sich dabei um zwei unterschiedliche konkrete Angriffe.

Kurzdarstellung der Sicherheitslücken

Grundsätzlich unterstützen CPUs einen gewissen Instruktionssatz. Dieser ist funktional genau definiert, so dass sich Anwendungen darauf verlassen können, dass der Prozessor zum richtigen Resultat kommt. Wie genau der Instruktionssatz in der Praxis implementiert wird, ist jedoch dem Prozessorhersteller überlassen. Um die Ausführungsgeschwindigkeit zu erhöhen, wenden die Prozessorhersteller alle möglichen Tricks an; z.B. versucht der Prozessor, mehrere Instruktionen gleichzeitig abzuarbeiten („pipelining“), oder er versucht zu erraten, welcher Pfad durch Fallunterscheidungen im Programm der wahrscheinlichste ist, und führt diesen auf gut Glück aus, mit dem Risiko, das Resultat verwerfen und nochmal weiter vorne beginnen zu müssen („speculative execution“, „branch prediction“). Diese Mechanismen haben zwar auf das Endresultat einer Berechnung keinen Einfluss, sehr wohl aber auf den zeitlichen Ablauf und den Inhalt der CPU-Caches. Die genannten Angriffe nutzen das nun aus, indem sie den Prozessor dazu verleiten etwas zu tun, was er nicht darf und was er anschliessend auch korrekt verwirft; aber über geschickte Zeitmessungen kann das Programm herausfinden, was für Werte aus dem Speicher dabei verwendet wurden. Über diesen Kniff kann ein entsprechendes Programm unter anderem geschützten Speicher des Systems auslesen und so z.B. Zugriff auf Verschlüsselungs-Keys erhalten. Im Falle von virtualisierten Umgebungen ist das besonders schlimm, denn der Angriff funktioniert auch über die Grenzen virtueller Maschinen hinweg; Es ist so möglich, auf den Speicher von anderen virtuellen Maschinen zuzugreifen.

Die technischen Details sind komplex und sprengen den Rahmen dieses Blog-Artikels bei Weitem, können aber auf der eigens dafür eingerichteten Webseite https://meltdownattack.com nachgelesen werden.

Bewertung

Innerhalb eines einzelnen Systems (ob physisch oder virtuell) haben die Angriffe den Charakter einer Rechteausweitung. Das bedeutet, dass ein einfacher User, der beliebige Software ausführen kann, Zugriff auf das System erhält, welcher nur ein Administrator haben dürfte. Das ist zwar sehr schlecht, aber bei Systemen, bei welchen grundsätzlich nur vertrauenswürdige User Software ausführen können, für sich alleine noch kein Problem. Das trifft typischerweise z.B. auf Web-, File- und Datenbankserver zu.

Bei Systemen, auf welchen beliebige User Software ausführen können, ist die Lücke katastrophal, denn nun ist die Trennung der User oder gar Kunden (Firmen) nicht mehr sichergestellt. Das betrifft z.B. Virtualisierungs-Server (Xen, KVM, VMWare) oder Docker-Server, auf denen beliebige User virtuelle Maschinen beziehen oder Docker-Container ausführen können. Die User können auf solchen Systemen innerhalb einer VM oder eines Docker-Containers bösartigen Code ausführen und Zugriff auf den Speicher anderer VMs oder Docker-Container erhalten. Für derartige öffentliche Virtualisierungsplattformen (z.B. Amazon AWS, Google Compute Engine, Cloudscale) ist daher sofortiges Handeln zwingend nötig.

Massnahmen

Für die gängigen Betriebssysteme stehen Sicherheitsupdates zur Verfügung oder sind in Arbeit. Da sich das Problem auf Ebene Hardware derzeit nicht lösen lässt, modifizieren die Betriebssysteme die Art und Weise, wie sie mit geschütztem Speicher umgehen. Dabei wird der Betriebssystem-Kernel nicht mehr im Speicherbereich jedes Prozesses eingeblendet, sondern ist nur noch nach einem Kontext-Wechsel (Wechsel in eine andere „Speicher-Arbeitsumgebung“) erreichbar.

Dies ist ein massiver Umbau. Einerseits führt er zu einem Performance-Verlust, weil der Kontext-Wechsel für den Prozessor aufwändiger ist als die heutige Umsetzung. Es ist von Geschwindigkeitseinbussen von 5% bis zu 30% die Rede. Wir rechnen für die meisten Anwendungsfälle mit Geschwindigkeitseinbussen von unter 10%, also nicht im spürbaren, aber knapp messbaren Bereich. Andererseits bedeuten solch umfangreiche Umbauten ein Risiko für Bugs und neue, bisher unbekannte Stabilitätsprobleme, weshalb sofortiges Aktualisieren aller Systeme nicht zwingend die beste Vorgehensweise ist.

Da allerdings die Sicherheitsprobleme im Falle von Systemen mit nicht vertrauenswürdigen Usern derart gravierend sind, müssen wir diese Systeme zwingend so bald wie möglich aktualisieren. Das betrifft konkret primär die APPUiO-Public-Plattform; Für alle anderen Systeme evaluieren wir das Vorgehen noch, jedoch werden diese spätestens im nächsten Wartungsfenster am 9. Januar aktualisiert und erhalten dann entsprechend angepasste Linux-Kernel.