Spectre & Meltdown
Bild: Meltdown & Spectre | by Natascha Eibl | License: CC0

Vor über einem Jahr mussten Prozessorhersteller wie AMD und ARM, aber vor allem Intel eingestehen, dass das Rennen um immer schnellere Prozessoren in den letzten 20 Jahren an den Abgrund geführt hatte. Wo stehen wir heute?

Pipeline immer gefüllt

Eine der fortgeschrittenen Techniken moderner CPUs, die Sprungvorhersage ist verwundbar und erlaubt, wenn auch nur mit viel Aufwand, das Auslesen von Daten aus dem virtuellen Speicher. Bei der auf Englisch branch prediction geheißenen Funktion geht es darum, möglichst immer alle Stufen der Pipeline eines Microprozessors sinnvoll auszulasten.

Verspekuliert

Die dabei angewendete spekulative Ausführung erlaubt zwar eine hohe Effizienz, ist bei den verschiedenen Varianten von Spectre aber das Einfallstor für mögliche Angriffe. Wird die Spekulation der CPU verworfen und das Ergebnis einer anderen Stufe der Pipeline gewählt, ergibt das minimale Änderungen etwa im Cache, die über eine Seitenkanalattacke ausgelesen und genutzt werden können, um Seiten im virtuellen Speicher zu lesen und zu kopieren.

Nur im Silizium zu beheben

Dass es bis heute keinen bekannten Fall eines Angriffs per Spectre gegeben hat, ist bei der Beurteilung der Schwere des Fehlers unmaßgeblich. Tatsache ist, die Fehler sind endgültig nur im Silizium zu beheben. Die ergriffenen Maßnahmen, sei es im Microcode oder in den Betriebssystemen, führte zu teils hohen Leistungseinbußen. somit werden diese Maßnahmen von vielen Administratoren gar nicht angewendet.

Spekulative Ausführung muss weg

Ein Team von Google-Sicherheitsexperten hat jetzt ein Papier unter dem Titel Spectre is here to stay vorgelegt, in dem sie erklären, Spectre werde uns so lange begleiten, bis einschneidende Änderungen am CPU-Design umgesetzt werden. Die Kernaussagen sind, dass auch künftig weitere Spectre-Varianten auftauchen werden und das sich das nicht ändert, bis die spekulative Ausführung aus den CPU-Architekturen entfernt wird.

Das Papier kommt zu dem Schluss, dass das aktuelle CPU- und Architekturdesign mit drei ungelösten Problemen konfrontiert ist: weitere Schwachstellen im Seitenkanal zu finden, sie zu verstehen und sie auf effiziente und umfassende Weise zu mildern. Das Papier endet mit einer Erklärung, in der die Sicherheit für die Leistung von CPUs beleuchtet und festgestellt wird, dass Seitenkanal-Angriffsvektoren so lange bestehen bleiben, wie die CPU-Architektur unverändert bleibt.

Schritt zurück?

Die offensichtlichste Lösung ist die Beseitigung der spekulativen Ausführung, wie es im Papier heißt. Spekulative Ausführung ist jedoch eine wichtige Technik zur Leistungsoptimierung, die von den meisten x86-Prozessoren verwendet wird, weshalb CPU-Hersteller Schwachstellen lieber auf andere Weise minimieren würden, anstatt diesen radikalen Schritt zurück zu gehen, der mit schwer bis gar nicht zu umgehenden Leistungsminderungen einhergehen würde.

Meltdown & Spectre 2019

Verwandte Themen

ZombieLoad: neue Lücken bei Intel CPUs
views 453
Logo: Natascha Eibl Lizenz: CCOIntel hat weitere Sicherheitslücken in fast allen Core-i- und Xeon-CPUs seit 2011 mit Ausnahme einiger aktueller M...
Meltdown und Spectre: weiter verbreitet als gedach...
views 613
Bild: Meltdown & Spectre | by Natascha Eibl | License: CC0Forscher der Technischen Universität Kaiserslautern (TUK) gaben in einer Pressemitteil...
Intel bereitet diskrete Grafikkarten vor
views 622
Bild: Graphikarte mit Intel i740 | Quelle: Wikimedia | Lizenz: GFDLVor einigen Tagen wurde bekannt, dass Intel für seinen Linux-Grafiktreiber i91...
PortSmash: Erneut Sicherheitslücke bei Intel
views 809
Bild: Hacker | Quelle: The Presier Project | Lizenz: CC BY 2.0 Forscher an Universitäten in Finnland und Kuba haben unter der Leitung vo...
Intel Microcode für Debian Stable aktualisiert
views 484
Screenshot: ft Für Debian GNU/Linux 9 »Stretch« steht ein aktualisierter Intel Microcode zum Schutz vor Angriffen durch die Sicherheitsl...

