Viele Berichte heben die Tatsache hervor, dass seit den Neunzigerjahren keine Änderungen in den Designs von Prozessoren vorgenommen wurden. Das stimmt erst einmal grob. Um die Leistung von Prozessoren zu erhöhen, wurden bestimmte Modelle wie „speculative execution“ entwickelt und sowohl von Intel als auch AMD sowie Cyrix verwendet. Diese Modelle bieten zahlreiche Vorteile gegenüber den Methoden in älteren Prozessoren, unter Anderem höhere Leistung bei bestimmten Operationen.
Ganz nah dran: von fest verdrahteten zu veränderbaren Instruktionen
Wenn man sich mit diesem Thema beschäftigt, bewegt man sich jenseits der Ebene, auf der die meisten Nutzer sich aufhalten. Alles, was wir jeden Tag an unseren Rechnern tun, tun wir in Software. Eine CPU kann allerdings mit einem Programm nichts anfangen, da es zumeist in einer „höheren“ Programmiersprache (wie Java, C, C++, C# usw) verfasst ist, die für Menschen verständlich und nachvollziehbar ist. Eine CPU spricht jedoch eine komplett andere Sprache als der Mensch. Diese Sprache wird „Mikrocode“ genannt. Ihr „Vokabular“ ist in einem eigenen Speicherbereich des Prozessors abgelegt. Dieser Speicherbereich kann bei Bedarf auch aktualisiert werden, um die Verarbeitung bestimmter Instruktionen effizienter zu gestalten oder Fehler zu beheben. Im Unterschied dazu waren auf älteren Prozessoren wie dem weit verbreiteten 8-bit-Prozessor MOS 6502 die einzelnen Befehlssätze des Prozessors noch fest verdrahtet und konnten auch nicht nachträglich geändert werden. Somit war das Beseitigen von Bugs während der Entwicklungsphase in diesen Prozessoren auch sehr mühselig – und wurden Fehler gefunden, nachdem eine CPU auf dem Markt war, konnte man nur die komplette CPU austauschen, was mit kostspieligen Rückrufaktionen verbunden war.
Bis hinein in die Achtziger- und teils in die frühen Neunzigerjahre wurden viele Programme noch in Assembler geschrieben, da andere Programmiersprachen entweder noch nicht erfunden oder noch nicht leistungsfähig genug waren, um die an ein Programm gestellten Anforderungen zu erfüllen. Diese Sprache ist nahe genug an der Hardware, um hohe Performance zu bieten und noch menschenlesbar genug, um von Programmierern genutzt werden zu können. Die Assembler-Befehle können in den meisten Fällen direkt in Mikrocode übersetzt werden.
Die Verwendung von änderbarem Mikrocode erleichtert es, neue Prozessoren zu entwickeln: Schaltungen müssen so nicht mehr komplett neu entworfen werden, was Kosten und Zeit spart und gleichzeitig eine Optimierung der Leistung ermöglicht.
Risikobewertung
Dass man mit Hilfe von Software-Tricksereien auf den CPU-internen Speicher zugreifen kann, in dem Informationen abgelegt werden, war jedoch nie ein relevantes Risiko-Szenario. Zum Einen benötigt man das entsprechende Wissen über die Prozessoren, zum anderen ist es alles andere als trivial, sich diese Informationen nutzbar zu machen. Als akademisches Konstrukt existiert dieses Szenario schon länger – aber eben nur als solches.
Das Problem hier ist: alle modernen Bedrohungsszenarien sind erst einmal akademisch – bis jemand sie in die Tat umsetzt.
Hersteller haben hier eine weitere Lektion gelernt, nämlich dass sie auch die prozessorinterne Kommunikation absichern müssen. Dass dies bisher nicht geschehen ist, kann man den Herstellern durchaus zum Vorwurf machen. Das wäre allerdings zu einfach gedacht.
Nicht ganz so einfach
Man würde hier implizieren, dass man fehlerfreie Hardware entwickeln kann, die nicht mehr nachgebessert werden muss. Das entsprach noch nie und entspricht auch jetzt nicht den Tatsachen. Es gibt auch aus anderen Geschäftsbereichen reichlich Beispiele dafür. Nehmen wir die Luftfahrtindustrie: Dinge, über die man sich anfangs nie Gedanken gemacht hat, weil sie einfach funktionierten, stellten sich im Nachhinein als Risikofaktor heraus, der ein Umdenken erforderlich macht.
Ein Beispiel: Es gibt einen guten Grund dafür, dass bei Passagierflugzeugen die Fenster mehr oder weniger rund sind bzw stark abgerundete Ecken haben.
Der Grund: die de Havilland Comet, einer der ersten kommerziellen Passagierjets der Nachkriegszeit, hatte ursprünglich große eckige Fenster, wie man sie von Autos, Zügen, älteren Flugzeugen und Bussen seit Jahrzehnten gewohnt war. Nach mehreren Abstürzen, bei denen Menschen ums Leben kamen, stellte sich jedoch nach ausführlichen Tests heraus, dass speziell in den Ecken der Fenster und Türen verstärkt Materialermüdung auftrat, die durch den Druckausgleich auf Reiseflughöhe verstärkt wurde. Die Folge war ein plötzlicher Druckverlust, der für die Strukturelle Integrität der Flugzeuge katastrophal war.
Die Probleme wurden erkannt und für alle nachfolgenden Flugzeuge behoben. Heute sind die Rundungen in Flugzeugen für uns vollkommen normal. Dieses konkrete Beispiel hat uns jedoch nicht nur kleinere und rundere Fenster an Passagierflugzeugen beschert, sondern ist auch einer der Gründe, aus denen moderne Flugzeuge mit einer „Black Box“ (die übrigens trotz ihres Namens nicht schwarz ist, sondern meist leuchtend orange) ausgestattet sind. Es gibt noch zahlreiche andere Beispiele wie etwa den in Fahrzeugen verwendeten CAN-Bus, der nie für eine Vernetzung nach außen vorgesehen war, aber das Prinzip ist dasselbe: Dinge, die zunächst als unproblematisch galten, stellen sich als Problem heraus, werden behoben und die Entwicklung geht weiter.
Mit Meltdown und Spectre wird es nicht anders laufen. Meltdown und Spectre sind übrigens nicht die ersten Bugs, die in CPUs gefunden und gemeldet wurden. In diesem Zusammenhang sei an den F00F-Bug erinnert, der Mitte der Neunziger bekannt wurde. Auch damals konnte die durch den Bug entstehende Problematik durch Workarounds im Betriebssystem umgangen werden. Ohne Patch konnte es passieren, dass ein betroffener Rechner abstürzte. Datenverluste waren so praktisch unvermeidbar.
Wenn es um die Aktualisierung von Mikrocode geht, dann ist aus Sicht der Hersteller immer Vorsicht geboten. Abwärtskompatibilität ist ein sehr wichtiger Faktor bei der Entwicklung. Dieser ist umso wichtiger, wenn es um kritische Infrastrukturen geht, in denen eben noch oft ältere Hardware zum Einsatz kommt. Ein hastig nachgeschobenes Update, das kritische Infrastrukturen zum Absturz bringt, wäre das Letzte was Hersteller und Kunden jetzt gebrauchen können. Die geplanten Updates verzögern sich ohnehin schon - so hat Intel den "Spectre"-Patch für einige CPU-Modelle kürzlich zurückgezogen, da der Patch bei einigen Systemen zu spontanen Abstürzen führte.
Was können betroffene Benutzer und Unternehmen tun?
Es sollte zunächst davon ausgegangen werden, dass eigene Geräte die Sicherheitslücke aufweisen. Sie betrifft prinzipiell alle CPUs, die nach 1994 auf den Markt kamen.
Wirksame Gegenmaßnahmen beschränken sich derzeit auf die Installation der Updates, die von Herstellern wie Microsoft und Apple herausgebracht wurden.
Um auf künftige Sicherheitslücken zeitnah reagieren zu können, ist es gerade für Betriebe wichtig, eine gute Patch Management-Strategie zu entwickeln, mit der im Bedarfsfall zeitnah kritische Updates im Unternehmensnetzwerk verteilt werden können.
Hierbei sollten Nutzer und Administratoren auch darauf achten, aus welcher Quelle die Patches stammen, die heruntergeladen werden. Mittlerweile gibt es nämlich auch Schadsoftware, die von der Verunsicherung von Nutzern zu profitieren versuchen: es existiert mindestens eine Schadsoftware, die sich als Patch für Spectre/Meltdown ausgibt, in Wirklichkeit aber den Rechner zum Teil eines Botnetzes macht.
Gerade für Unternehmen ist es entscheidend, längerfristig zu denken.
Zwar hat Intel Microcode-Updates für CPUs ab Baujahr 2013 in Aussicht gestellt, die Frage bleibt allerdings, inwieweit künftige Prozessorgenerationen ebenfalls anfällig für die Sicherheitslücken sind. Da heutzutage viele Betriebe Daten verarbeiten, die von extern eingespeist werden, sollte man hier im Hinterkopf behalten, dass man auch in solchen Daten theoretisch Schadcode verstecken kann, der die Sicherheitslücke ausnutzt. Daher sollten Unternehmen bei der Neuanschaffung von Hardware auch immer prüfen, ob derzeit bekannte Sicherheitslücken in neuen Geräten schlummern und diese Gegebenenfalls vor Inbetriebnahme mit aktuellen Patches versorgen. Dies ist umso wichtiger, als dass das öffentliche Interesse an einer Sicherheitslücke schnell erlahmt und nicht mehr unbedingt im Fokus von IT-Verantwortlichen ist.
Wo immer „fremde“ Daten verarbeitet werden, muss eben auch die Entscheidung getroffen werden, inwieweit man der Quelle vertraut und wie man sicherstellt, dass eine Manipulation keine weiterreichenden Konsequenzen hat.
Ein System mit eingespeisten Daten zu manipulieren ist übrigens auch keine neue Idee. Selbiges wurde bereits erfolgreich an einer DNA-Sequenziermaschine getestet, in die man mit Hilfe einer speziell präparierten DNA-Probe Schadcode eingeschleust hat. Praktisch relevant ist der Angriff (noch?) nicht, aber es wurde bewiesen, dass er durchführbar ist.
Update 15.Februar 2018: G DATA veröffentlicht kostenlosen Scanner für Meltdown & Spectre
Ab sofort steht auf unserer Webseite ein Werkzeug zur Verfügung, mit dem jeder seinen Rechner auf Anfälligkeit für die Spectre- und Meltdown-Angriffe prüfen kann.
Dieser Scanner ist kostenlos, mit installierten Sicherheitsprogrammen kompatibel und kann auf unserer Webseite heruntergeladen werden.
