Schutz von Rechnern in der Produktion Software-Design zum Schutz vor Meltdown und Spectre

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

FTAPI Software GmbH

Lynx Software Technologies Inc.

Viele kritische Systeme sind anfällig für Meltdown und Spectre, müssen es aber nicht zwangsläufig sein. Die hier beschriebenen Tools und Entwurfsmethoden befähigen Systementwickler dazu, in Hinblick auf diese (und andere) Software- und Hardware-Schwachstellen ein hochgradiges Maß an Leistung und Sicherheit aufrechtzuerhalten.

Meltdown und Spectre geben Aufschluss darüber, wie sich widerstandsfähigere Systeme aufbauen lassen. Weniger ausführlich in der Presse behandelt als die Schwachstellen selbst, die Patch-Probleme oder die „Timelines bis zur Entdeckung”, war jedoch, dass einige Systeme tatsächlich vorbereitet waren und verschont blieben— ohne gepatcht, rekompiliert oder neu designet werden zu müssen [1]. Ihr Unterscheidungsmerkmal? Eine Separation-Kernel-Technologie, die auf der Arbeit von John Rushby [2] basiert und Systementwicklern durch eine gesteigerte Hardwaresteuerung in noch stärkerem Maße dazu befähigt, kritische von nicht-kritischen Rechenumgebungen zu trennen.

Bildergalerie

Trennung ist ein fundamentales Konzept bei der funktionalen und der Datensicherheit und wird bei High-Assurance-Systemdesigns seit Jahrzehnten eingesetzt. In Bezug auf funktionale Sicherheit stützt sich die Partitionierung von Flugverkehrsystemen auf die Trennung von Komponenten, um deren Schutz zu gewährleisten [3] [4] [5].

Was die Security der Daten betrifft, so baut das US-amerikanische Verteidigungsministerium zur Sicherung von Informationen in höchstgefährdeten Umgebungen auf eine modulare Trennung des Systemdesigns und des kontrollierten Informationsflusses [6] [7].

Meltdown als Lackmustest

Innerhalb dieser kritischen Kontexte bedeuten Trennungsfehler geradezu zwangsläufig Safety- und Security-Sicherheitsmängel. Somit fungiert Meltdown praktischer Lackmustest, der aufzeigt, wo sichere Trennungen hinsichtlich Safety und Security erreicht wurden und wo nicht.

Zudem sei hier auch nochmal angemerkt, dass auch vor Meltdown und Spectre Angriffe auf CPUs nichts Unbekanntes waren. Zwei bekannte Beispiele hierfür sind etwa Side-Channel-Angriffe und die sogenannte Out-of-Order-Ausführung. Als Side-Channel-Angriff wird jede Art von Attacke bezeichnet, die auf Informationen basiert, die durch ein physikalisch implementiertes Computersystems generiert werden, im Gegensatz zu Schwächen innerhalb des implementierten Algorithmus selbst. [13].

Bei der Out-Of-Order-Ausführung handelt es sich um ein Optimierungsverfahren, das die maximale Nutzung aller Ausführungseinheiten eines CPU-Kerns so ausgiebig wie möglich erlaubt. Anstatt die Instruktionen genau in der Reihenfolge des Ablaufprogramms auszuführen, führt die CPU diese aus, sobald alle erforderlichen Ressourcen verfügbar sind. Während der Ausführungsbereich für den augenblicklichen Vorgang besetzt ist, können andere Ausführungen schon vorauseilen. [8] Auch vor solchen Schwachstellen ist also ein effizienter Schutz notwendig, der durch gutes Design umgesetzt werden.

Meltdown – eine Zusammenfassung

Meltdown [8] erlaubt nichtprivilegierten Angreifern, den gesamten physischen Speicher eines Betriebssystems (OS) oder Hypervisors durch das Ausnutzen von Out-Order Execution (OoOE) auszulesen, ein verbreitetes CPU-Performancefeature fast alles Kernel-Designs. OoOE stellt die Berechtigungsauflösung zwischen Benutzer- oder Kernel-Adress-Lookups zurück und profitiert somit vom Adresskonvertierungs-Caching, während Kernel Daten zu und vom Anwendungsspeicher überträgt.

