Selbstheilende Software Spectre: Den Datenklau verhindern

Software-Entwicklung ist ein schwieriges Geschäft. Es geht darum, Computern eindeutig zu sagen, was sie tun sollen – absolut zuverlässig, absolut präzise. Aber das Umfeld verändert sich ständig. Für Anwendungen, die bereits implementiert sind und operativ genutzt werden, stellt das ein Risiko dar. Vor allem im IoT-Bereich, wo weder breitbandiges Internet noch die notwendige Rechenkapazität verfügbar ist, um mit Updates und zusätzlichen Sicherheitslösungen für Schutz zu sorgen. Im schlimmsten Fall werden alte Geräte für neue Einsatzszenarien genutzt. Etwa, wenn ein vor 20 Jahren für geschlossene Kliniknetze entwickeltes medizinisches Gerät nun über das Internet kommunizieren soll. Das gilt analog für Controller im industriellen Einsatz und für zahllose Legacy-Systeme, die weltweit im Einsatz sind.

Zu den Veränderungen des Umfelds zählt auch, dass bei Altsystemen immer wieder neue Sicherheitslücken gefunden werden. Ein prominentes Beispiel dafür war der so genannte „Heartbleed-Bug“, der ältere Versionen der Verschlüsselungsbibliothek OpenSSL angreifbar machte. Die Sicherheitslücken Spectre und Meltdown sind ähnlich gelagert, auch wenn sie technologisch sehr unterschiedlich sind. Beide erlauben es, sensible Daten offenzulegen. War die Ursache bei Heartbleed nur ein Buffer Overflow in der Software, liegen die Wurzeln von Spectre und Meltdown deutlich tiefer. Der Fehler befindet sich direkt in der Prozessorarchitektur – fast alle modernen Prozessoren sind betroffen. Und Patches oder Updates gestalten sich extrem schwierig.

Der Prozessor spekuliert

Betroffen ist dabei ein Merkmal heutiger CPUs, das entscheidenden Anteil an der hohen Verarbeitungsgeschwindigkeit hat: Speculative oder Out-of-Order Execution. Dabei versucht der Prozessor im Falle einer IF-Verzweigung im Code zu erraten, welcher Zweig der richtige ist. Die erwarteten Code-Teile können dann vorab berechnet werden. Ist die Vorhersage der CPU falsch, wird der vorberechnete Code-Zweig zurückgerollt und stattdessen der richtige Zweig abgearbeitet. Um möglichst genaue Vorhersagen treffen zu können, speichert der Prozessor das Ergebnis der bisherigen Verzweigungen im Branch History Buffer (BHB).

Teile des Codes werden also von modernen Prozessoren spekulativ ausgeführt, bevor das Ergebnis einer bedingten Anweisung feststeht, um die Arbeitsgeschwindigkeit zu erhöhen. Dabei kann es passieren, dass der spekulativ ausgeführte Code durchaus sicherheitskritisch ist. In den meisten Fällen spielt das aus Security-Sicht keine große Rolle, der Rollback funktioniert in der Regel reibungslos. Allerdings gibt es dabei zwei Ausnahmen: Weder Cache noch BHB werden dadurch zurückgesetzt, da das erhebliche Auswirkungen auf die Performance des Prozessors hätte. Und genau hier setzen Spectre und Meltdown an, um den Kernel-Speicher aus dem nicht-privilegierten User-Space heraus auszulesen. Insgesamt umfassen die beiden Sicherheitslücken drei Angriffsvektoren. Im Falle von Spectre sind es zwei: Branch Target Injection (CVE-2017-5715) und Bounds Check Bypass (CVE-2017-5753).

Insgesamt sind Spectre und Meltdown durch ihre vielen Einzelschritte recht komplex auszunutzen, die jeweiligen Schritte hingegen stellen für einen erfahrenen Entwickler keine unlösbaren Probleme dar. So etwa das Bestimmen der Cache-Zugriffszeiten, das für Rückschlüsse auf den Inhalt des Kernel-Speichers wichtig ist. In Assembler kann das zum Beispiel so aussehen:

lfence
rdtsc                     ; get the time stamp counter
mov   BL,[RSI]
shl   RDX,32              ; mov EDX to the high double word
add   RAX,RDX             ; add it to the low double word
mov   R15,RAX
lfence
rdtsc                     ; get the time stamp counter
shl   RDX,32              ; mov EDX to the high double word
add   RAX,RDX             ; add it to the low double word
sub   RAX,R15

Retpolines als erste Hilfe

Wann die Sicherheitslücke in den Prozessoren endgültig beseitigt wird, ist bislang unklar. Bis dahin müssen Unternehmen ihre Anwendungen durch entsprechende Aktualisierungen schützen. Ein Ansatz dabei ist Retpoline von Google. Der Begriff ist eine Verkürzung von Return Trampoline und basiert im Wesentlichen darauf, die Ausführung von spekulativem Code durch eine Endlosschleife zu verhindern. Retpoline schützt gegen Branch Target Injections, nicht jedoch gegen Bounds Check Bypass.

