NetSpectre liest RAM via Netzwerk aus
NetSpectre greift ohne ausführbaren Schadcode an – zwar fließen nur wenige Bytes pro Stunde, aber ungeschützte Server und Storage-Systeme sind angreifbar.
Das Forscherteam der TU Graz, das zu den Entdeckern der Spectre-Lücken in Prozessoren von Intel, AMD, ARM und IBM gehört, legt nach: NetSpectre nutzt im Prinzip die Methoden von Spectre V1, allerdings über Netzwerkverbindungen sowie ohne Schadcode auf das Zielsystem zu bringen. NetSpectre missbraucht normale Netzwerk-Funktionen in Betriebssystemen, Treibern oder in Server-Software als sogenannte Gadgets.
Zwei Faktoren schränken die Gefährlichkeit von NetSpectre ein: Einerseits schützen die bereits bekannten Maßnahmen und Patches gegen Spectre V1 (Bounds Check Bypass) auch gegen NetSpectre und andererseits liefert NetSpectre selbst über schnelle lokale Gigabit-Ethernet-Netze nur wenige Bytes pro Stunde.
NetSpectre-Angriffe könnten allerdings theoretisch sehr lange unbemerkt laufen als Advanced Persistent Threats (APT) und somit dann doch kritische Informationen liefern. Im Prinzip erreicht NetSpectre jede beliebige RAM-Adresse, also auch Passwörter, geheime Schlüssel und Zertifikate. Die Angriffstechnik ist allerdings kompliziert, das Paper von Michael Schwarz, Martin Schwarzl, Moritz Lipp und Daniel Gruss umfasst fast 14 Seiten.
Server, Storage-Systeme und Netzwerkgeräte
Nach bisherigen Vorstellungen erforderten Spectre-Angriffe das Ausführen von bösartigem Code auf dem Zielsystem. Damit erschienen viele Geräte als sicher, etwa weil dort niemand eigenen Code ausführen darf – und wenn ein Angreifer das doch schafft, ist das System ohnehin geknackt. Diese optimistische Einschätzung haben die Forscher mit ihrer Arbeit zertrümmert. Denn Schwarz et al zeigen, dass man Spectre übers Netz etwa gegen Router oder Server einsetzen kann, um geheime Informationen zu stehlen. Dabei wird wohlgemerkt kein Code in das Zielsystem eingeschleust und ausgeführt.
Die Basis der Angriffe ist nach wie vor das von Spectre aufgedeckte Grundproblem moderner Prozessoren: Sicherheit wird zugunsten von Performance geopfert. Konkret führen moderne Prozessoren "auf Verdacht" schon mal Code aus, von dem noch gar nicht feststeht, ob er wirklich ausgeführt werden soll. Für diese spekulative Ausführung gelten nicht die herkömmlichen Sicherheitsregeln, die etwa den Zugriff auf geschützten Speicher verhindern.
Für NetSpectre nutzen die Forscher auf dem System bereits vorhandenen Code, um Informationen übers Netz hinweg abzugreifen. Sie sprechen dabei von einem Leak-Gadget, also einem Code-Schnippsel, der Informationen über eine eigentlich nicht zugängliche Speicherstelle extrahiert, sowie von einem Transmit-Gadget, das diese Information über das Netz verschickt.
Beide Code-Schnipsel aktiviert der Angreifer, indem er ĂĽbers Netz Pakete an das Zielsystem schickt. Genauer beschreiben Schwarz et al das in Kapitel 3 des Papers NetSpectre: Read Arbitrary Memory over Network.
| Die CPU-SicherheitslĂĽcken Meltdown und Spectre | ||
| (Google-)Name | Kurzbezeichnung | CVE-Nummer |
| Spectre V1 | Bounds Check Bypass | CVE-2017-5753 |
| Spectre V1.1 | Bounds Check Bypass Store | CVE-2018-3693 |
| Spectre V1.2 | Read-only Protection Bypass | k.A. |
| Spectre V2 | Branch Target Injection (BTI) | CVE-2017-5715 |
| Meltdown (GPZ V3) | Rogue Data Cache Load | CVE-2017-5754 |
| Spectre-NG: | ||
| Spectre V3a | Rogue System Register Read (RSRE) | CVE-2018-3640 |
| Spectre V4 | Speculative Store Bypass (SSB) | CVE-2018-3639 |
| k.A. | Lazy FP State Restore | CVE-2018-3665 |
| Spectre-Varianten via Return Stack Buffer (RSB) | ||
| "Spectre v5" | ret2spec | k.A. |
| k.A. | SpectreRSB | k.A. |
| zu fĂĽnf weiteren Spectre-NG-LĂĽcken fehlen noch Informationen | ||
| GPZ steht fĂĽr Google Project Zero, Spectre V1 und V2 werden auch GPZ V1 und GPZ V2 genannt | ||
(ciw)
