Sind Spectre und Meltdown nur die Spitze des Eisbergs?

CPU-Schwachstellen im Überblick
Keine Kommentare

Die Anfang 2018 bekannt gewordenen CPU-Schwachstellen Spectre und Meltdown sind ein großes Problem. Und da immer mehr Spectre-Varianten auftauchen, sieht es fast so aus, als wäre das nur die Spitze des sprichwörtlichen Eisbergs. Aber auch wenn über sie momentan kaum gesprochen wird: Es gibt noch ein paar andere Schwachstellen in den CPUs.

Ich wage mal eine Prognose: Es werden noch viele weitere entdeckt werden. Die Sicherheitsforscher fangen gerade erst an, sich mit den CPUs zu beschäftigen. Sie werden also mit ziemlicher Sicherheit noch weitere Schwachstellen finden und wahrscheinlich auch neue, bisher unbekannte Angriffe entwickeln. Aber das ist Zukunftsmusik, also werfen wir mal einen Blick auf die aktuelle Lage. Dazu habe ich die Schwachstellen zu Paketen zusammengefasst.

Schwachstellenpaket 1: Spectre und Meltdown

Los ging‘s Anfang Januar 2018 mit der Veröffentlichung von Spectre und Meltdown. Darüber habe ich bereits im Windows Developer 4.2018 ausführlich berichtet [1], sodass hier eine Kurzfassung reichen sollte.

Januar 2018: Spectre und Meltdown werden veröffentlicht

Am 2. Januar gab es erste Gerüchte über eine kritische Hardwareschwachstelle, die zu immer mehr Spekulationen führten. Die Details zu den Schwachstellen und Angriffen, die eigentlich bis zum 9. Januar unter Verschluss bleiben sollten, wurden daraufhin früher veröffentlicht, was dazu führte, dass einige Patches noch nicht veröffentlicht waren, es sich also zumindest zum Teil um 0-Day-Schwachstellen handelte. Daran änderte sich auch einige Zeit erst mal nichts, denn es dauerte ziemlich lange, bis alle Schwachstellen überall behoben wurden. Jedenfalls soweit sie behoben werden sollten, denn einige CPUs werden von den Herstellern nicht mit Patches versorgt, und bei der Software sieht es genauso aus.

Die neuen Angriffe wurden Meltdown und Spectre genannt und waren damals über eine (Meltdown) bzw. zwei Schwachstellen (Spectre) möglich. Ursache dieser Schwachstellen ist die sogenannte Speculative Execution, die zur Optimierung der Performance eingesetzt wird. Dabei wird versucht, die nächsten auszuführenden Befehle vorauszusagen und ansonsten auf ungenutzten Prozessorkapazitäten auszuführen, bevor sie benötigt werden. Treffen die bei der Vorhersage gemachten Annahmen zu, wird die Ausführung des Codes weiter fortgesetzt. Stimmen sie nicht, wird die spekulative Ausführung verworfen und mit den korrekten Werten weitergerechnet. Dabei kann es vorkommen, dass beim Wiederherstellen des korrekten CPU-Status durch Seiteneffekte Informationen preisgegeben werden. Ein bösartiges Programm kann diese Technik nutzen, um sich Zugriff auf ihm eigentlich unzugängliche Speicherbereiche zu verschaffen.

Die im Januar 2018 veröffentlichten Schwachstellen sind:

  1. CVE-2017-5753 (Spectre V1), [2] – „Bounds Check Bypass“
  2. CVE-2017-5715 (Spectre V2), [2] – „Branch Target Injection“
  3. CVE-2017-5754 (Meltdown), [3], [4] – „Rogue Data Cache Load“

CVE-2017-5753 – „Bounds Check Bypass“ (Spectre V1)

Die Schwachstelle CVE-2017-5753 („Bounds Check Bypass“) betrifft Prozessoren, die die sogenannte Branch Prediction einsetzen. Dabei wird bei Verzweigungen wie If-then-else-Anweisungen die Anweisung im wahrscheinlichsten Zweig ausgeführt, bevor der tatsächliche Ausführungspfad bekannt ist. Der Prozessor versucht dabei, herauszufinden, ob ein Sprung ausgeführt wird oder nicht. War die Vorhersage richtig, beschleunigt sich die Ausführung, da die Ergebnisse der Anweisungen bereits vorliegen. Tritt die Vorhersage nicht ein, wird im tatsächlichen Ausführungspfad weitergearbeitet. Man hat zwar keine Zeit gewonnen, aber auch nichts verloren, da immer nur freie Kapazitäten der CPU für spekulative Ausführung genutzt werden.

