staging.inyokaproject.org

Meltdown und Spectre

linux.png

Spectre und Meltdown wurden durch die Massenmedien weltweit bekannt, dabei ist meist nicht wirklich klar, was sie genau für Auswirkungen haben. Ein Versuch einen groben Überblick über die verzwickte aktuelle Lage zu geben.

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.

meltdown.png

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.

spectre.png

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 😉

xkcd_1938-meltdown_and_spectre.png
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

Veröffentlicht von chris34 | 8. Januar 2018 22:30 | Kategorie: Rund um Ubuntu | # Fehler im Artikel melden

user32847

1 9. Januar 2018 08:32

Danke für den Beitrag, sehr gut gelungen und das wesentliche auf den Punkt gebracht! Gerne öfter sowas. ☺

Tronde

Avatar von Tronde
2 9. Januar 2018 12:16

Danke für den tollen Artikel. 👍

lama4linux

Avatar von lama4linux
3 10. Januar 2018 08:51

Danke für den Überblick.

andy.ka

4 10. Januar 2018 16:22

Danke; prima Artikel,

mir -als Laien- stellt sich nun die Frage Fehler oder Hintertürchen...

putzerstammer

Avatar von putzerstammer
5 10. Januar 2018 17:29

Danke für den Artikel 👍 und ein besseres Fazit kann man auch nicht machen

gnude

Avatar von gnude
6 10. Januar 2018 18:35

Ich finde den auch super

DPITTI

Avatar von DPITTI
7 10. Januar 2018 20:28

Danke auch von mir an den Schreiberling.

tomtomtom

Supporter

Avatar von tomtomtom
8 10. Januar 2018 21:13

@4: Das ist selbstredend eine Backdoor. Hat die NSA 1995 implementieren lassen, für den Fall, dass sich dieses "Neuland" tatsächlich Mal durchsetzen sollte.

#CyberCyberCyber-TheEndIsNear

ubulinux

9 10. Januar 2018 22:07

@tomtomtom,

endlich mal einer der das Kind beim Namen nennt. In den anderen Foren redet man da wie Katze um den heißen Brei z.B. Design-Fehler und als Behandlung--Placebo-forte--Kernel 4.13.0-26-generic.Na ja,Glaube versetzt auch Berge.

DPITTI

Avatar von DPITTI
10 11. Januar 2018 21:03

@9 Man muss ja auch nicht alles glauben was in Foren so geredet wird. Habe heute zwei Foren den Rücken gekehrt. Die sagt man wenn es nicht mehr passt muss man freiwillig gehen. Das dazu weitermachen.

bergerjunge

Avatar von bergerjunge
11 11. Januar 2018 21:27

Zunächst mal vielen Dank für die tolle Zusammenfassung.

Wie nach Googlesuche zu diesem Thema zu lesen war soll Asus ja schon BIOS - Updates für einige Mainboards angeboten haben. Ich habe allerdings auf deren Website kein Wort von Meltdown oder Spectre gefunden. Ob eine Biosversion nun ein Update enthält oder nicht muß man warscheinlich erraten.

Als nicht so kundiger User ist man mit einem Biosupdate sowieso schon schnell überfordert, und wenn dann Hersteller keine Infos geben frage ich mich wie sollen solche Rechner gepatcht werden. 😬

DPITTI

Avatar von DPITTI
12 11. Januar 2018 22:16

@11 Stellst im Forum hier einfach ein Thread. Dann wird RS User geben die helfen schon. Also bei älteren Asus Mainboards gibt es Asus Flash was Extra zum Flashen des BIOS gedacht ist. Man muss halt nur die genaue Bezeichnung sollte es ein fertig Pc sein reicht schon die Model Nummer. Oder schreibt den Support des Hersteller an bist in jeden Fall auf der sichere Seite.

chris34

Ikhaya- und Webteam

13 11. Januar 2018 22:43

@11:

Ich habe allerdings auf deren Website kein Wort von Meltdown oder Spectre gefunden. Ob eine Biosversion nun ein Update enthält oder nicht muß man warscheinlich erraten.

Ok, dann gehen wir wieder zurück zu Linkübersichen statt Suchmaschinen: Über diese heise Übersicht komm ich auf diese Asus-Seite mit Infos 🇬🇧. Die Überschrift enthält mit „Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method“ so ein paar Buzzwords 😉 Die Tabelle bei Asus sollte ansonsten selbsterklärend sein.

Alternative zum Firmware-Update (sollte es keins geben oder wg. kompletter Serverfarm zu aufwändig sein z.B.) ist übrigens ein Mikrocode-Update. Das liegt in den Repos und wird dann beim Booten von Linux „eingespielt“. Hier kommt es dann auf das verwendet CPU-Modell drauf an.

Neue Firmware/Mikrocode allein wird btw. nicht reichen, da braucht es in diesem Fall auch noch mal ein Kernelupdate, was dann auch die Änderungen nutzt. (steht auch so in der Ubuntu Security Notice)

Gaianer

14 12. Januar 2018 14:34

Danke und großes Lob für diesen hervorragenden und lesenswerten Artikel.

SinoPhil

15 13. Januar 2018 10:31

Vielen Dank für den sehr informativen und ausführlichen Artikel.

@13:

In dem Zusammenhang habe ich noch eine Verständnisfrage: so wie ich das verstehe, findet das Mikrocode-Update dann auf Betriebssystem-Ebene ab, richtig? D.h., falls ich ein Dual- oder Multiboot-System nutze, werde ich dieses Mikrocode-Update (im Idealfall..☹ ) mehrmals erhalten, für jedes meiner Betriebssysteme. Ebenso müsste das Mikrocode-Update bei einer Neuinstallation des Betriebssystems von neuem wieder eingespielt werden (im Gegensatz zum Firmware-Update), ist das korrekt?

encbladexp

Ehemaliger

Avatar von encbladexp
16 13. Januar 2018 12:17

@15: Microcode wird entweder per BIOS/UEFI geladen oder vom Betriebssystem beim booten. Also ja, das macht idr jedes Betriebssystem für sich, da es nicht permanent in der CPU ist.

mfg Stefan