Beitrag kommentieren

Alle Kommentare
  • Klaus Meier

    17.02.2019, 20:34 Uhr

    Linus hat ja seinen Kommentar dazu abgegeben. Er sagte, es ist nicht sein Aufgabe, Fehler von Intel auszubügeln. Ok, ich glaube, er hat es noch etwas heftiger formuliert.

    Aber zum einen muss man erst mal das Bedrohungsszenario analysieren. Davon betroffen sind VMs, die auf einer CPU (einem Kern) laufen. Da kann man mit viel Aufwand langsam auf Daten zugreifen. BSD hat ja deshalb Hyperthreading rausgeworfen. Damit es nicht mehr passieren kann, dass 2 VMs auf einem Kern laufen. Rechner, auf denen ein OS läuft, sind davon genau NULL betroffen. Das wird ja auch von folgender Aussage bestätigt: “Dass es bis heute keinen bekannten Fall eines Angriffs per Spectre gegeben hat, ist bei der Beurteilung der Schwere des Fehlers unmaßgeblich.”. Doch, genau das ist maßgeblich. Meine Kiste wird 30% langsamer, weil im Kernel Fixes eingebaut werden, für ein Szenario, was auf mich nicht sowieso nicht zutrifft und welches noch nie ausgenutzt wurde?

    Oh, es gibt einen ganz bösen Bug, der ist der schlimmste von allen. Wurde aber noch nie ausgenutzt. Aber weil er der schlimmste von allen ist, ist er der schlimmste von allen. Beweis per Aussage.

    Natürlich finde ich es schlimm, dass sich Intel genau NULL mit dieser Problematik beschäftigt. AMD betrifft es ja noch weniger. Aber das Problem wird sowas von aufgebauscht. Betroffen sind nur Rechenzentren, wo VMs laufen. Und da kann man das Problem zu 99% beseitigen, in dem man Hyperthreading abschaltet.

    Richtig, das Problem kann man nur in Silizium fixen. Aber welches Problem? Steht doch im Artikel, es hat bis heut nicht ein Problem gegeben.

  • tuxnix

    18.02.2019, 11:55 Uhr

    Ganze Produktlinien zu unterbrechen und danach dem Kunden für mehr Geld weniger Leistung zu verkaufen ist ein schwieriges Unterfangen und wird sich nur in Teilbereichen realisieren lassen. Wahrscheinlich bleibt es bei Meltdown & Spectre bis sich RISC‑V etabliert hat.

  • chris_blues

    18.02.2019, 13:33 Uhr

    @Klaus Meier
    War mir nicht klar, daß es nur VMs betrifft. Nach überfliegen des Papers, sieht es eher nicht danach aus. Hast du da Quellen?

    Jruß

    • Ferdinand Thommes

      18.02.2019, 13:54 Uhr

      VMs sind am schlimmsten betroffen. Da soll es Einbussen bis zu 50 Prozent geben.

  • chris_blues

    18.02.2019, 14:16 Uhr

    Du meinst Leistungsabfall? Ich meinte eher überhaupt die Möglichkeit Daten abzugreifen. Laut Klaus Meier scheint das ja nur in VMs möglich zu sein. So wie ich es verstehe, ist es auch außerhalb von VMs möglich… Daher meine Frage.

    • Ferdinand Thommes

      18.02.2019, 14:33 Uhr

      Ja, ich meinte Leistungsabfall. Meltdown und Spectre sind ansonsten theoretisch für PCs, bei mobilen Geräten und in der Cloud gefährlich. Tatsache ist allerdings auch, dass niemand den riesigen notwendigen Aufwand betreiben wird, um über eine Seitenkanalattacke in deinen PC einzudringen. Da dürfte es einfachere Einfallstore geben.

  • chris_blues

    18.02.2019, 14:51 Uhr

    Ja, dem stimme ich zu! Zumal, wenn man in der Lage wäre, so eine Attacke auf meinem System zu fahren, man ja sowieso schon Zugriff aufs System hätte. Die Rechteverwaltung auszutricksen ist sicherlich einfacher, als spekulative Daten abzugreifen und dann versuchen da irgendwas sinnvolles herauszuquetschen.

    Mich hat nur Klaus Meier’s Beitrag irritiert.
    […] Meine Kiste wird 30% langsamer, weil im Kernel Fixes eingebaut werden, für ein Szenario, was auf mich nicht sowieso nicht zutrifft […]
    So wie die meisten Sicherheitsproblem-Szenarios sind die ja eher hypothetisch, was aber nicht heißt, daß sie nicht real wären. Würde jemand sich die Mühe machen, eines der zahllosen Sicherheitslöcher auszunutzen, dann würde zumindest ich die Leistungseinbußen gerne in Kauf nehmen, um nicht alle 3 Tage ein neues Betriebssystem aufsetzen zu müssen, weil irgendjemand meint, mein System angreifen zu müssen… Oder ständig neue GPG Schlüssel generieren müssen, an meine Kontakte verteilen etc, oder SSH-Schlüssel oder oder…
    Ebenso hypothetisches Szenario, aber eben mal nur einen einzigen Schritt weiter gedacht.

  • Uwe

    18.02.2019, 15:41 Uhr

    Im Silizium.. Das sehe ich auch so. Wie soll denn Software einen “verdrahteten” Fehler beseitigen? Das Problem liegt im CPU-Design!

  • tuxnix

    18.02.2019, 18:12 Uhr

    Hier hab ich eine Anleitung gefunden wie man den Schutz vor Meltdown und Spectre wieder los wird.
    Gilt leider nur für Red Hat. https://access.redhat.com/articles/3311301 Vielleicht bieten andere Distries bald ähnliches an.

  • Klaus Meier

    18.02.2019, 18:55 Uhr

    Da wird Panik ohne Ende hochgekocht. Wer betroffen ist, der soll sich melden. Ist bislang noch keiner. “Dass es bis heute keinen bekannten Fall eines Angriffs per Spectre gegeben hat, ist bei der Beurteilung der Schwere des Fehlers unmaßgeblich.” Dieser Satz kotzt mich richtig an. Also ein Bug, der noch nie ausgenutzt wurde, der ist richtig schwer. Weil er noch nie ausgenutzt wurde. Aber schwer ist. Beweis durch Behauptung.

    ich werde mich jetzt ran setzen, wie ich meine Kiste von diesem ganzen Scheiß befreien kann, betroffen bin bin genau NULL aber ich habe 30% weniger Leistung.

    • Ferdinand Thommes

      18.02.2019, 19:21 Uhr

      Ich finde, der von Dir monierte Satz hat seine Berechtigung, denn: Keiner weiß, ob nicht in diesem Moment ein angriff stattfindet. Die Beurteilung der Schwere des Fehlers führt direkt ins Innerste der CPU, ist von unter andserem von Intel verursacht und wird, wenn überhaupt, auf unsere Kosten repariert. Die Schwere des Fehlers, ungeachtet der Ausnutzung verhindert, dass ich eine CPU kaufen kann, die frei von Sicherheitslücken ist. Ich finde, da gibt es nichts hochzukochen, das ist schon kochend heiß.

  • Nick

    19.02.2019, 07:40 Uhr

    @Klaus Meier
    Diese Kernel-Parameter schalten alle Sicherheitsmechanismen bezüglich Spectre und Meltdown ab.

    Folgendes einfach der Kernelzeile in GRUB anfügen:
    pti=off
    l1tf=off
    spectre_v2=off
    nospec_store_bypass_disable no_stf_barrier

    Alternativ wenn man sich des Risikos wirklich bewusst ist, kann das auch dauerhaft gesetzt werden.