Um die Sicherheitslücke zu beseitigen, muss also der Quellcode angepasst werden. Mit allen Aufwänden, die sich daraus ergeben: Das Problem genau identifizieren, den neuen Code entwickeln, neu kompilieren, testen und flächendeckend ausrollen. Für viele Gerätearten ist das aber schlicht nicht möglich. Oft ist der Quellcode aus unterschiedlichen Gründen nicht verfügbar, etwa bei älteren Geräten. Nur der vorhandene, ausführbare Binärcode auf dem Gerät steht zur Verfügung, um eine vorhandene Schwachstelle abzusichern. Hier wäre es hilfreich, einfach die Binärdatei zu aktualisieren und wieder auszurollen.

Ein in der Praxis erfolgreicher Ansatz hierfür wurde im Rahmen der Cyber Grand Challenge (https://www.darpa.mil/program/cyber-grand-challenge) der amerikanischen Defense Advanced Research Projects Agency (DARPA) entwickelt. Die dem US-Verteidigungsministerium unterstellte Behörde ist für die Entwicklung neuer Technologien für das Militär zuständig. Das Ziel der Cyber Grand Challenge war es, eine Software zu entwickeln, die in den oben beschriebenen Szenarien dazu in der Lage ist, Software automatisch gegen neue Bedrohungen abzusichern. Einer der Teilnehmer der Cyber Grand Challenge war Grammatech.

Autonomes Patchen funktioniert

Die Challenge hat deutlich gezeigt, wie extrem wichtig die automatische Absicherung von Software gegen neue Angriffsszenarien in bestimmten Fälle ist. Grammatech hat die dabei gewonnenen Erkenntnisse weiterentwickelt und bietet damit in Form der Cyber Hardening Services eine kommerzielle Dienstleistung an. Die Basis dafür bildet die Möglichkeit, binäre Dateien zu analysieren. Diese Analyse binären Codes wird üblicherweise von Unternehmen mit erhöhtem Sicherheitsbedürfnis dazu genutzt, um Code aus externen Quellen genau unter die Lupe zu nehmen. Die Technologie dahinter ist in der Lage, den Binärcode in ein exaktes Modell der Programmlogik im Speicher zu überführen. Dieses Modell kann dann analysiert werden, um Sicherheitslücken aufzudecken. Dabei handelt es sich grundsätzlich um das gleiche Verfahren wie bei der statischen Analyse von Quellcode. Buffer Overflows, statische Passwörter, fehlerhaft eingesetzte Krypto-Bibilotheken und zahlreiche andere Probleme lassen sich damit sicher aufspüren.

Sind die potenziellen Sicherheitslücken bekannt, kann eine Lösung dafür gesucht werden. Sofern der Quellcode vorhanden ist, kann dieser entsprechend angepasst werden. Doch in vielen Fällen ist dieser Ansatz nicht möglich, etwa aus Zeit- oder Ressourcengründen. Die Cyber Hardening Services von Grammatech setzen deswegen direkt auf den Binärcode. Anhand des für die Analyse erstellten Modells wird die Schwachstelle ohne Umwege im Binärcode beseitigt, indem das Modell entsprechend transformiert und daraus eine neue Binärdatei erzeugt wird. Nach heutigem Stand dieser noch sehr jungen Technologie können nicht alle Probleme auf diese Art beseitigt werden. Aber bei verschiedenen Szenarien funktioniert das schon sehr gut.

Auf dem Weg zur selbstheilenden Software

Ein zentrales Anliegen dabei ist aktuell die Spectre-Lücke in ihren beiden Varianten. Der Retpoline-Ansatz von Google als Schutz vor Branch Target Injections erfordert eigentlich die Neukompilation der Quellen. Die Cyber Hardening Services hingegen erkennen auf Basis der Binärdateien selbstständig, an welchen Stellen die Retpolines eingefügt werden müssen. Selbstverständlich muss auch in diesem Fall die modifizierte Anwendung getestet und funktional überprüft werden. Doch zumindest das aufwändige und letztlich auch teure manuelle Überarbeiten des Quellcodes und das Kompilieren entfällt. Auf dem Weg zu selbstheilenden Systemen ist damit ein erster, großer Schritt gemacht. Es geht zwar noch nicht vollkommen selbsttätig, aber hier ist in Zukunft noch Spannendes zu erwarten. Denn in einer digitalen, IoT-geprägten Welt stößt das manuelle Patchen an seine Grenzen. Schon alleine deswegen, weil die Ressourcen der Entwicklungsabteilungen für die Vielzahl der unterschiedlichen, verteilten Clients nicht ausreichen werden.