Kritische Systeme vor Spectre und Meltdown schützen

Trennung ist ein fundamentales Konzept bei der funktionalen und bei der Datensicherheit und kommt bei High-Assurance-Systemdesigns seit Jahrzehnten zum Einsatz. In Bezug auf funktionale Sicherheit stützt sich die Partitionierung von Flugverkehrsystemen (DO-178C, CAST 32, Integrated Modular Avionics) auf die Trennung von Komponenten, um deren Schutz zu gewährleisten. Was die  Datensicherheit betrifft, ist Trennung das Rückgrat der strengsten Standards: Multiple-Independent-Levels-of-Security-Architekturen (MILS) des US-amerikanischen Verteidigungsministeriums sind beispielsweise Implementierungen von Sicherheitsmodellen, die auf den Grundsätzen der Trennung und des kontrollierten Informationsflusses basieren. Innerhalb dieser Kontexte bedeuten Trennungsfehler geradezu zwangsläufig Sicherheitsmängel. Somit kann Meltdown Entwicklern von kritischen eingebetteten Systemen als praktischer Lackmustest fungieren, der aufzeigt, wo eine sichere Trennung erreicht wurde und wo nicht.

Trennung wahren, Vertrauen wiederherstellen

Obwohl sich die Angriffsszenarien in wichtigen Merkmalen unterscheiden, handelt es sich sowohl bei Meltdown als auch bei Spectre um sogenannte Side-Channel-Attacks. Der Angreifer verwendet eine fortgeschrittene, subversive Methode (Cache-Timing-Analyse), um den Zustand des Cache zu untersuchen und dabei die Werte des temporär referenzierten Kernel-Speichers abzuleiten. Obwohl jede Variante einen anderen Designfehler ausnutzt, sind beide Szenarien unumstritten in der Lage, die Sicherheitskontrollen herkömmlicher Betriebssysteme und Hypervisoren zu umgehen – ohne dabei administrativen Zugriff zu benötigen oder die privilegierte Codebasis infiltrieren zu müssen. Erhält ein Angreifer administrative Zugriffsberechtigung durch diese Art von Side-Channel-Techniken, ist er in der Lage, das gesamte System zu übernehmen.

Meltdown und Spectre wurden als hardwareimmanente Prozessor-Designprobleme identifiziert. Daher sind Software-Entwickler unter Umständen fälschlicherweise der Meinung, nichts tun  zu können, um die Designs ihrer High-Assurance-Systeme zu schützen. Durch eine entsprechende Implementierung bewährter High-Assurance-Grundsätze lassen sich kritische Systemelemente komplett vor Meltdown schützen und die negativen Auswirkungen von Spectre wesentlich mildern. Außerdem sind anfällige Systeme oftmals ohne Neudesign entsprechend widerstandsfähig gestaltet.

Was das Angriffsszenarium Meltdown im Detail bedeutet, erfahren Sie auf der nächsten Seite.

Meltdown im Detail

Bei Meltdown ist ein nichtprivilegierter Angreifer in der Lage, den gesamten physischen Speicher eines Betriebssystems oder Hypervisors mit etwa 100 bis 500 KB/s auszulesen. Dies ist durch das Ausnutzen eines verbreiteten CPU-Performancefeatures, der Out-of-Order Execution (OoOE) möglich. Dieser Exploit greift zwei Optionen beim Kernel-Design an: einen allgemeinen Zugriff auf Systemspeicher und die kombinierte User- und Kernel-Space-Speicherverwaltung.

Bild 1: Angriffspunkt für Meltdown: Adressübersetzung und Aufzeichnungen des OS-Kernels an den Systemspeicher kombiniert im gleichen Tabelleneintrag. Lynx

Fast alle OS/Hypervisor-Kernel-Designs verlassen sich auf Software-Leistungsoptimierungsmethoden, bei denen sowohl virtuelle Benutzerprozess-Adresskonvertierungen als auch Kernel-Adresskonvertierungen in den gleichen Lookup-Tabellen gespeichert werden, damit der Kernel Daten schnell zu und vom Anwendungsspeicher übertragen kann und damit vom Adresskonvertierungs-Caching profitiert. Bild 1 zeigt die Übersetzung von virtuellen zu physikalischen Adressen von Nutzer-Anwendungen und die herkömmlichen Aufzeichnungen des Hypervisor/OS-Kernels an den Systemspeicher kombiniert im gleichen Tabelleneintrag pro Applikation.

Studien zu Meltdown haben gezeigt, dass OoOE die Berechtigungsauflösung zwischen Benutzer- oder Kernel-Adress-Lookups zurückstellt, was Benutzeranwendungen ermöglicht, direkt auf virtuelle Kernel-Adressen in ihrem Programm zuzugreifen, um „illegal“ (temporär) referenzierten Speicher im CPU-Cache zu laden. Die CPU gibt letztlich einen Speicherzugriffsausnahmefehler für die Speicherreferenz des Angreifers auf Kernel-Adressen aus, stellt jedoch nicht den Zustand des Cache wieder her. Daraufhin verwendet der Angreifer eine Cache-Timing-Analyse, um den Zustand des Cache zu untersuchen und dabei die Werte des temporär referenzierten Kernel-Speichers abzuleiten.

