CPU-Sicherheits­prob­lem: Insecurity by design

Intel: Wir nicht, die anderen auch.
 
Gestern haben wir kurz über ein neu bekannt gewordenes, potentiell äusserst schwerwiegendes Sicherheitsproblem in Intel-CPUs berichtet. Inzwischen sind neue Details dazu veröffentlicht worden und wir hatten etwas mehr Zeit, uns mit den Berichten zu beschäftigen.
 
Die Kurzzusammenfassung: Das Problem existiert nicht nur auf Intel-CPUs, sondern auch auf AMD-, ARM- und möglicherweise weiteren CPUs.
 
Das Problem entsteht aus einer schon seit 20 Jahren von vielen Herstellern eingesetzten Funktion von CPUs, der sogenannten "spekulativen Codeausführung", welche ihre Leistung erhöhen soll. Diese Funktion kann durch Programme so manipuliert werden, dass es möglich wird, heikle Daten aus dem Kernel eines Betriebssystems auszulesen, darunter auch Passwörter oder kryptographische Schlüssel. Technische Details dazu, wie dies möglich ist, findet man unter anderem in einem Blogbeitrag von Googles Sicherheitsteam Project Zero.
 
Das Problem ist aber noch schwerwiegender, es geht nicht nur um einzelne Systeme. Wie Google warnt, haben Tests gezeigt, dass es möglich ist, durch eine Attacke, die in einer virtuellen Maschine erfolgt, auf den physischen Speicher eines Hosts zuzugreifen. Darüber wiederum könnten Daten in einer anderen virtuellen Maschine auf demselben Host abgegriffen werden.
 
Bisher haben die Security-Experten zwei verschiedene Methoden entdeckt, um das Sicherheitsproblem auszunützen, und ihnen die Codenamen "Meltdown" und "Spectre" gegeben. Die Methode "Meltdown" funktioniert bisher nur für Angriffe auf Intel-Systeme. Spectre dagegen ermöglicht auch Angriffe auf AMD- und ARM-Prozessoren.
 
Patches? Jein
Aber es existieren schon Sicherheitspatches für einige Betriebssysteme, beziehungsweise sie kommen bald. Im Falle von Windows dürften sie am nächsten Dienstag im Rahmen des Patch Tuesday ausgeliefert werden.
 
Allerdings verhindern die meisten Patches vor allem, dass Programme die spezifisch auf Intel-CPUs zielende "Meltdown"-Methode ausnützen können. Unglücklicherweise, so sagen viele Security-Experten, sei es viel schwieriger, die allgemeinere "Spectre"-Methode in allen Aspekten abzublocken. Dafür gebe es einzelne Möglichkeiten, aber eine generell wirksame Methode, um die Ausnützung der spekulativen Exekution für böswillige Zwecke zu verhindern, sei bisher nicht bekannt.
 
Ausserdem kann man durch Patches auf Betriebssystem- oder Programmebene das grundlegende Problem in der CPU-Hardware natürlich nicht beheben. Und die Patches beruhen darauf, dass die leistungsfördernde "speculative execution" verhindert beziehungsweise eingeschränkt wird. Das bedeutet logischerweise, dass die Leistung der CPUs ebenfalls gesenkt wird. Wie sehr, dürfte aber bei jeder Applikation unterschiedlich sein. In den meisten Fällten sollte es sich um geringe Leistungseinbussen handeln.
 
Intels Statement
Wie bereits geschrieben, wurde die Sicherheitslücke bereits vor einiger Zeit entdeckt, aber nicht publik gemacht. Die Tech-Industrie arbeitete seit der Entdeckung daran, die Schwachstelle mit Software Updates zu schliessen, bevor sie der Öffentlichkeit bekanntgegeben wurde. Die Veröffentlichung war für den 9. Januar geplant. Einige Unternehmen zogen sie aber auf Mittwoch vor, als spekulative Berichte über eine Sicherheitslücke in Intel-Chips die Runde machten.
 
Erst gestern Abend reagierte Intel mit einem Statement auf diese Veröffentlichungen. Wie nicht anders zu erwarten, versucht der Chipriese abzuwiegeln. Allerdings auf eine eher… Nun, urteilen Sie selbst.
 
So schreibt Intel beispielsweise, dass gewisse Methoden, böswillig eingesetzt, das Potential hätten, sensible Daten von Computern abzugreifen, die "so funktionieren, wie sie designed wurden." Beruhigend, nicht wahr?. Deshalb sei es auch nicht korrekt zu sagen, dass die Intel-Produkte einen Bug beziehungsweise einen Defekt aufweisen würden. Und ausserdem seien ja auch andere CPU-Hersteller betroffen.
 
Letzteres stimmt natürlich, aber "wir nicht, die anderen auch" war schon immer eine schwache Verteidigung. (hjm)