Original-URL des Artikels: https://www.golem.de/news/schwer-ausnutzbar-die-ungefixten-sicherheitsluecken-1901-138336.html    Veröffentlicht: 15.01.2019 12:05    Kurz-URL: https://glm.io/138336

Schwer ausnutzbar

Die ungefixten Sicherheitslücken

Sicherheitslücken wie Spectre, Rowhammer und Heist lassen sich kaum vollständig beheben, ohne gravierende Performance-Einbußen zu akzeptieren. Daher bleiben sie ungefixt. Trotzdem werden sie bisher kaum ausgenutzt.

Diese Meldung sorgte für einige Aufregung unter den Linux-Kernel-Entwicklern: Die Webseite Phoronix hatte im November Messungen einer neuen Kernelversion durchgeführt und dabei bei einigen Benchmarks Geschwindigkeitsverluste von 40 Prozent festgestellt. Nach einigem Suchen stellte sich dann heraus: Was den Kernel so langsam machte, war ein Feature namens STIBP (Single Thread Indirect Branch Predictors), eine Funktion, die das Ausnutzen bestimmter Varianten der Spectre-Sicherheitslücke verhindern sollte.

Nach einigen Umbauarbeiten funktioniert STIBP inzwischen ohne diese gravierenden Performanceeinbußen und ist in jüngsten Kernelversionen auch standardmäßig aktiviert. Aber die Episode zeigt, wie Entwickler von Betriebssystemen mit den Folgen der CPU-Sicherheitslücken Meltdown, Spectre und den zahlreichen Varianten zu kämpfen haben.

Spectre-Gegenmaßnahmen unzureichend

Der Erfolg ist dabei eher bescheiden. In einem kürzlich veröffentlichten Paper versuchten einige der Spectre-Entdecker eine Übersicht zu schaffen, welche Varianten von Spectre es gibt und wie gut verschiedene Gegenmaßnahmen helfen. Das enttäuschende Fazit: Praktisch alle Maßnahmen helfen nur teilweise oder nur gegen einzelne Varianten von Spectre. Für eine der originalen Spectre-Varianten gibt es nach wie vor überhaupt keine zufriedenstellende Gegenmaßnahme.

Das Grundproblem von Spectre ist ein Designprinzip moderner Prozessoren: die sogenannte spekulative Codeausführung. Dabei werden bereits vorab Codebestandteile ausgeführt, die Ergebnisse werden jedoch verworfen, wenn sich zwischenzeitlich Daten ändern oder diese Codestelle überhaupt nicht ausgeführt werden soll. Seiteneffekte dieser spekulativ ausgeführten Codes lassen sich jedoch beobachten, etwa durch Cache-Zugriffszeiten.

Diese spekulative Codeausführung gibt es in allen modernen Mainstream-Prozessoren und sie wird seit Jahrzehnten eingesetzt, um die Leistung zu optimieren. Der Marktführer Intel setzt seit der Pentium-Pro-Serie auf spekulative Codeausführung, diese wurde 1995 veröffentlicht.

Theoretisch gäbe es eine Radikallösung, um Spectre und alle Varianten davon loszuwerden: Man müsste komplett auf die spekulative Codeausführung verzichten. Bisher haben Prozessoren keine Funktion, um die spekulative Codeausführung abzuschalten, und lediglich einige Nischenprodukte wie das Open-Source-Projekt RISC-V kommen ohne sie aus. Doch der Nachteil liegt auf der Hand: Ein solcher Prozessor wäre um ein Vielfaches langsamer.



Vermutlich wurde bisher niemand durch Spectre gehackt

Es ist kaum anzunehmen, dass Laptop-Käufer und Smartphone-Kunden ein Gerät kaufen würden, das bei gleichem Preis nur einen Bruchteil der Leistung bringt. Doch ganz davon abgesehen stellt sich eine andere Frage: Ist Spectre überhaupt wichtig genug, um den Bug mit hohen Performancekosten zu fixen?

Bisher gibt es keinen einzigen bekannten Fall, in dem Spectre tatsächlich für einen Angriff eingesetzt oder von einer Malware ausgenutzt wurde. Natürlich ist es theoretisch denkbar, dass Angriffe stattgefunden haben, die nicht bekannt wurden oder zu denen die Details geheim blieben. Doch es spricht manches dafür, dass die Auswirkungen von Spectre insgesamt begrenzt sind.