Tritt die Vorhersage nicht ein, wird zwar im tatsächlichen Ausführungspfad weitergearbeitet, die bei der spekulativen Ausführung in den L1-Cache geladenen Daten werden dabei aber nicht explizit gelöscht. Sie bleiben erhalten, bis sie im Rahmen der normalen Ausführung überschrieben werden.

Schadcode kann, sofern zuvor bestimmte Codemuster zum Einsatz kamen, im Rahmen der regulären Ausführung über einen Timing-Angriff feststellen, welche Daten während der spekulativen Ausführung im Cache gespeichert wurden und darüber z. B. Kernelspeicher ausspähen.

Für diese Schwachstelle wurden zwei Proofs of Concept entwickelt, von denen einer Privilegiengrenzen überschreitet: Er läuft unter Linux mit normalen Benutzerrechten und kann beliebige Daten in einem 4-GB-Bereich des Kernelspeichers lesen.

Außerdem kann diese Schwachstelle auch über JavaScript-Code im Webbrowser ausgenutzt werden, sodass Angriffe über präparierte Webseiten möglich sind. Der Angreifer kann dann Informationen aus von anderen Servern geladenen Seiten ausspähen.

CVE-2017-5715 – „Branch Target Injection“ (Spectre V2)

Die Schwachstelle CVE-2017-5715 („Branch Target Injection“) betrifft ebenfalls Prozessoren, die die Branch Prediction einsetzen. Sie besteht im Wesentlichen darin, dass Code in unterschiedlichen Sicherheitskontexten die Branch Prediction des jeweils anderen beeinflussen kann. Schadcode kann darüber die spekulative Ausführung manipulieren und danach Daten im Cache ausspähen. Ein PoC, der mit Root-Rechten in einem KVM-Gastsystem läuft, kann Kernelspeicher des Hostsystems lesen.

Spectre: Schutz durch Hard- und Softwareupdates

Die Spectre-Schwachstellen betreffen im Grunde alle aktuellen Prozessoren aller Hersteller und können nur durch Änderungen am Prozessor beseitigt werden. Die bekannten Angriffe können auch nur über Software verhindert werden, die Schwachstellen bleiben dann aber erhalten und können durch neue, bisher unbekannte Angriffswege ausgenutzt werden.

Meltdown

Die Meltdown-Schwachstelle CVE-2017-5754 („Rogue Data Cache Load“) nutzt die Speculative Execution, um aus dem Userland heraus Kernelspeicher zu lesen. Gefährdet ist der gesamte Kernelspeicher! Mehrere PoCs, die mit normalen Benutzerrechten laufen, können Kernelspeicher lesen.

Meltdown: Softwareupdates beseitigen das Problem

Von Meltdown sind laut den Entdeckern potenziell alle Intel-Prozessoren betroffen, die eine „Out-of-Order Execution“ implementieren. Die Schwachstelle kann durch Patches für die Betriebssysteme korrigiert werden. Allerdings standen sie durch die vorgezogene Veröffentlichung der Schwachstellen anfangs nicht für alle Systeme zur Verfügung.

Im Rückblick sieht das gar nicht so schlimm aus

Das war so ungefähr der Stand Ende Januar 2018 – und eigentlich sieht das Ganze im Rückblick gar nicht mal so schlimm aus. Die Verwirrung lichtete sich so langsam, Updates waren veröffentlicht oder angekündigt, und auch wenn die Auswirkungen noch nicht richtig bekannt waren, wusste man zumindest, woran man war: Es gab zwei neue Angriffe und drei neue Schwachstellen, und wenn man die Schwachstellen behoben hatte, sollte von den Angriffen keine Gefahr mehr ausgehen.

Es war also nur eine Frage der Zeit, bis das Problem zumindest für die aktuellen Prozessoren, Systeme und Programme behoben sein würde, und die entscheidende Frage war eigentlich nur, ob die Cyberkriminellen vor oder nach der Korrektur der Schwachstellen zuschlugen (wenn sie es denn überhaupt taten).

Und so ging es weiter…