Weil sowohl die virtuelle Benutzerprozess- als auch die Kernel-Adresskonvertierungen in den gleichen Lookup-Tabellen gespeichert werden, erlaubt es die durch OoOE zurückgestellte Berechtigungsauflösung Angreiferanwendungen, direkt auf unautorisierte virtuelle Kernel-Adressen in ihrem Programm zuzugreifen, um unautorisierten 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 fortgeschrittene subversive Methode (Cache-Timing-Analyse) [16], um den Zustand des Cache zu untersuchen und dabei die Werte des temporär referenzierten Kernel-Speichers abzuleiten.

Die Lösung für Meltdown

Eine einfache, sofwareseitig handhabbare Lösung für Meltdown sind Seitentabellenisolation und Least-Privilege-Speicherzugriff - im „Lynx Secure Separation Kernel“ bereits integrierte Methoden. Das so genannte Least-Leverage-Prinzip erfordert, dass in einem bestimmten Abstraction Layer einer Rechenumgebung jedes Modul (das kann je nach Gegenstand ein Prozess, ein Nutzer oder ein Programm sein) nur auf die Informationen und Ressourcen zugreifen darf, die für seine rechtmäßige Aufgabe notwendig sind.

In Lynx Secure werden alle Kernel-zu-physischen-Adressen in einer komplett anderen Seitentabelle anstatt in Anwendungs-/Gast-OS-Seitentabellen gespeichert. Alternativ zu herkömmlichen zentralisierten ressourcen- und dienstorientierten Designs sind, ist Lynx Secure sowohl aus Kernel-Konstruktions- als auch aus Benutzermodell-Perspektive tief in einem Least-Privilege-Design verwurzelt. Lynx Secure erzwingt einen dezentralisierten Designansatz, bei dem jede Gast-Computing-Umgebung unabhängig ist. Durch die Autonomie jeder Gastumgebung wird vermieden, dass der Kernel globale Dienste bereitstellen muss.

Spectre – eine Zusammenfassung

Spectre [9] greift auf unautorisierten Speicher mittels CPU-Branch-Prediction, einer Methode zur Leistungsoptimierung, bei der die CPU den Zielwert einer Steuerungsflussoperation „vorhersagt“, damit die Ausführungs-Pipeline nicht auf die Auflösung des Zielspeicherortes warten muss. Die zwei identifizierten Methoden, um die Branch-Prediction auszunutzen, sind: (1) Umgehen von Längenchecks und (2) Manipulieren des Sprungadressenzwischenspeichers (Branch Target Injection).

Bei der Längencheckumgehung zielt auf den Code des Opfers, bei dem mit zu großen Indizes auf Bereiche jenseits der Indexgrenze von Speicher-Arrays zugegriffen wird. Durch Trainieren des Branch-Predictors mit aufeinanderfolgenden Aufrufen der Funktion mittels „legaler“ (nicht-temporärer) Indexwerte bringt der Angreifer die CPU dazu, anzunehmen, dass es beim folgenden Funktionsaufruf sicher ist, zum Array-Lookup-Code zu springen. Dann startet der Angreifer diesen Funktionsaufruf mit einem Indexwert, und die CPU lädt den Speicherinhalt nach den angreifergesteuerten Indices vorübergehend/transient in den Cache.

Bildergalerie

Branch Target Injection zielt auf den Code des Opfers 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-Predictors der CPU kann der Angreifer einen Sprung zu normalerweise nicht zugänglichen Gadgets verursachen.

Wenig Transparenz - nur Milderung in Sicht

Man hat nur wenige Möglichkeiten, um die Mechanismen des Angriffs zu entdecken oder gar zu korrigieren, da der Angriffscode einfach normale Funktionen ausführt und Register festlegt, bevor ein Ziel aufgerufen wird. Patches können Spectre abmildern — am effektivsten erwies sich die Modifikation des Compilers für einen alternativen Maschinendatencode in Form eines bedingten Applikationscodes [10] [11] Dies erfordert jedoch eine Rekompilierung aller bestehender Software und untersagt dennoch nicht die Anwendung ausnutzbarere CPU-Befehle.

Wie weiß man in 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 3 zeigt mögliche Angriffsvektoren einer Nutzeranwendung auf solche Architekturen.

Eindämmung von Spectre

Spectre misst die Code-Aktivität des Opfers, der auf ein gemeinsames Rechnersystem zugreift. In herkömmlichen Architekturen — in denen jede Anwendung von einem einzigen Kernel abhängt, um die Ausführung von Threads zu terminieren, Ressourcen zu managen und Daten bereitzustellen — Ist es fast unmöglich, einen Angreifer daran zu hindern, auf durch den Kernel gewahrte Systeminterna zuzugreifen. Noch schlimmer: wenn Anwendungen auf dynamische Weise administrative Zugriffsrechte auf den OS/Hypervisor gewinnen können, nimmt die Angriffsbedrohung dramatisch zu.

