Spectre NG: Weitere acht Sicherheitslücken in Intel-Prozessoren

UPDATE 22.5.2018: Die ersten beiden Sicherheitslücken sind nun bekannt. Es gibt auch das erste Hersteller Advisory. Für beide Lücken hat Intel Microcode Updates angekündigt, damit Anwendungen Memory Disambiguation (MD) abschalten können. Nur in diesem Fall greift der durch die Updates bereitgestellte Schutz. Ich habe den Blog-Artikel um CVEs und Hersteller Advisories ergänzt.

UPDATE 9.5.2018: Bis zum 7.5.2018 gaben die Entdecker keine Details zur ersten Spectre NG-Sicherheitslücke bekannt, da Intel offenbar Probleme habe, rechtzeitig Patches bereit zu stellen. Neuer Termin für eine koordinierte Veröffentlichung könnte der 21. Mai sein. Es könnte aber auch noch länger dauern. Für Patches zur kritischsten Sicherheitslücke ist der 14. August im Gespräch – eine ziemlich lange Zeit, um eine Lücke zu schließen, die es sehr einfach mache, Barrieren zwischen virtuellen Maschinen oder virtuellen Maschinen und Hypervisor zu umgehen.

Zwischenzeitlich war es relativ ruhig geworden um Meltdown und Spectre. Für die meisten im Enterprise-Umfeld eingesetzten Systeme gibt es mittlerweile Patches, die oftmals aus einer Mischung von Microcode-Updates (via Betriebssystem und/oder Firmware), Vorkehrungen im jeweiligen Betriebssystem-Kern sowie Anwendungen mit besonders großer Angriffsfläche, wie Webbrowser, bestehen. War es das?

Schon zu Meltdown und Spectre warnten Experten, dass es noch weitere Sicherheitslücken geben könnte. Genau dies hat sich laut einem Artikel im c´t Magazin bewahrheitet.

Was ist bislang bekannt?

Laut c´t Magazin haben Forscher aus verschiedenen Projekten acht neue Sicherheitslücken entdeckt, die diese aktuell noch geheim halten. Sie basieren allesamt auf dem Design-Problem, das mein Kollege Patrick Dreker ausführlich in seiner Analyse und Erklärung zu den Meltdown und Spectre Sicherheitsproblemen beschrieben hat. Die Autoren des c´t-Artikels nennen diese Lücken vorläufig Spectre NG, auch wenn die Lücken später wahrscheinlich jeweils einzelne Namen bekommen.

Die Sicherheitslücken haben bereits CVE-Nummern (Common Vulnerability Enumerator) bekommen, die der Artikel derzeit nicht nennt. Der Autor des Artikels Jürgen Fischer schreibt dazu in einem Kommentar vom 3.5.2018, dass diese derzeit nutzlos, jedoch deren Veröffentlichung eventuell ein Risiko für die Hinweisgeber seien. Wahrscheinlich handelt es sich um CVEs im Zustand RESERVED, für die noch keine weiteren Details vorliegen. Wir liefern die konkreten CVEs nach, sobald diese bekannt sind. Die ersten CVEs sind nun bekannt. Es gibt auch bereits das erste Hersteller Advisory.

Auch sonst mangelt es dem Artikel an konkreten Details. Eine von Google Project Zero gefundene Lücke veröffentlichen die Sicherheitsforscher wahrscheinlich am 7. Mai nach Ablauf der 90-Tage-Frist, die die Google-Hacker bislang in der Regel relativ strikt einhalten würden. Bei einer weiteren Lücke rechne Intel mit einer baldigen Veröffentlichung.

Intel stufe vier der Sicherheitslücken mit einem hohen Risiko ein. Die Redakteure sehen die Risiken und Angriffsszenarien als ähnlich an wie bei Spectre, für das dem Autor dieses Blog-Artikels derzeit keine auf produktiven Systemen laufende und dabei erfolgreiche Angriffe bekannt sind. Eine Umsetzung von Angriffen gemäß Spectre V1 – Bounds Check Bypass, CVE-2017-5753 – und Spectre V2 – Branch Target Injection (BTI), CVE-2017-5715 – erfordere Einiges an Vorwissen.