Am 1. Februar 2018 zählte AV-TEST 139 verschiedene Schadsoftwarevarianten, die die drei Schwachstellen ausnutzen. Alles basierte auf den veröffentlichten Proofs of Concept, und sehr wahrscheinlich dienten diese Schädlinge dem gleichen Zweck, denn Berichte über echte Angriffe blieben bisher aus.

Abb. 1: Von AV-TEST registrierte Schadsoftwarevarianten im Februar 2018 (Quelle: AV-TEST)

Abb. 1: Von AV-TEST registrierte Schadsoftwarevarianten im Februar 2018 (Quelle: AV-TEST)

Februar 2018, zum Ersten: Schutzfunktionen schützen nicht

Die Software Guards Extension (SGX) ist eine Schutzfunktion in aktuellen Intel-Prozessoren. Sie wurde mit Skylake (Core i-6000, Xeon-SP) eingeführt und richtet geschützte Enklaven im Hauptspeicher ein. Der darin ausgeführte Code soll sogar vor Zugriffen durch bereits auf dem System laufenden Schadcode sicher sein. Über die neuen Angriffe SgxPectre und SGXPectre ist jedoch ein Zugriff auf diese geschützten Enklaven möglich.

SgxPectre wurde von Forschern von der Ohio State University entwickelt. Sie manipulieren die Enklave von außen so, dass sie eigentlich nicht zugängliche Bereiche lesen können. Dabei wird der SGX-Schutz komplett unterlaufen und jede in einer Enklave laufende Software ist für den Angriff anfällig.

Der bisher verwendete Softwareschutz gegen Spectre-Angriffe (Retpoline) bietet keinen Schutz vor SgxPectre-Angriffen, und auch der Hardwareschutz durch Microcode-Updates mit Indirect Branch Control (IBC) lässt sich unterlaufen. Die Enklave kann nicht erkennen, ob Hardwarepatches installiert sind, sodass ein Angreifer mit Admin-Rechten die Patches unerkannt deaktivieren und danach ungestört einen SgxPectre-Angriff auf die Enklave durchführen kann.

SGXSpectre wurde von Forschern der Arbeitsgruppe „SeReCa: Hardware-Assisted Cloud Security“ des Imperial College London entwickelt. Sie verlagern den normalen Spectre-Angriff mit einigen leichten Anpassungen in eine Enklave, um dort Daten ausspähen zu können. Ob die software- oder hardwareseitigen Schutzfunktionen greifen oder nicht, ist nicht bekannt.

Februar 2018, zum Zweiten: Verbesserte Angriffe MeltdownPrime und SpectrePrime

Am 11. Februar wurden zwei neue Möglichkeiten für Angriffe veröffentlicht: MeltdownPrime und SpectrePrime. Ein Tool übernimmt dabei die mühselige Anpassung an das Zielsystem. Es simuliert eine bestimmte Chipbaureihe und passt den Angriffscode an deren spezifische Ausführungsmuster an. Neu ist dabei, dass durch die Ausnutzung von Eigenheiten beim Umgang mit Speicher in Mehrkern-CPUs zwei verschiedene CPU-Kerne gegeneinander ausgespielt werden können.

März und April 2018: Intel – mal hui, mal pfui

Am 15. März 2018 kündigte Intel neue Prozessoren an, deren Hardwaredesign so geändert werden sollte, dass sie von den Schwachstellen Spectre V2 und Meltdown nicht mehr betroffen sein würden. Angriffe über die Spectre-Variante 1 sollten aber weiterhin über Softwarelösungen abgewehrt werden.

Neue, sichere CPUs sind eine feine Sache, wenn man sowieso einen neuen Rechner oder zumindest eine neue CPU kaufen möchte. Die meisten Benutzer werden aber sicherlich ihre bisherigen Rechner noch einige Zeit unverändert behalten wollen und möchten natürlich auch sichere CPUs haben, benötigen also Updates für ihre betroffenen Prozessoren. Am 2. April 2018 veröffentlichte Intel eine „Microcode Revision Guidance“ mit Informationen darüber, für welche Prozessoren es Microcode-Updates zum Schutz vor den Spectre-Schwachstellen geben wird. Neun ältere CPU-Familien bleiben ungeschützt, darunter der häufig verwendete Core 2 Duo.

Mai und Juni 2018: Updates – ein ständiges Hin und Her