Lösung für Meltdown

Die einfache Lösung für Meltdown ist Seitentabellenisolation und der Least-Privilege-Speicherzugriff. Beide Methoden sind beim Lynx-Secure-Separation-Kernel seit seiner Einführung integriert. In Lynx-Secure erfolgt die Speicherung aller Kernel-zu-physischen-Adressen in einer anderen Seitentabelle anstatt in Anwendungs-/Gast-OS-Seitentabellen.

Lynx-Secure ist eine High-Assurance-Virtualisierungstechnologie auf der Grundlage robuster Designprinzipien. Alternativ zu herkömmlichen zentralisierten ressourcen- und dienstorientierten Designs, wie sie bei den meisten Betriebssystemen und Hypervisoren zu finden sind, ist die Technologie sowohl aus Kernel-Konstruktions- als auch aus Benutzermodell-Perspektive tief in einem Least-Privilege-Design verwurzelt. Sie erzwingt einen dezentralisierten Designansatz, bei dem jede Gast-Computing-Umgebung mit lokal verwalteten Ressourcen unabhängig ist.

Bild 2: Beim virtuellen Speicherverwaltungsschema Lynx-Secure besitzt der Kernel seine eigene Seitentabelle. Lynx

Durch die Autonomie jeder Gastumgebung wird vermieden, dass der Kernel globale Dienste bereitstellen muss, was die Durchführung von Meltdown aushebelt. Bild 2 zeigt das virtuelle Speicherverwaltungsschema von Lynx-Secure, in dem der Kernel seine eigene Seitentabelle hat und Speicherplatz nur für einen minimalen Gebrauch vorsieht.

Auf der folgenden Seite untersucht der Beitrag Spectre und zeigt, wo die Attacke konkret ansetzen kann.

Untersuchung von Spectre

Bei Spectre kann ein Angreifer nicht autorisierten Speicher von einem Adressraum einer Anwendung sowie adressraumübergreifend auslesen, einschließlich OS/Hypervisor-Kernel-Speicher. Im Gegensatz zu Meltdown verwendet Spectre die CPU-Branch-Prediction als Mechanismus zum Durchsuchen von temporären Code-Pfaden, um auf geschützten Speicher zuzugreifen. Der Angreifer kann zwar nicht direkt auf den Speicher zugreifen, ihn aber später per Cache-Timing-Analyse ableiten.

Branch-Prediction ist eine Methode zur CPU-Leistungsoptimierung, die es der CPU ermöglicht, den Zielwert einer Steuerungsflussoperation vorherzusagen, damit die Ausführungs-Pipeline nicht auf die Auflösung des Zielspeicherortes warten muss.

Bild 3: Manipulation des Sprungadressenzwischenspeichers durch Spectre. Lynx

Spectre stellt eine größere Assurance-Herausforderung dar als Meltdown und greift auf nicht privilegierten Speicher im CPU-Cache des Angreifers zu, ohne den direkten Verweis auf den Speicher des Opfers im Angreifercode zu nutzen. Spectre visiert Codemuster an, die bedingungsbezogene Pfade enthalten, die zu einem nicht autorisierten Speicherzugriff führen können. Es existieren dabei zwei unterschiedliche Methoden, die Branch-Pediction auszunutzen: Das Umgehen von Längenchecks und das Manipulieren des Sprungadressenzwischenspeichers (Bild 3).

Umgehen von Längenchecks

Bei der Längencheckumgehung handelt es sich um einen Angriff auf den Code des Opfers, bei dem mit zu großen Indizes auf Bereiche jenseits der Indexgrenze von Speicher-Arrays ein Zugriff erfolgt. Durch Trainieren des Branch-Predictors mit aufeinanderfolgenden Aufrufen der Funktion mittels „legaler“ (nicht-temporärer) Indexwerte bringt der Angreifer die CPU dazu, spekulativ anzunehmen, dass es beim folgenden Funktionsaufruf sicher ist, zum Array-Lookup-Code zu springen.

Ist der Branch-Predictor erst einmal in dieser Weise trainiert, kann der Angreifer diesen Funktionsaufruf mit jedem Indexwert starten, wissend, dass die CPU den Speicherinhalt nach den angreifergesteuerten Indices vorübergehend/transient in den Cache laden wird.

Sprungadressenzwischenspeicher manipulieren

Bei der Manipulation des Sprungadressenzwischenspeichers (Branch Target Buffer) wird mittels Branch-Instruktionen der Sprung zu variablen Zieladressen verursacht, die Code enthalten (sogenannte Gadgets), der auf privaten Speicher innerhalb des Adressraums des Ziels zugreift. Durch „Trainieren“ des Branch-Predictor der CPU kann der Angreifer einen Sprung zu Gadgets verursachen, die normalerweise nicht zugänglich wären.

Bild 4: Mögliche Angriffsvektoren auf eine herkömmliche, zentralisierte Ressourcen- und dienstorientierte Architektur. Lynx

