Meltdown & Spectre: Microsofts Compiler-Fix weitgehend wirkungslos
Paul Kocher, einer der Entdecker der CPU-Sicherheitslücke Spectre, hat sich angesehen, wie effektiv Microsofts C/C++-Compiler den erzeugten Code vor Angriffen schützt. Sein Urteil fällt vernichtend aus.
(Bild: Alysson alyssonrock, gemeinfrei (Creative Commons CC0))
- Hajo Schulz
Kurz nach der Entdeckung der CPU-Sicherheitslücke, die die Angriffsszenarien Meltdown und Spectre ermöglicht, hatte Microsoft seinen C/C++-Compiler um eine Option erweitert, die den erzeugten Code vor Angriffen vom Typ Spectre 1 schützen soll. Was genau dieser Schalter bewirkt, hat sich jetzt Paul Kocher angesehen, einer der Autoren des ursprünglichen Spectre-Dokuments.
Sein Urteil: Mit der Option /Qspectre entdeckt der Compiler durchaus Code, der genau der Beschreibung entspricht, wie sie Kocher und seine Kollegen in ihrem Paper verwendet haben, und fügt CPU-Instruktionen ein, die den Code vor entsprechenden Angriffen schützen. Schon kleine Änderungen am Code hebeln aber die Erkennung aus, was dazu führt, dass Angreifer ihn nach wie vor missbrauchen könnten.
Spectre-1-Angriffe nutzen die Tatsache aus, dass moderne Prozessoren bei bedingten Sprungbefehlen den als wahrscheinlich eingeschätzten Programmpfad schon einmal auf Verdacht ausführen, bevor überhaupt sicher ist, ob die Bedingung erfüllt sein wird. Stellt sich dann heraus, dass die Annahme falsch war, werden die Änderungen etwa an Registerinhalten zurückgenommen, aber über Seiteneffekte – beispielsweise den Inhalt von Cache-Speicherzellen – können Angreifer trotzdem Rückschlüsse auf die unberechtigterweise gelesenen Daten ziehen. Microsofts Compiler-Fix fügt nun an als gefährlich erkannten Stellen LFENCE-Befehle in den erzeugten Code ein. Diese verbieten dem Prozessor, die folgenden Instruktionen spekulativ auszuführen.
Performance-Einbußen
Ein hundertprozentiger Schutz vor solchen Angriffen wäre möglich, indem der Compiler vor jedem bedingten Sprung ein LFENCE-Kommando einbauen würde, schreibt Kocher in seiner Betrachtung. Das führe aber zu nicht hinnehmbaren Performance-Einbußen: Eine von Hand auf diese Weise gesicherte Hash-Routine sei in seinen Experimenten um fast 60 Prozent langsamer gelaufen. Andererseits genüge schon eine einzige angreifbare Stelle im Code, um ein Programm insgesamt verwundbar zu machen. So sei jeder Ansatz, der von einem Compiler verlangt, zuverlässig kritische Code-Passagen zu identifizieren, zum Scheitern verurteilt. Jede Anstrengung in dieser Richtung müsse eine Abwägung zwischen Performance und Sicherheit treffen: Wer vollkommenen Schutz will, riskiert viele unnötige LFENCE-Schranken und damit einen hohen Leistungsverlust; wer Wert legt auf Performance, muss mit unentdeckten Schlupflöchern leben.
Kocher habe dieses Dilemma auch mit Entwicklern aus Microsofts Compiler-Team diskutiert. Diese seien sehr an Feedback aus der Anwendergemeinschaft interessiert: Wie viel Performance wären Programmierer für zusätzliche Sicherheit zu opfern bereit? Das Microsoft-Team freue sich auf Antworten per E-Mail oder Online-Formular. (hos)