Im Laufe der Zeit wurden immer mehr Updates veröffentlicht, teilweise wieder zurückgezogen, dann erneut veröffentlicht, erweitert, überarbeitet …

Das soll hier nicht weiter interessieren, nur ein Beispiel möchte ich aufgreifen: Am 29. Mai veröffentliche Google Chrome 67, mit dem für weitere Benutzer die neue Schutzfunktion der Site Isolation ausgerollt wurde, die Spectre-Angriffe erschweren soll.

Dass die dringend nötig war, zeigte sich am 26. Juni, als zwei Forscher ihre Untersuchungen der Browserschutzmaßnahmen gegen Spectre-Angriffe veröffentlichten: Die ersten eingeführten Schutzmaßnahmen bestanden darin, das Timing so zu ändern, dass es für die Angriffe zu ungenau wird. Dieser Schutz ließ sich in fast allen Browsern unterlaufen, nur an Firefox scheiterten die Forscher. Dort wurde die Auflösung des internen Timers auf zwei Millisekunden reduziert, was den Angriff so weit ausbremst, dass er unpraktikabel wird. Die Forscher schlagen den Einsatz von Lösungen wie Site Isolation vor, warnen aber auch, dass deren korrekte Implementierung anspruchsvoll ist.

November und Dezember 2018: Linux: Spectre-V2-Patch erst raus, dann rein

Die Spectre-Patches haben teilweise drastische Auswirkungen auf die Performance [1].

Am 18. November erklärte Linus Torvalds, dass er mit der Performance der Schutzfunktion „Single Thread Indirect Branch Predictors“ (STIBP) zur Verhinderung von Angriffen über Spectre V2 überhaupt nicht zufrieden sei, weshalb der Patch aus dem Linux-Kernel flog. Warum sollte man alle Benutzer ausbremsen, wenn es genauso möglich ist, gezielt den bedrohten Code über Softwareanpassungen zu schützen?

Am 1. Dezember war Linus Torvalds dann mit der Performance der inzwischen verbesserten Implementierung zufrieden und gab ihr seinen Segen.

Schwachstellenpaket 2: Die AMD Flaws

Im März 2018 veröffentlichte CTS-Labs dreizehn kritische Schwachstellen in den aktuellen AMD-Prozessorfamilien Ryzen, Ryzen Pro und Epyc, genannt Masterkey, Ryzenfall, Fallout und Chimera. Diese Veröffentlichung ist inzwischen nur noch über archive.org verfügbar. Alle Schwachstellen wurden von AMD bestätigt und Updates angekündigt. Die Schwachstellen haben folgende CVE-IDs:

Die Masterkey-Angriffe funktionieren nur, wenn der Angreifer physischen Zugriff auf das System hat und den BIOS-Code im Flash-Chip überschreiben kann. Für die Ryzenfall- und Fallout-Angriffe muss der Angreifer Admin-Rechte haben. Die Folgen ähneln denen von Spectre und Meltdown: Zugriff auf eigentlich nicht zugängliche Daten sind im Fall der Hintertüren natürlich besonders einfach.

Schwachstellenpaket 3: Spectre-NG

Als „Spectre-NG“ werden acht Schwachstellen bezeichnet, für die Intel im Mai 2018 CVE-IDs reserviert hat. Da man nicht viel mehr wusste, als dass eben die CVE-IDs reserviert worden waren und dass es sich um Spectre-ähnliche Schwachstellen handelt, sprach die c’t in Ihrem Bericht über diese neuen Schwachstellen von „Spectre Next Generation“ oder „Spectre-NG“.

Eine der Schwachstellen soll insbesondere für Cloud-Umgebungen gefährlich sein. Ein Angreifer kann seinen Exploit-Code in einer virtuellen Maschine starten und von dort aus das Wirtssystem übernehmen, in der Cloud also den Server, auf dem seine VM läuft. Leider hat die c’t im Mai nicht die CVE-IDs verraten, sodass man jetzt nicht weiß, welche neu vorgestellten Intel-Schwachstellen zu den Spectre-NG-Schwachstellen gehören und welche nicht.

Ab Mai 2018: Die Spectre-NG-Schwachstellen werden veröffentlicht