Angesichts von Spectre müssen sich Systementwickler fragen, ob die Vertraulichkeit sensibler Daten durch ihr System noch gewährleistet ist. Wie weiß ein Systementwickler einer serviceorientierten, daher zentralisiert angelegten Architektur, ob Standardprozesse wie Benutzer-Login und Datenverschlüsselung nicht unterschwellig Geheimes wie Authentifizierungs- und Entschlüsselungspasswörter verraten? Bild 4 zeigt mögliche Angriffsvektoren auf eine herkömmliche zentralisierte Ressourcen- und dienstorientierte Architektur.

Und wie lässt sich ein System vor Spectre schützen? Anworten darauf finden Sie auf der nächsten Seite.

Schutz vor Spectre

Side-Channel-Attacken generell messen die Code-Aktivität des Opfers, das auf ein gemeinsames Rechnersystem zugreift. In herkömmlichen zentralisierten ressourcen- und dienstorientierten Designs hängt jede Anwendung von einem einzigen Kernel ab, um die Ausführung von Threads zu terminieren, Ressourcen zu managen und Daten bereitzustellen (siehe Bild 4). Hier gestaltet sich die Aufgabe, einen Angreifer daran zu hindern, auf durch den Kernel gewahrte Systeminterna zuzugreifen, als fast unlösbar. Schlimmer noch: Verfügen Anwendungen von Grund auf über die Option, administrative Zugriffsrechte auf den OS/Hypervisor auf dynamische Weise zu gewinnen, können Spectre-ähnliche Angriffe dramatisch zunehmen.

Least Privilege-Prinzip

Der Separation-Kernel Lynx-Secure hebt die Least-Privilege-Architektur auf ein stringentes Niveau an. Er eliminiert die zentralen Ressourcenmanager, Datendienste und die administrativen Benutzerkontrollrechte. Das Kerneldesign erlaubt es immer noch Anwendungen in Gastumgebungen unmodifiziert auszuführen. Der Unterschied zu anderen Lösungen ist, dass kritischer Code, der für die Initialisierung der Hardware und die Handhabung von Hardware-Ausnahmen verantwortlich ist, von dem Code separiert wurde, der die Anwendungsdienste (Speichermanager, Gerätetreiber, Datenschutz) unterstützt. Zusätzlich ist jede Applikationsunterstützungsschicht autonom segmentiert. Durch das Abkoppeln der Applikationsunterstützungsschichten von den lebenswichtigen Hardwaresteuerungsfunktonen und indem sichergestellt wird, dass jede Applikationsumgebung eigenständig unterstützt wird, verfügen die Anwendungen nur über einen sehr eingeschränkten vorübergehenden Zugriff auf geheime Zustände der CPU.

Verteilte Systemarchitektur

Softwaredesigns mit zentralen Dienstfunktionen wie Datenschutz sind unverzichtbar. Mit einem Least-Privilege-Prinzip als Fundament lässt sich ein kritischer Sicherheitsservice vom Kernel abkoppeln, sodass er nur den Anwendungen ausgesetzt ist, die er kennen muss. Dennoch muss sich dieser Dienst stabil und widerstandfähig gegenüber Seitenkanalangriffe ausführen lassen.

Lynx-Secure bietet eine feinkörnige Systemkonfigurationskontrolle, die die Möglichkeit ausschließen kann, dass Gäste/Anwendungen auf sensible Informationen zugreifen können – einschließlich einer expliziten Zuordnung von Gästen für CPU-Kerne, einer Kontrolle der Speicheradressierung, und durch Schreiben/Lesen durchführbare Zuordnung aller CPU-adressierbaren Ressourcen. Wenn gewährleistet wird, dass etwas Geheimes mittels komplett von einem Benutzerprozess unabhängigen CPU-Ressourcen ausgeführt wird, können Schadprogramme auch nichts Geheimes finden.

Bei Systemen, die nicht über ausreichende Ressourcen verfügen, die kritischen Funktionalitäten zugeordnet werden könnten, muss dem Softwaredesign eine größere Aufmerksamkeit gewidmet werden. Spectre floriert in Softwaredesigns mit einer engen Kopplung zwischen Schadanwendung und dem Code des Opfers. Herkömmliche OS/Hypervisor-System-APIs sind bevorzugte Ziele für Spectre-Angriffe, da der Angreifer sich in Schnittstellen des Opfers einlinken und den Zielcode des Opfers direkt aufrufen kann. Alternativ dazu koppelt die verteilte Systemarchitektur von Lynx-Secure Anwendungen und Dienste voneinander ab. Anwendungen können Dienste nicht einfach direkt aufrufen, sondern müssen eine Service-Anfrage stellen und für diese Dienste über Message-APIs Daten hinterlegen. Dies erlaubt einen höheren Trennungsgrad zwischen Angriffs- und Opfer-Code. Hierdurch wird der Angreifer „blind“ gegenüber der tatsächlichen Dienste-Schnittstelle des Opfers und der Dienste-Code kann auf Nicht-Schnittstellen-Rechenressourcen ausgeführt werden.