Viele Betriebssysteme und Hypervisoren sollen angeblich schon nach gemäß Least Privilege arbeiten, wenn sie ein zwingend vorgeschriebenes Zugangskontrollsystem vorweisen können oder die Treiber außerhalb des Kernel-Adressraums platzieren. Beim Separation Kernel LynxSecure geht das Least-Privilege-Prinzip jedoch noch weiter. Er eliminiert die zentralen Ressourcenmanager, Datendienste und die administrativen Benutzerkontrollrechte.

Obwohl Anwendungen immer noch in Gastumgebungen unmodifiziert ausgeführt werden dürfen, ist kritischer Code, der für die Initialisierung der Hardware und die Handhabung von Hardware-Ausnahmen (hardware exceptions) verantwortlich ist, von dem Code separiert, der die Anwendungsdienste unterstützt. Überdies ist jede Applikationsunterstützungsschicht autonom segmentiert. Das Design koppelt Applikationsunterstützungsschichten von den lebenswichtigen Hardwaresteuerungsfunktonen ab und stellt sicher, dass jede Applikationsumgebung eigenständig unterstützt wird. So haben die Anwendungen ¬nur streng eingeschränkten vorübergehenden Zugriff auf unbeabsichtigte CPU-Zustände.

Die Trennung von Kernel und Security

Softwaredesigns mit zentralen Dienstfunktionen wie Datenschutz sind unvermeidbar. Mit einem Least Privilege-Fundament lässt sich ein kritischer Sicherheitsservice vom Kernel abkoppeln, so dass er nur den Anwendungen ausgesetzt ist, die er kennen muss (need-to-know applications). Dennoch muss sich dieser Dienst stabil und widerstandsfähig gegenüber Seitenkanalangriffe ausführen lassen.

Lynx Secure bietet Systemkonfigurationskontrollen, die Anwendungen von der Möglichkeit ausschließen können, auf sensible Informationen zuzugreifen. Mittels einer feinkörnigen Ressourcenzuweisungssteuerung wird gewährleistet, dass Geheimes auf CPU-Ressourcen ausgeführt wird, die komplett unabhängig von einem Benutzerprozess und so vor Schadprogrammen geschützt sind.

Wenn keine ausreichenden Ressourcen verfügbar sind, die kritischen Funktionalitäten zugeordnet werden können, 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, da Angreifer sich in Schnittstellen des Opfers einlinken und den Zielcode des Opfers direkt aufrufen können. Alternativ dazu koppelt die verteilte Systemarchitektur von Lynx Secure Anwendungen und Dienste voneinander ab. Anwendungen müssen eine Service-Anfrage stellen und für diese Dienste über Message-APIs Daten hinterlegen. Dies führt zu einem höheren Trennungsgrad zwischen Angriffs- und Opfer-Code. Hierdurch wird der Angreifer ‚blind‘ gegenüber der Dienste-Schnittstelle des Opfers und der Dienste-Code kann auf Nicht-Schnittstellen-Rechenressourcen ausgeführt werden.

Bild 4 der Bildergallerie (siehe oben) zeigt eine alternative Systemarchitektur von LynxSecure, in der (1) die Ressourcen kritischer Dienste sind physikalisch von den Anwendungen separiert und die (2) Dienste mittels einer Message-API über eine System-Call-Schnittstelle an die Anwendungen angebunden sind.

Schlussfolgerung

Auch wenn es sich bei Meltdown und Spectre um sicherheitskritische Fehler in der Hardware handelt, müssen Systeme, die eine anfällige CPU verwenden, nicht zwangsläufig auch von den Security-Problemen betroffen sein. Mit Hilfe der richtigen Tools und Software-Designmethoden sind Entwickler in der Lage, diese Schwierigkeiten zu adressieren. Zudem sind sie somit auch besser auf die unvermeidlichen, derzeit noch unbekannten Sicherheitslücken und Angriffe der Zukunft vorbereitet.

Hinweis: Das Original des Artikels erschien zunächst in der Publikation „Elektronik Praxis“.

* Will Keegan ist CTO bei Lynx Software Technologies.

(ID:45246900)