Seit Mai wurden folgende Schwachstellen veröffentlicht, die vermutlich zu Spectre-NG gehören:

  • 21. Mai: CVE-2018-3639 (Spectre V4), [5], [6] – „Speculative Store Bypass“ (SSB): Ausspähen von Informationen über einen Seitenkanal-Angriff, auch über Browser ausnutzbar
  • 21. Mai: CVE-2018-3640 (Spectre V3a), [5], [6] – „Rogue System Register Read“ (RSRE): Ausspähen von Informationen über einen Seitenkanalangriff
  • 13. Juni: CVE-2018-3665, [7], [8] – „Spectre Lazy FP State Restore“: Ausspähen von Informationen über einen Seitenkanal-Angriff
  • 10. Juli: CVE-2018-3693 (Spectre 1.1), [9], 10], [11 – PDF und Archiv] – „Bounds Check Bypass Store“: Die Schwachstelle kann z. B. wie bei einem klassischen Pufferüberlauf ausgenutzt werden, um eine Sprungadresse zu überschreiben und dann eigenen Code ausführen zu lassen. Das passiert zwar spekulativ, aber mit erweiterten Rechten. Wenn die CPU erkennt, dass der Schreibzugriff eigentlich nicht erlaubt war, macht sie alles wieder rückgängig. Alles bis auf den Zustand des Caches, den sie nicht bereinigen kann. Der stellt wie bei den anderen Spectre-Schwachstellen einen Seitenkanal dar, über den Informationen ausgespäht werden können.
  • 10. Juli: ohne CVE ID (Spectre 1.2) [11 – PDF und Archiv]: Es ist spekulativem Speicher möglich, auf CPUs, die keinen Schreib-/Leseschutz erzwingen, Daten in Read-Only-Bereichen und Code Pointer zu überschreiben und dadurch z. B. aus einer Sandbox auszubrechen
  • 14. August: CVE-2018-3615 (Foreshadow), [12], [13] – „L1 Terminal Fault: SGX“: Diese Schwachstelle erlaubt Zugriffe auf die von SGX-Enklaven (siehe oben) im Level-1-Cache gespeicherten Daten und dadurch das Ausspähen aller Informationen aus deren besonders geschützten Speicherbereichen.
  • 14. August: CVE-2018-3620 (Foreshadow-NG (Next Generation)), [12], [13] – „L1 Terminal Fault: OS/SMM“: Variante von Foreshadow, bei der Informationen des Betriebssystems oder des System Management Mode (SMM) ausgespäht werden können
  • 14. August: CVE-2018-3646 (Foreshadow-NG), [12], [13] – „L1 Terminal Fault: VMM“: Variante von Foreshadow, bei der eine virtuelle Maschine Informationen andere virtueller Maschinen ausspähen kann; dies dürfte die „Spectre-NG-Cloud-Schwachstelle“ sein, die im Artikel zur Cloud-Sicherheit im Windows Developer 10.18 erwähnt wurde, damals aber noch nicht veröffentlicht war [14]. Wie erwartet erlaubt sie einer bösartigen oder kompromittierten VM den Zugriff auf die Daten anderer VMs.

Wie leider üblich, sind mal wieder sowohl Software- als auch Microcode-Patches nötig, aber zumindest im Fall von Foreshadow/Foreshadow-NG hat die koordinierte Veröffentlichung so gut funktioniert, dass die Patches zum Zeitpunkt der Veröffentlichung der Schwachstellen bereitstanden. So hat z. B. Linus Torvalds die nötigen Patches für den Linux-Kernel parallel zur Veröffentlichung der Schwachstellen freigegeben, und „rein zufällig“ wurden die Schwachstellen an Microsofts Patchday veröffentlicht, an dem auch die entsprechenden Patches veröffentlicht wurden.

Zumindest im Fall von Foreshadow/Foreshadow-NG hat die koordinierte Veröffentlichung so gut funktioniert, dass die Patches zum Zeitpunkt der Veröffentlichung der Schwachstellen bereitstanden.

Schwachstellenpaket 4: TLBleed

Am 22. Juni wurden auf The Register vorab Informationen über einen neuen Angriff veröffentlicht, der von Ben Gras auf der Black Hat USA Anfang August vorgestellt werden sollte: TLBleed.

Mit TLBleed lassen sich auf Systemen mit Intel-Prozessoren mit Hyper-Threading geschützte Informationen aus einem Thread auslesen, der gemeinsam mit dem bösartigen Thread auf demselben CPU-Kern läuft. Für diesen Seitenkanalangriff werden die Eigenschaften des Translation Lookaside Buffers (TLB) ausgenutzt, einem Bestandteil des Caches.