In einer Lücke sehen die c´t-Redakteure jedoch eine erhebliche Gefahr für virtualisierte Umgebungen. Diese vereinfache Angriff über die Grenzen virtueller Maschinen so stark, dass den Redakteuren des Artikels ein Angriff praktikabel erscheint. So könne jemand aus einer virtuellen Maschine andere virtuelle Maschinen oder gar das Hypervisor-Wirt-System angreifen und dabei geheime Informationen wie Schlüssel-Dateien oder Passwörter auslesen. Sollten sich diese Aussagen als wahr herausstellen, so macht es Sinn, insbesondere in Cloud-Umgebungen für diese Lücke baldmöglichst einen Patch einzuspielen.

Was tun?

Nach dem gängigen, eher dürftigen Kenntnis-Stand bleibt nur abzuwarten und bereit zu sein, zeitnah Patches einzuspielen – insbesondere für die besonders kritische Lücke.

Andere Quellen wie Security Announce-Mailinglisten/-Webseiten gängiger Linux-Distributoren wie Debian, Ubuntu, RedHat oder SUSE oder die allgemeine oss-security-Mailingliste liefern derzeit (3.5.2018) noch keine Hinweise. Eine Diskussion zu Spectre NG auf der Linux Kernel Mailingliste ist dem Autor des Blog-Artikels bislang auch noch nicht aufgefallen. Laut dem Artikel würden bereits Intel und Microsoft an Patches arbeiten.

Wir informieren Sie natürlich, sobald uns weitere Informationen vorliegen. Das betrifft natürlich auch Patches für VMware-, NetApp-, Juniper-, Cisco- und andere von uns angebotenen Systeme.

CVEs

• Spectre V4, Speculative Store Bypass, CVE-2018-3639: Von Google Project Zero und Microsoft gemeldet. Die von Browserhersteller umgesetzten Schutzmaßnahmen zu Spectre V1 und V2 wirken auch gegen Spectre V4. Blog-Einrag im Intel-Newsroom, Youtube-Video von Red Hat.
• Spectre V3a, Rogue System Register Read, CVE-2018-3640: Von ARM gemeldet. Unter Linux wohl schwer ausnutzbar.

Hersteller Advisories

• Red Hat (Bugreport)

Unter Linux?

Da Linux mein Steckenpferd ist, folgen noch zwei kurze Tipps, um den derzeitigen Patch-Stand von Linux-Systemen zu ermitteln. Beide berücksichtigen nur die derzeit bekannten Lücken und Angriffsszenarien. Die neuen Lücken, die sicherlich auch Linux-Systeme betreffen, unterstützen sie derzeit noch nicht.

Zum einen liefern aktuelle Kernel und solche, für die Entwickler die entsprechenden Patches zurückportieren, Informationen zu den Sicherheitslücken und der verwendeten Abhilfe an. Diese zeigt der Befehl grep . /sys/devices/system/cpu/vulnerabilities/* an. Beispiel für das Laptop des Autors dieses Blog-Artikels, das derzeit Kernel 4.16.3 und das via Debian ausgelieferte Intel Microcode-Paket vom 12.3.2018 verwendet:

Eine wesentlich ausführlichere Ausgabe liefert der Spectre Meltdown Checker. Er zeigt, inwiefern der Prozessor nach derzeitigem Kenntnis-Stand für Meltdown (aka Variante 3), Spectre V1 (Variante 1) und Spectr V2 (Variante 2) anfällig ist, inwiefern der Prozessor-Microcode die neuen Instruktionen zur Abwehr der Angriffe enthält, und inwiefern der verwendete Kernel diese oder andere Maßnahmen nutzt, um die Lücken nach derzeitigen Kenntnisstand zu schließen. Dieses distributions-übergreifende Programm funktioniert auch für die BSD-Varianten FreeBSD, NetBSD und DragonFlyBSD.

Windows-Admins finden im Windows-Abschnitt der Aufstellung zu Patches zu Spectre V1/V2 und Meltdown von Hanno Böck Hinweise mit einem passenden Powershell-Skript zum Prüfen auf die Lücken. Auch zu Apple-Produkten sowie Android, FreeBSD, Browsern liefert die Aufstellung wertvolle Hinweise. Mein Kollege Patrick Dreker hat im Überblicks-Artikel Spectre/Meltdown – die Kurzfassung  die wichtigsten Links, auch für Cisco, VMware und NetApp zusammen gestellt.

Martin Steigerwald

Martin Steigerwald beschäftigt sich seit Mitte der 90er Jahre mit Linux. Er ist langjähriger Autor von Artikeln für verschiedene Computer-Magazine wie die LinuxUser (linuxuser.de) und das Linux-Magazin (linux-magazin.de). Seit Herbst 2004 ist er als Trainer für Linux-Themen bei Proact Deutschland in Nürnberg tätig.