Software-Design zum Schutz kritischer Systeme vor Meltdown und Spectre

Seite: 2/2

Anbieter zum Thema

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.

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.

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 widerstandfähig gegenüber Seitenkanalangriffe ausführen lassen. LynxSecure 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.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

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 LynxSecure 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.

Literaturverzeichnis

[1] Lynx Software Technologies, "Lynx Customers Are Immune To Meltdown," 22 January 2018. [Online].

[2] D. J. Rushby, "Design and Verification of Secure Systems," ACM Operating Systems Review Vol. 15 No. 5, pp. 12-21, December, 1981.

[3] RTCA/DO-178C, "Software Considerations in Airborne Systems and Equipment Certification," RTCA, Inc. [EUROCAE document number: 12C], 2011.

[4] Certification Authorities Software Team, "Position Paper CAST 32-A: Multicore processors," November 2016. [Online].

[5] AIR-120, Aviation Safety - Aircraft Certification Service, Aircraft Engineering Division, "20-170 - Integrated Modular Avionics Development. Verification, Integration and Approval using RTCA/DO-297 and Technical Standard Order C153," 28 October 2010. [Online].

[6] D. E. B. a. L. J. LaPadula, "Secure Computer Systems: Mathematical Foundations," MITRE Technical Report 2547, Volume I, March, 1973.

[7] D. J. Rushby, "A Trusted Computing Base for Embedded Systems," in Proceedings of the 7th Department of Defense/NBS Computer Security Conference, Gaithersburg, Maryland, United States, 1984.

[8] M. a. S. M. a. G. D. a. P. T. a. H. W. a. M. S. a. K. P. a. G. D. a. Y. Y. a. H. M. Lipp, "Meltdown," ArXiv e-prints, vol. 1801.01207, January 2018.

[9] D. G. D. G. W. H. M. H. M. L. S. M. T. P. M. S. Y. Y. Paul Kocher, "Spectre Attacks: Exploiting Speculative Execution," January 2018. [Online].

[10] Paul Turner, Google Senior Staff Engineer, Technical Infrastructure, "Retpoline: a software construct for preventing branch-target-injection," [Online].

[11] National Institute of Standards and Technology , "CVE-2017-5715 Detail," 18 January 2018. [Online].

[12] Wikipedia, "Wikipedia -- Principle of Least Privilege," 1 November 2017. [Online]

[13] Wikipedia, "Wikipedia -- Side Channel Attacks," 29 January 2018. [Online].

* Will Keegan ist CTO bei Lynx Software Technologies.

(ID:45228203)