Bei Tests mit Intel-Prozessoren verschiedener Generationen war der TLBleed-Angriff in mehr als 99 Prozent der Fälle erfolgreich. So war es möglich, einen geheimen 256-Bit-Schlüssel auszuspähen, während ein Thread eine Signatur mit dem Curve25519-EdDSA-Algorithmus aus der libgcrypt-Bibliothek berechnete.

Intel will die Schwachstelle nicht beseitigen; dort ist man der Meinung, kritischer Code könne so angepasst werden, dass der Seitenkanalangriff nicht funktioniert.

Schwachstellenpaket 5: NetSpectre

Bisher waren alle Angriffe auf die Spectre-Schwachstellen nur lokal möglich. Im Juli  2018 änderte sich das: NetSpectre ermöglicht Spectre-Angriffe über das Netz.

Entwickelt wurde NetSpectre vom Forscherteam der TU Graz, das zu den Entdeckern der Spectre-Schwachstellen gehört. NetSpectre verwendet im Grunde die Methoden von Spectre V1, arbeitet aber über Netzwerkverbindungen und kommt ohne Schadcode auf dem Zielsystem aus. Es werden normale Netzwerkfunktionen in Betriebssystemen, Treibern oder in Serversoftware als sogenannte Gadgets missbraucht. Darunter verstehen die Forscher Codeschnipsel, die sie zum Ausspähen eigentlich nicht zugänglicher Speicherstellen (sog. Leak-Gadgets) bzw. zum Versand dieser Informationen über das Netz (sog. Transmit-Gadgets) missbrauchen. Diese Gadgets werden aktiviert, indem über das Netzwerk präparierte Pakete an das Zielsystem geschickt werden. Theoretisch kann über NetSpectre jede beliebige RAM-Adresse ausgespäht werden. Das Ganze läuft allerdings sehr langsam ab, selbst über lokale Gigabit-Ethernet-Netze können nur wenige Bytes pro Stunde ausgespäht werden.

Zum Schutz vor NetSpectre-Angriffen kann auf die Schutzmaßnahmen gegen Spectre-V1-Angriffe zurückgegriffen werden. Oder andersrum formuliert: Systeme, die gegen Spectre-V1-Angriffe geschützt sind, sind auch vor Angriffen durch NetSpectre sicher.

Während man bis zur Veröffentlichung von NetSprectre davon ausgehen konnte, dass Netzwerkgeräte wie Router oder NAS vor Spectre-Angriffen sicher waren, so lange darauf kein Schadcode läuft, sieht es seitdem deutlich gefährlicher aus: Alle Netzwerkgeräte sind potenziell gefährdet, benötigen also auch Patches. Und damit sieht es i. Allg. ziemlich schlecht aus.

ret2spec und SpectreRSB

Ebenfalls im Juli 2018 wurden ret2spec und SpectreRSB vorgestellt, zwei unabhängig voneinander entwickelte neue Angriffe, die den Return Stack Buffer (RSB) von Intel-Prozessoren zum Ausspähen geschützter Speicherbereiche durch spekulative Ausführung missbrauchen. Die Schwachstellen basieren auf der Tatsache, dass die Prozessoren zur Laufzeitoptimierung auch Rücksprungadressen vorhersagen. Wenn ein Angreifer diese Vorhersage manipuliert, erhält er die Kontrolle über den spekulativ ausgeführten Code und kann über Seitenkanalangriffe Daten auslesen, die eigentlich vor Zugriffen geschützt sind.

ret2spec erlaubt Schadcode auf dem Rechner z.B. das Lesen von Speicherinhalten anderer Prozesse, und über JavaScript-Code im Browser können z. B. gespeicherte Passwörter ausgespäht oder Sessions übernommen werden. ret2spec wurde von den Entdeckern auch als Spectre V5 bezeichnet.

SpectreRSB erlaubt ebenfalls den Zugriff auf Speicherinhalte anderer Prozesse, aber auch Angriffe aus SGX-Enklaven. Eventell ist auch der Zugriff auf Speicher anderer virtueller Maschinen möglich.

Haben Sie vor 2018 schon mal was von CPU-Schwachstellen gehört? Innerhalb eines Jahres haben wir jetzt Spectre und Meltdown und weitere, davon unabhängige Schwachstellen.