Denn einen praktikablen Exploit für Spectre zu entwickeln, ist hochkomplex. Generell ist Spectre nur in Situationen interessant, in denen man in irgendeiner Weise Code auf dem System des Opfers ausführen kann. Szenarien, in denen das wirklich eine Rolle spielt, gibt es wenige, und oft gibt es sehr viele potenzielle Störungen, die das Auslesen der Seitenkanäle erschweren. Selbst ein funktionierender Exploit führt nicht dazu, dass man ein System direkt übernehmen kann, sondern lediglich dazu, dass man unberechtigt Speicherbereiche ausliest.

In vielen Fällen dürfte es für Angreifer praktikabler sein, auf unentdeckte andere Sicherheitslücken zu setzen. Die zu finden und auszunutzen ist unter Umständen mit weniger Aufwand verbunden als ein hochkomplexer Spectre-Exploit.

Rowhammer: Speicherbitflips und unzuverlässige Hardware

Spectre ist nicht der einzige Fall, in dem eine Sicherheitslücke unzureichend behoben wurde. Eine andere Lücke, die ebenfalls auf die Eigenschaften von Hardware abzielt, ist Rowhammer.

Die Grundidee: Der Arbeitsspeicher arbeitet nicht hundertprozentig zuverlässig. Das ist auch keine Überraschung: Bits müssen in der physikalischen Welt gespeichert werden und die ist nicht vollständig berechenbar und von zahlreichen Störeinflüssen umgeben. Was die Rowhammer-Entdecker herausfanden: Wenn man sehr häufig auf eine bestimmte Speicherstelle schreibt, führt es manchmal dazu, dass das Speicherbit daneben umkippt.

Rowhammer mit Javascript - und trotzdem keine Angriffe

Einige Zeit später zeigte ein anderes Forscherteam, dass sich ein solcher Angriff mittels Javascript durchführen lässt - was ihn scheinbar praktikabler machte.

Als relativ sicherer Schutz vor Rowhammer galt bisher sogenannter ECC-Speicher. Dieser speichert in zusätzlichen Bits Checksummeninformationen und kann einzelne Speicherbitfehler korrigieren und Zwei-Bit-Fehler zumindest erkennen. Doch im November konnte zum ersten Mal praktisch gezeigt werden, dass auch ECC-Speicher für Rowhammer anfällig ist.

Die Industrie reagierte auf Rowhammer mit verschiedenen Gegenmaßnahmen. So wurde beispielsweise häufig die Speicher-Refresh-Rate heruntergesetzt, was erfolgreiche Angriffe unwahrscheinlicher macht. Doch hier gilt - in gewisser Weise ähnlich wie bei Spectre -, dass ein solcher Schutz zu schlechterer Performance führt. Und perfekt ist er allemal nicht, man senkt nur die Chancen für einen Angriff.

Man könnte vermutlich Arbeitsspeicher bauen, bei dem Rowhammer-artige Angriffe nahezu ausgeschlossen sind - etwa indem man deutlich ausgefeiltere Checksummen und mehr Redundanz einführt, so dass auch größere Bitfehler korrigiert oder zumindest erkannt werden können; doch in der Praxis gibt es solche Speicherchips bislang nicht. Ob es dafür Bedarf gäbe, ist fraglich: Der Speicher wäre teurer und langsamer - und auch Rowhammer spielt in der Praxis kaum eine Rolle.

Um Rowhammer praktisch auszunutzen, muss man Details über das physikalische Speicherlayout des Arbeitsspeichers kennen. Der Angriff muss also auf die jeweilige Hardware abgestimmt werden. In der Praxis ist das in der Regel wohl zu aufwendig - Berichte über Angriffe gibt es bisher nicht.



Kompressionsangriffe gegen TLS

Eine etwas anders gelagerte Klasse von Sicherheitslücke, bei der sich jedoch ähnliche Phänomene beobachten lassen, finden sich in der Internet-Verschlüsselung TLS im Zusammenhang mit Kompression.

Aus Performancegründen werden Daten bei der Übertragung sehr häufig komprimiert. Bei verschlüsselten Daten müssen diese vor der Verschlüsselung komprimiert werden, denn andernfalls würde es wenig Sinn machen: Verschlüsselte Daten sind ohne den entsprechenden Schlüssel Pseudo-Zufallswerte und lassen sich nicht komprimieren.

Doch die Kompression kann dazu führen, dass Informationen über die verschlüsselten Daten preisgegeben werden. Die grundlegende Idee dabei ist relativ simpel: Ein Angreifer hat in vielen Fällen die Möglichkeit, Teile einer Datenverbindung zu kontrollieren, während er an einem anderen Teil interessiert ist. Bei HTTPS-Verbindungen treten solche Situationen häufig auf. Somit kann ein Angreifer an einer Stelle Teile des Geheimnisses raten; und wenn die komprimierten Daten kleiner sind, liegt er vermutlich richtig. Somit kann man Schritt für Schritt die geheimen Daten extrahieren.

Die grundlegende Idee von Kompressionsangriffen wurde bereits im Jahr 2000 von John Kelsey erläutert. Adam Langley spekulierte 2011, wie ein solcher Angriff zur Entschlüsselung von HTTPS-Cookies eingesetzt werden könnte. 2012 präsentierten dann Juliano Rizzo und Thai Duong den CRIME-Angriff, in dem sie das praktisch zeigten.

Der Crime-Angriff nutzt die Kompression von TLS, was letztendlich dazu führte, dass diese aus TLS entfernt wurde, da sie sowieso kaum genutzt wurde. Die jüngste TLS-Version 1.3 enthält keine Kompression mehr.

Doch die TLS-Kompression war überhaupt nicht nötig, um diesen Angriff durchzuführen, denn viele Protokolle bringen eigene Kompressionsverfahren mit. 2013 wurde mit dem Breach-Angriff gezeigt, wie sich ein solcher Angriff mittels HTTP-Kompression durchführen lässt. Dieser Angriff wurde immer weiter verbessert, weitere Varianten wurden unter den Namen TIME und Heist veröffentlicht. Diese funktionierten sogar ohne einen Man-in-the-Middle-Angriff, die Datengröße wird mittels Javascript und Timing-Angriffen herausgefunden.

Einen wirklich zufriedenstellenden Fix gibt es für das Problem bisher nicht. Man kann mit einzelnen Maßnahmen, etwa durch die Verwendung von sogenannten Same-Site-Cookies bestimmte Angriffsszenarien verhindern. Ein genereller Schutz ist das aber nicht.

Bei der Kompression von Headern in HTTP2 hat man mit HPACK versucht, eine Kompression zu nutzen, die nicht für derartige Angriffe anfällig ist. Doch HPACK ist nicht perfekt und das Verfahren ist auf andere Daten nicht einfach übertragbar.

Wirklich beheben könnte man das Problem nur, wenn man die Kompression von geheimen und nicht geheimen Daten separiert und beispielsweise geheime Tokens von der Kompression ausschließt. Das ist aber extrem komplex und bisher beispielsweise in HTTP nicht vorgesehen.

Kompression abschalten? Dafür funktioniert sie zu gut!

Natürlich gäbe es auch hier eine Radikallösung: die Kompression komplett abzustellen. Doch das möchte kaum jemand machen. Der HTML-Code von Webseiten lässt sich extrem gut komprimieren und bei Webseitenaufrufen sind selbst kleine Performancegewinne spürbar. Und auch hier gilt: Berichte darüber, dass die Kompressionsangriffe praktisch ausgenutzt wurden, gibt es bisher nicht.

Die Beispiele hier zeigen, dass es Situationen gibt, in denen sich bestimmte Sicherheitslücken nicht zufriedenstellend beheben lassen oder nur zu Kosten, die kaum jemand bereit ist zu zahlen. Das ist einerseits beunruhigend, hat aber andererseits ganz offensichtlich bisher keine größeren Auswirkungen. Zumindest Massenangriffe gibt es bisher weder mittels spekulativer Codeausführung noch mittels Timing-Angriffen auf verschlüsselte Datenströme. Unklar bleibt natürlich, ob es Angriffe gab, die nicht öffentlich bekannt wurden.

Mittelfristig wird sich zeigen, ob es Angreifern gelingt, Angriffe wie Spectre so weit praktikabel zu machen, dass sie im größerem Umfang zum Problem werden - und ob irgendwann Prozessoren ohne spekulative Codeausführung zum Verkaufsschlager werden. Bisher sieht es aber nicht danach aus.  (hab)


Verwandte Artikel:
Retpoline: Linux-Kernel soll besseren Spectre-Schutz bekommen   
(02.01.2019, https://glm.io/138448 )
ECCploit: Rowhammer-Angriff funktioniert auch mit ECC   
(22.11.2018, https://glm.io/137863 )
TLS-Zertifikate: Mkcert vereinfacht Web-Entwicklung mit lokalem HTTPS   
(07.01.2019, https://glm.io/138545 )
HEIST: Timing- und Kompressionsangriff auf TLS   
(04.08.2016, https://glm.io/122508 )
Passwörter: Eine vernünftige Maßnahme gegen den IoT-Irrsinn   
(09.10.2018, https://glm.io/136995 )

© 1997–2020 Golem.de, https://www.golem.de/