- Welche Folgen hat Meltdown?
- Welche Folgen hat Spectre?
- Geht es technischer?
- Auf welcher Hardware lassen sich Meltdown/...
- Wann gibt es Updates (bei Ubuntu) dafür?
- Welche Auswirkungen haben die Updates?
- Warum bekommen Browser Updates?
- Warum wird das gerade so durch die Presse ...
- Fazit
- Fehlt doch eigentlich nur noch ein XKCD?
Welche Folgen hat Meltdown?¶
Meltdown löst die Speichertrennung zwischen Betriebssystem und Anwendungen auf. Deshalb kann ein Programm Speicher aller laufenden Programme oder des Betriebssystems lesen. Auf ungepatchten Systemen besteht daher das Risiko, sensitive Informationen wie Passwörter offenzulegen.
Welche Folgen hat Spectre?¶
Spectre löst die Speichertrennung zwischen zwei Programmen auf. Auch dadurch können private Daten wie Passwörter ungewollt an Dritte gelangen. Spectre ist schwieriger ausnützbar als Meltdown, aber auch schwieriger zu verhindern.
Geht es technischer?¶
Sicher. Wer es auf deutsch möchte, für den ist die Analyse von Andreas Stiller empfehlenswert.
Auf englisch gibt es wiederum noch sehr viel mehr Lesestoff. Angefangen von der Webseite zu Meltdown und Spectre über die beiden Papers zu Meltdown und Spectre, bis hin zu einem Post von Googles Project Zero. Recht anschaulich ist auch die Erklärung, warum die Raspberry Pis nicht betroffen sind. LWN.net sammelt Links auf weitere Artikel.
Auf welcher Hardware lassen sich Meltdown/Spectre ausnutzen?¶
Sehr spitz formuliert: Auf vielen™ CPUs – gerade mit x86-Architektur, aber nicht nur.
Meltdown betrifft potenziell alle Intel-CPUs seit 1995, die out-of-order execution beherrschen – abgesehen von Intel Itaniums und Intel Atoms vor 2013. Bei AMD sei es nach Angaben der Entdecker noch unklar. ARM hat eine Liste von betroffenen CPUs 🇬🇧.
Spectre wurde nach Angaben der Entdecker auf Intel-, AMD-, und ARM-Prozessoren getestet.
Wer genaueres wissen möchte, schaut am besten in die Liste auf der Meltdown/Spectre-Seite 🇬🇧. Dort sind quasi alle Ankündigungen der großen Hersteller verlinkt.
Wann gibt es Updates (bei Ubuntu) dafür?¶
Für die beiden Bugs Fehlerbeseitigung zu entwickeln, liegt mehr im Aufgabenbereich des Linux-Kernels als der einer Distribution. Allerdings muss die Distribution diese Änderungen verteilen und ggf. auch davor testen, ob es anderweitig Probleme auf den Systemen der Endkunden geben könnte.
Linux-Kernel¶
Das Drumherum um Meltdown und Spectre im Linux-Kernel, erläutert Greg Kroah-Hartman in einem Blogpost 🇬🇧. Der Linux-Kernel 4.15-rc7 enthält demnach die „Kernel page table isolation (KPTI)“ für x86, was Meltdown verhindert (Kerneloption CONFIG_PAGE_TABLE_ISOLATION). Portierungen existieren für 4.14, 4.4 und 4.9. Bei den letzten beiden können ggf. noch Probleme mit virtuellen Maschinen oder VDSO auftreten. Andere Kernelportierungen liegen in Hand der Distributionen.
Meltdown-Patches für ARM64 werden wahrscheinlich erst in Linux 4.16 aufgenommen. Wer früher die Patches für ARM64 benötigt, den verweist Greg Kroah-Hartman auf den Common Android Kernel Tree.
Für Spectre arbeiten die Linux-Kernel-Entwickler aktuell noch an mehreren Patches. Möglicherweise wurde Spectre bereits durch die verwendete Distribution gepatcht. Ein manuelles Testen, ob die Distribution-Patches vollständig das Problem lösen, sei trotzdem nötig. Im upstream-Kernel ist aktuell kein Fix vorhanden. Lösungsvorschläge werden aktuell diskutiert und befinden sich in Entwicklung. Helfen könnte gegen Spectre beispielsweise Retpoline 🇬🇧.
Nach Greg Kroah-Hartman wird es noch einige Wochen brauchen, bis Spectre in Linux beseitigt sei. Grund sei vor allem, dass an Meltdown gearbeitet wurde und zu Spectre weniger Informationen vorhanden waren.
Ubuntu¶
Für Meltdown sollen spätestens am 9. Januar, dem ursprünglichen abgesprochenen Veröffentlichungsdatum, Kernelupdates für Ubuntu 17.10, 16.04 LTS und 14.04 LTS erscheinen (das Update für 12.04 LTS erhalten nur zahlende Extended-Security-Maintenance-Kunden). Den aktuellen Stand der Dinge erfährt man im ubuntu Wiki auf einer Seite des Security Teams 🇬🇧.
Die Verzögerung gegenüber dem Linux-Kernel erklärt sich vor allem damit, dass intern nochmals ausgiebig getestet wird, ob anderweitige Probleme durch die Patches entstehen. Zudem gab es für Linux in Version 4.13 keine offiziellen Patches. Stattdessen musste Canonical diese selbst zurückportieren. Kernel 4.13 wird zum Beispiel in Ubuntu 17.10 Artful oder 16.04 mit LTS Enablement Stacks verwendet. 16.04 (mit Enablement Stacks) wird damit früher von Linux 4.10 auf 4.13 wechseln.
Darüber hinaus werden Updates für den Microcode der Prozessoren, den Compiler GCC sowie den Virtualisierer QEMU folgen. Es ist also sinnvoll wie immer Updates zu installieren. Außerdem sollte man in nächster Zeit bei seinem Motherboardhersteller prüfen, ob Firmwareupdates verfügbar sind.
Welche Auswirkungen haben die Updates?¶
Für den Endanwender funktioniert hoffentlich noch alles. Ansonsten hat man einen Bug gefunden, was angesichts des Entstehungstempos der Fixes und der Vielzahl an betroffenen Geräten durchaus vorkommen kann.
Performancemäßig könnte es zu Einbußen kommen. Diese betreffen nach RedHat 🇬🇧 aber vor allem zufälliges Lesen mit buffered I/O, Datenbanken oder Anwendungen mit vielen Kontextwechsel zwischen User- und Kernelspace. Nach RedHat ist dort ein Performanceverlust von 8 bis 19% zu verzeichnen. Mit 3 bis 7% ist bei netzwerk-lastigen und sequenziell lesenden Programmen zu rechnen, da Daten vom Kernel intern zusammengefasst und dann erst der Kontextwechsel ausgeführt werden kann. Java VMs fallen auch in diese Kategorie. Rechenintensive Anwendungen werden nach RedHat um 2 bis 5% verlangsamt, da diese vor allem in Userspace laufen.
Das passt grob zu den Tests von Phoronix, die ebenfalls ein paar Benchmarks für Kernel mit KPTI bieten: Auf blanker Hardware, in VMs und in Docker. Einen Vorgeschmack, was die Auswirkungen der in Entwicklung befindlichen Patches für Retpoline ausfallen, gibt es dort ebenfalls 🇬🇧.
Letztendlich kann man die Fragen nach den Auswirkungen aber nicht pauschal beantworten, sondern es kommt (wie so häufig) auf den Einzelfall an. Dabei ist es sinnvoll – wenn möglich – zu vergleichen und im Idealfall selbst der Ursache auf den Grund zu gehen. So wurde bei Phoronix festgestellt, dass man mit Clear Linux 🇬🇧 mit aktivierten KPTI immer noch eine bessere Performance als bei Ubuntu/Debian ohne KPTI erreichen kann.
Warum bekommen Browser Updates?¶
Das Problem hier ist, dass die Lücken via JavaScript ausgenützt werden können. In Folge dessen können vom Browser aus private Daten ausgelesen werden. Die Reaktionen sind eindeutig:
Firefox hat schon ein Update in Form von Version 57.0.4 bekommen 🇬🇧, um einen Angriff zu erschweren. Firefox 52 ESR ist wegen einem fehlenden Feature (SharedArrayBuffer 🇬🇧) weniger davon betroffen und wird deshalb erst zum 23. Januar ein Update erhalten.
Auch Chrome hat die selben Maßnahmen 🇬🇧 als Update verteilt oder angekündigt.
Ebenso werden Edge und Internet Explorer sehr ähnliche Updates erhalten 🇬🇧. (Der Vollständigkeit halber, um zu illustrieren, dass es bei diesen Bugs relativ egal ist, welchen Browser man verwendet.)
Jetzt ist zudem wieder ein guter Zeitpunkt, um über AdBlocker wie uBlock Origin, die zumindest JavaScript aus Werbenetzwerken blocken, oder ein selektives Aktivieren von JavaScript im Browser (z.B. via uMatrix) nachzudenken (siehe Alan Cox Einschätzung). AdBlocker haben gegenüber Add-ons wie uMatrix den Vorteil, anwenderfreundlicher zu sein. Sie benötigen weniger Wissen und auch weniger Pflege. Gleichzeitig kann man viele, aber nicht jeden Missbrauchsfall abdecken.
Generell können die Bugs weitere Anwendungsprogramme, die Code von Extern ausführen, betreffen.
Warum wird das gerade so durch die Presse gejagt?¶
Gute Frage nächste Frage. Mag zur Entstehung von Hypes jemand ein Paper schreiben?
Ein Grund dürfte aber sicherlich sein, dass es ein Hardware-Problem ist, das sich auch nicht komplett durch ein Microcode-Update beheben lässt, sondern auf höheren Ebenen (z.B. Betriebsystem) Updates benötigt. Zudem betrifft es eine riesige Menge an potenziellen Geräten – seien es ältere als auch verschiedene Geräteklassen (von Desktop über Server bis hin zu Smartphones und teils IoT).
Man muss sich aber auch klar sein, dass noch andere „interessante“ Lücken in Hardware bekannt sind: Sei es Intel Managment Engine oder die Äquivalente ähnlicher Hersteller. Auch Angriffe auf Hardware sind nicht neu, siehe zum Beispiel Rowhammer. Dadurch war es möglich, einzelne Bits im RAM zu flippen – und das auch per JavaScript im Browser. Glaubt man Bruce Schneier, wird das in Zukunft nicht unbedingt besser 🇬🇧.
Fazit¶
Klar kann man alle CPUs wegwerfen, um das Problem endgültig los zu werden. Allerdings gibt es aktuell keine wirkliche Alternative, weil alle großen CPU-Hersteller so ein bisschen betroffen sind. Durch die komplexen Entwicklungszyklen bei CPUs wird sich ebenso zeigen müssen, wie schnell sich das ändert. Hardware hat den schrecklichen Nachteil, dass man sie nicht so schnell und schön wie Software komplett austauschen kann. Deshalb muss man sich aktuell mit Softwarepatches der Hersteller zufrieden geben.
Zudem bleiben eigentlich nur die klassischen Regeln: Aktuelle (Ubuntu-)Version verwenden, Updates installieren und Rechner neu starten. Regelmäßig Backups machen – inklusive Einspielen testen. Wer fürchtet direkt oder über einen genutzten Webdienst betroffen zu sein, kann auch seine Passwörter ändern. Dafür kann man aber auch noch warten oder angekündigt nochmal machen, weil die Patches für Spectre sich noch in Entwicklung befinden.
Fehlt doch eigentlich nur noch ein XKCD?¶
Guck da isser 😉
 |
| New zero-day vulnerability: In addition to rowhammer, it turns out lots of servers are vulnerable to regular hammers, too. CC BY-NC 2.5 xkcd.com |