Schwachstellenpaket 7: SplitSpectre und der Speculator

Der nächste Angriff wurde im Oktober präsentiert: SplitSpectre. Da es sich dabei um eine Variante eines browserbasierten Angriffs auf Spectre  V1 handelt, könnte man diesen Angriff eigentlich dort einordnen. Da er aber zum einen deutlich einfacher als die bisherigen browserbasierten Angriffe ist und zum anderen mit Hilfe eines Tools entdeckt wurde, mit dem sehr wahrscheinlich weitere Schwachstellen bzw. Angriffsvarianten entdeckt werden, habe ich Angriff und Tool zusammen ein eigenes Paket gegönnt.

SplitSpectre

Bei einem Angriff auf Spectre V1 benötigt der Angreifer verwundbaren Code im Zielsystem, den er angreifen kann: die schon erwähnten Gadgets. SplitSpectre teilt diese Gadgets in zwei Komponenten auf und ermöglicht es dem Angreifer dadurch, mehr eigenen Code unterzubringen. Er benötigt dadurch also weniger verwundbaren Code auf dem Zielsystem, wodurch der Angriff leichter durchführbar wird.

Außerdem verlängert der Angriff den Zeitraum, in dem der Prozessort abgreifbar ist, sodass das Zeitfenster für den Angriff größer wird. Die Entdecker von SplitSpectre haben als Test die JavaScript-Engine von Firefox angegriffen und versucht, zehn aufeinander folgende Zeichen zu lesen. In zehn Prozent der Versuche konnten sie alle zehn Zeichen ermitteln.

Speculator

SplitSpectre wurde mit einem von den Forschern entwickelten Tool zur Untersuchung der spekulativen Ausführung entdeckt: Speculator. Das erleichtert das Reverse Engineering der Funktionen und soll veröffentlicht werden.

Schwachstellenpaket 8: PortSmash

Im November 2018 wurde eine Schwachstelle im simultanen Multithreading (SMT) – von Intel Hyper-Threading genannt – entdeckt: PortSmash. Es handelt sich wieder mal um einen Seitenkanalangriff, über den Daten eines zweiten Threads auf demselben CPU-Kern gelesen werden können. Der Proof-of-Concept-Code zu PortSmash liest einen P-384-Private-Key einer TLS-Verschlüsselung mit OpenSSL (bis Version 1.1.0h) aus. Die Schwachstelle hat die CVE-ID CVE-2018-5407; besonders gefährdet sind wieder Cloud-Umgebungen. Zum Schutz vor den Angriffen sollte Hyper-Threading ausgeschaltet werden.

Schwachstellenpaket 9: Weitere fünf Spectre- und zwei Meltdown-Schwachstellen

Und noch eine Veröffentlichung aus dem November 2018: Eine Forschergruppe, die die bisher veröffentlichten Spectre-Schwachstellen und die dazugehörigen Patches eingehend untersucht hat, ist auf fünf weitere Spectre- und zwei weitere Meltdown-Schwachstellen gestoßen. Die sind zum Teil allerdings ziemlich speziell und z. B. davon abhängig, welche Daten zuvor verarbeitet wurden.

Schwachstellenpaket 10: Schwachstellen in Intels Debugging-Schnittstelle

Maxim Goryachy und Mark Ermolov werden auf der im März 2019 stattfindenden Black Hat Asia 2019 zeigen, wie sie über eine von ihnen in Intels Management Engine gefundene Schwachstelle Zugriff auf Intels Debugging-Schnittstelle Visualization of Internal Signals Architecture (VISA) erhalten haben. Darüber ist dann der Zugriff auf sensible Daten möglich. Der Angriff erfordert allerdings physischen Zugriff auf das System.

Schwachstellen sind immer Fehler, die ein Angreifer für seine Zwecke ausnutzen kann.

Microcode?

Falls es Sie interessiert, wie das mit den Microcode-Updates eigentlich funktioniert, könnte ein Vortrag vom 35C3 interessant für Sie sein: Benjamin Kollenda und Philipp Koppe haben in „Inside the AMD Microcode ROM“ und [15] gezeigt, wie über Microcode-Updates Funktionen nachgerüstet werden können. Das hat zwar nicht direkt etwas mit den Updates zur Korrektur der Spectre-Schwachstellen zu tun, das Grundprinzip ist aber das gleiche.

Fazit

Haben Sie vor 2018 schon mal was von CPU-Schwachstellen gehört? Klar, es gab 1994 den FDVI-Bug im Intel Pentium, durch den der Prozessor sich bei bestimmten Gleitkommadivisionen verrechnete. Aber das war ein Fehler, keine Schwachstelle – darüber ließ sich kein Schaden anrichten.

Es gab Schwachstellen in der Intel Management Engine und der Firmware, aber in der CPU selbst kann ich mich nur an Fehler erinnern. Und Google liefert dazu auch nicht besonders viel, wenn man die Suche auf die Zeit vor Januar 2018 beschränkt.

Und jetzt haben wir Spectre und Meltdown – im Fall von Spectre sogar zig Varianten – und ein paar weitere, davon unabhängige Schwachstellen. Und das alles innerhalb eines Jahres! Ich fürchte, wie anfangs schon geschrieben, dass da noch viele weitere Schwachstellen und Angriffe folgen werden.

Das alles kann man nun eigentlich wirklich nicht gebrauchen. Aber wenn man es realistisch betrachtet, musste es irgendwann so kommen.

Schwachstellen sind immer auch Fehler, sie unterscheiden sich davon nur dadurch, dass ein Angreifer sie für seine Zwecke ausnutzen kann. Und Fehler in Software werden gerne damit erklärt, dass sie so komplex ist, dass sie sich einfach nicht vermeiden lassen.

CPUs sind noch viel komplexer, warum sollten sie also keine Fehler enthalten? Und warum sollten diese Fehler alle „nur“ Fehler sein und nicht auch einige davon ausnutzbare Schwachstellen? Möglich ist das, nur hat sich halt bisher niemand näher damit beschäftigt.

Es ist gut, dass sich das geändert hat. Es ist immer noch besser, die Sicherheitsforscher finden die Schwachstellen und melden sie zur Korrektur an die Hersteller, als wenn Cyberkriminelle oder Geheimdienste sie finden, geheim halten und für ihre Angriffe ausnutzen.

Links & Literatur

[1] Eilers, C.: „Neue Gefahren für die CPU“, Windows Developer 4.2018
[2] Kocher, P.; Genkin, D.; Gruss, D.; Haas, W.; Hamburg, M.; Lipp, M.; Mangard, S.; Prescher, T.; Schwarz, M.; Yarom, Y.: „Spectre Attacks: Exploiting Speculative Execution“: https://spectreattack.com/spectre.pdf
[3] Lipp, M.; Schwarz, M.; Gruss, D.; Prescher, T.; Haas, W.; Mangard, S.; Kocher, P.; Genkin, D.; Yarom, Y.; Hamburg, M.: „Meltdown“: https://meltdownattack.com/meltdown.pdf
[4] Galowicz, J.; Cyberus Technology: „Meltdown“: http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.html
[5] Intel Security Advisory INTEL-SA-00115 – „Q2 2018 Speculative Execution Side Channel Update“: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html
[6] Microsoft Security Advisory ADV180012 – „Microsoft Guidance for Speculative Store Bypass“: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180012
[7] Intel Security Advisory INTEL-SA-00145 – „Lazy FP state restore“: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html
[8] Microsoft Security Advisory ADV180016 – „Microsoft Guidance for Lazy FP State Restore“: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180016
[9] Intel Security Advisory INTEL-OSS-10002 – „Speculative Execution Branch Prediction Side Channel and Branch Prediction Analysis Method“: https://01.org/security/advisories/intel-oss-10002
[10] Microsoft Security Advisory ADV180002 – „Guidance to mitigate speculative execution side-channel vulnerabilities“: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180002
[11] Kiriansky, V.; Waldspurger, C.: „Speculative Buffer Overflows: Attacks and Defenses“: https://people.csail.mit.edu/vlk/spectre11.pdf ; https://arxiv.org/abs/1807.03757
[12] Foreshadow: Breaking the Virtual Memory Abstraction with Transient Out-of-Order Execution: https://foreshadowattack.eu
[13] Intel Security Advisory INTEL-SA-00161: „Q3 2018 Speculative Execution Side Channel Update: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
[14] Eilers, C.: „Alles nur (ge)Cloud?“; Windows Developer 10.18
[15] Kollenda, B.; Koppe, P.; 35C3: „Lecture: Inside the AMD Microcode ROM“: https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9614.html
Medien: https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -