Meltdown und Spectre – Lehren aus dem Desaster? – II – Konsequenzen für Linux-User

Im letzten Artikel habe ich begonnen, Spectre und Meltdown zu kommentieren. Ich habe zudem Links zu relevanten Informationen im Internet aufgelistet. In diesem Beitrag will ich nun ein wenig darauf eingehen, was man im Moment als normaler Linux-User tun kann.

Ein normaler Linux-Anwender hat eher selten Server- oder Virtualisierungssysteme im Einsatz, die parallel von unterschiedlichen aktiven Usern genutzt werden. Er arbeitet eher als Einzelkämpfer auf einem PC/Notebook. Bedroht sind aber eben nicht nur Server, sondern eben jedes System mit halbwegs modernen Computerprozessoren – ob von Intel, AMD und auch diverse Prozessoren mit ARM-, POWER- und SPARC-Mikroarchitektur. Bedroht sind wir potentiell also alle!

Gute und schlechte Nachrichten für den normalen Linux-User

Es ist wichtig, sich als User klarzumachen, dass der Einsatz von Verschlüsselungsverfahren wie etwa PGP und Veracrypt einen nicht gegen Meltdown/Spectre schützt. Bei Nutzung solcher Tools liegen die entschlüsselten Daten ja irgendwann unverschlüsselt im Speicher vor – und gerade der wird angegriffen. Ähnliches gilt übrigens für die Passwortspeicher von Browsern.

Die zwei guten Nachrichten sind:

  • Das Ausnutzen aller drei bislang diskutierten Schwachstellen erfordert die Ausführung von Schadcode auf dem angegriffenen System. Der muss da erst mal hingelangen.
  • Meltdown lässt sich auf der Ebene der Betriebssysteme durch Kernel- also SW-Korrekturen (Patches) ausschließen. Das bedeutet gewisse Performance-Einbrüche, die aber alle noch in erträglicher Größenordnung liegen.

Die schlechten Nachrichten sind:

  • Meltdown-Angriffe können relativ leicht umgesetzt werden, eben auch aus Webseiten per Javascript heraus.
  • Glaubt man den Forschern, die zu Spectre publiziert haben, so kann man gegen ausgeklügelte Spectre-Angriffe nur Hindernisse aufbauen; sie aber womöglich nicht grundsätzlich unterbinden. Auch für Spectre gibt es übrigens Proof-Of-Concept-Szenarien für Angriffe auf Basis von Javascript und damit über das Web.
  • Ein wichtiger Gefahrenpunkt bzgl. von Angriffen aus dem Web sind Zugriffe auf seitenübergreifende Speicherinhalte des Browsers, z.B. von Passwort-Speichern. Beides wurde sowohl für Meltdown- als auch Spectre-Angriffsmuster demonstriert.
  • Bestimmte moderne Änderungen (KTPI, Retpoline) an Linux-Kerneln (in Kombination mit Microcode-Updates für die Prozessoren) sind noch nicht für LTS-Kernel umgesetzt worden – und können vermutlich auch nicht rückportiert werden.
  • Es wird noch dauern, bis neue Kernel in die üblichen Linux-Distributionen einfließen.
  • Gegen eine Variante von Spectre gibt es noch kein Heilmittel.

Konsequenzen- was kann man tun?

Die Konsequenzen für Anwender sind:

  • Kernel-Updates zum Schutz gegen Meltdown sind Pflicht. Dazu sind die SW-Repositories der jeweiligen Distribution abzufragen. Vor evtl. problematischen Linux-Kernel-Modifikationen zur Abwehr von Spectre-Angriffen (in Kombination mit Microcode_Updates für die Prozessoren) schützt uns hoffentlich die Kompetenz von Hrn. Torvalds und anderen Kernel-Spezialisten/Maitainer im Rahmen ihrer Qualitätskontrollen. Siehe hierzu: https://www.heise.de/newsticker/meldung/Absoluter-Muell-Linus-Torvalds-verliert-die-Geduld-mit-Spectre-Patches-3948756.html
  • Upgrades auf Kernelversionen, die von der eigenen Distribution und oder Treibern und Virtualisierungsanwendungen (noch) nicht unterstützt werden: Verfahren wie KPTI und Retpoline-
    Techniken sind nur in neueste Kernelversionen 4.14/4.15 – z.T. Vorabversionen – integriert. Ein normaler User ist beim Experimentieren mit solchen Kernels ggf. überfordert. Wer sich dennoch daran wagt und solche Kernels aus Repositories lädt, sollte sich vorab unbedingt darüber informieren, wie man den alten Kernel bootet und welche Versionen schon mit Grafikkartentreibern und Virtualisierungstools wie VMware kompatibel sind. Ansonsten ist man auf die Kernel-Updates der aktuellen Distributions-Repositories angewiesen. OpenSUSE-User sollten darauf achten, dass der Supportzeitraum für Leap 42.2 in Kürze endet!
  • Updates von Paketen mit Intel-Microcode, der Spectre-Angriffe erschwert, sind Pflicht – soweit solche Updates nicht die Stabilität der Systeme in Frage stellen. Leider kann das am 08.01.2018 publizierte Microcode-Update Instabilitäten verursachen. Siehe die Links am Ende der Seiten. Die Lage ist hier z.Z. unübersichtlich. SuSE und Red Hat haben z.B. die Intel-Microcode-Update-Pakete vom 08.01. wieder aus ihren Repositories entfernt. Im Moment liegt noch kein neueres Paket vor. Das Erscheinen neuerer Pakete für Microcode-Updates in den Repositories der Distributionen ist aber systematisch zu verfolgen.
  • Browser-Updates sind Pflicht. Die Browser-Hersteller können bestimmte Spectre-Varianten immerhin erschweren. Dazu zählt u.a. das Unterbinden von Funktionen zur hochauflösenden Zeitanalyse von Speicher-/Cache-Vorgängen.
  • Prävention: Noch mehr als zuvor ist darauf zu achten, von wo man sich Software einspielt. Deshalb sind https-Verbindungen statt http-Verbindungen zu Repository-Servern der jeweiligen Distributionen einzurichten. Für eingespielte Pakete sind die Hashes zu prüfen. Geübte Linux-Nutzer machen das sowieso; die Hash-Überprüfung nehmen einem meist Tools ab.
  • Prävention: Noch mehr als zuvor ist darauf zu achten, auf welche Webseiten man geht. NoScript-Plugins sollten im Browser im ersten Anlauf immer aktiv sein. Man sollte sich gut überlegen, für welche Domänen man Javascript oder andere Scriptsprachen überhaupt freigibt.
  • Prävention: Abschalten von Passwortspeichern in Browsern.
  • Prävention: Noch mehr als zuvor ist darauf zu achten, dass man sich nichts über E-Mail-Anhänge einfängt. Bei unbekannten Absendern oder “seltsamen” Inhalten immer zuerst den Header und seine Inhalte auf Inkonsistenzen überprüfen. IP-Adressen der Absender mit “whois” prüfen. Checken, ob im Internet zu Spams oder Malware für die Absender-IPs vorliegen. Eher mal zuviel löschen als irgendetwas in der Mail anzuklicken oder gar Anhänge zu öffnen.
  • Angesichts der Unsicherheiten, ob es bereits wirksame aber unentdeckte Angriffstools gab oder nicht, der Länge des Zeitraums seit Bekanntwerden der Schwachstellen (7 Monate) und der relativen Einfachheit von Meltdown-Angriffen, ist es auf exponierten Systemen sicher nicht verkehrt, mal alle Passwörter zu ändern.

Mehr Möglichkeiten hat der Linux-User zur Zeit wohl kaum. Im Kern also: Updaten, Repository-Änderungen für Kernel und Microcode-Pakete beobachten und ansonsten noch vorsichtiger mit Webseiten und E-Mails sein. Einige Punkte führen leider zu einer unbequemer Bedienung von Browsern und E-Mail-Programmen, aber potentieller Schaden und Nutzen sind eben abzuwägen. Wird ein Passwortspeicher ausgelesen, ist der Schaden immens.

Im nächsten Artikel gehe ich in allgemeiner Weise auf das Thema Browser und auch auf die Bedeutung von OpenSource im Kontext von Meltdown/Spectre ein.

Meltdown und Spectre – Lehren aus dem Desaster ? – I – Die letzte Warnung

Als WannaCry und SambaCry 2017 die IT-Welt in Aufruhr versetzten, wurde ein paar fundamentale Dilemmata IT-gestützter Informationsgesellschaften deutlich:

  • Hardware und Software sind nie fehlerfrei – auch OpenSource Software nicht.
  • Es kann fundamentale, hochkritische Fehler geben, die von interessierten Kreisen über entsprechende Schadcodes lange Zeit genutzt werden, ohne dass die Schwachstellen öffentlich gemacht würden.
  • Auch staatliche “Sicherheits”-Organe sind gegen das Abgreifen von selbst entwickelten Angriffsverfahren durch kriminelle Organisationen und feindliche Staaten nicht zu 100% gefeit. Der Staat als (ggf. durch ein Parlament legitimierter) Hacker ist daher nicht nur als Schutzfaktor, sondern auch als ungewollte indirekte Gefahrenquelle zu begreifen.
  • Es kann Schwachstellen geben, die über hinreichend intelligent gestrickte Angriffs-Software und gesteuerte Angriffswellen über BOT-Netze innerhalb kürzester Zeit zu einer weltweiten Bedrohung werden können – und zwar auch für die sensiblen Infrastrukturen von Industriestaaten.
  • Es ist ein gigantischer Fehler, von wenigen HW-Produzenten und Betriebssystem-Herstellern abhängig zu sein – und im Ernstfall keine Alternativen zu haben. In diesem Sinne sind wir in Westeuropa fast alle abhängig von der IT-Supermacht USA. Das beklagte zuletzt ja sogar unser amtierender Außenminister auf der DLD-Konferenz.

Meltdown/Spectre verschärfen alle diese Punkte – und lassen sie im Sinne einer globalen Verwundbarkeit von uns allen in neuem Licht erscheinen. Nun haben wir also noch eine ganze Weile mit Meltdown/Spectre zu leben. Der Unterschied ist diesmal: Fast alle gängigen IT-Systeme sind angreifbar, da die Schwachstellen in den Prozessoren selbst stecken. SW-Updates werden möglicherweise nur begrenzt helfen; z.Z. gibt es noch kein Heilmittel gegen bestimmte Varianten von Angriffen nach dem Spectre-Muster. Die Nerven der Beteiligten liegen deshalb auch auf der Linux-Seite blank – siehe
https://www.heise.de/newsticker/meldung/Absoluter-Muell-Linus-Torvalds-verliert-die-Geduld-mit-Spectre-Patches-3948756.html.

Ich behaupte deshalb mal: Meltdown/Spectre sind – genau wie WannaCry eine Art letzter Warnung, die erneut verdeutlicht auf welch dünnem Eis unsere modernen Gesellschaften leben – nicht zuletzt auch durch bestehende Abhängigkeiten von einigen wenigen IT-Monopolisten.

Jeder, der sich einmal mit der Abhängigkeit moderner Industrie- und Informationsgesellschaften wie Deutschland von funktionierender IT auseinandergesetzt hat, weiß, dass wir extrem verwundbar sind: Ein dauerhafter Zusammenbruch grundlegender und infrastrukturell relevanter IT-Netzwerke und -Systeme würde uns in kürzester Zeit in wahrhaft katastrophale Zustände katapultieren.

Zeit für ein paar Gedanken zu möglichen Lehren aus dem aktuellen Desaster, die in der aktuellen Debatte weniger angesprochen werden …. Weniger technik-affine Leser, die sich erst in die Thematik einarbeiten wollen oder müssen, seien auf die Links weiter unten verwiesen.

Ich teile meine Kommentare in mehrere Beiträge auf, da mich einige Bekannte (Linux-Nutzer) vor kurzem auch gefragt haben, was sie den nun konkret tun sollten.

Schwachstellen und Angriffsverfahren

Meltdown und Spectre stellen bislang Angriffsmuster dar und noch (!?) keinen vollständigen, massenhaft einsetzbaren Schadcode. Sie beruhen nach dem, was ich dazu gelesen habe, auf zwei Aspekten moderner Prozessoren, die in ihrer Kombination zu angreifbaren Schwachstellen führen:

  • Das spekulative Ausführen von Programm-Code auf Basis von
    Heuristiken, bevor das Ergebnis solcher Code-Fragmente in der Ausführung einer Anwendung faktisch benötigt wird. Die Bevorratung der Ergebnisse derartiger “transienter Instruktionen” dient der Performance praktisch aller moderner Computer-Prozessoren. Bei der spekulativen Code-Ausführung wird z.Z. auf verschiedenen Prozessortypen nicht hinreichend geprüft, ob in einem bestimmten Ausführungskontext hinreichende Berechtigungen vorliegen.
  • Seiteneffekte beim Einlagern von (vorausberechneten) Daten in Prozessor-Caches, die erstens erkennen lassen, ob die Daten einer spekulativen Codeausführung entstammen und die in Kombination mit bestimmten, schon länger bekannten Verfahren den ungehinderten Zugriff auf solche Daten auch durch unberechtigte Prozesse/Programme ermöglichen. Durch geschickte Manipulationen der spekulativen Codeausführung kann man das Exception-Handling beeinflussen und über den Cache systematisch auf ganze Speicherbereiche mit hinreichender Geschwindigkeit zugreifen.

Wie genau diese Effekte ausgenutzt werden können, ist u.a. von der Prozessorarchitektur und der Art der Caching-Seiteneffekte abhängig. Bei Meltdown greift man dabei den eigenen Speicherbereich an, in den allerdings auch globale Speicherinhalte eingeblendet sind, die normalerweise nur in bestimmten Prozessormodes und nicht direkt durch einen unberechtigten User-Prozess ausgelesen werden können – wohl aber im Rahmen der spekulativen Ausführung von Codefragmenten.
Meltdown betrifft Intel-Prozessoren.

Bei Spectre werden Speicherbereiche fremder Prozesskontexte (anderer User) angegriffen. Für Spectre-basierte Angriffe sind intime Kenntnisse von Anwendungen und auch des Betriebssystems erforderlich. Das spekulative Verhalten des Prozessors wird dabei vorab auf bestimmte Annahmen hin “trainiert”. Spectre betrifft (zumindest in einer Variante) sehr viele Prozessortypen unterschiedlicher Hersteller.

Die Zugriffsverfahren auf Prozessor-Cache-Inhalte über Seitenaspekte (und z.B. Zeitanalysen) wurden bereits seit mehreren Jahren erforscht. Dass das Zusammenspiel mit spekulativer Codeausführung erst jetzt als fundamentaler Gefahrenpunkt erkannt wurde, mutet etwas seltsam an und offenbart im besten Fall die Blickfeldeinschränkung, von der auch Sicherheitsexperten nicht verschont bleiben, wenn sie sich auf ein spezielles Problem konzentrieren. Über den schlechteren Fall mag ich gar nicht nachdenken … In jedem Fall scheint zu gelten: Professionell durchgeführte Angriffe auf Basis der Schwachstellen würden kaum Spuren in den betroffenen Systemen hinterlassen.

Nun wurden die Schwachstellen, die seit vielen Jahren existieren, im Juni letzten Jahres publiziert und kommuniziert. Seitdem sind 7 Monate vergangen. Auch das ist ein erheblicher Zeitraum. Die schlimmsten Schwachstellen und Bedrohungen sind diejenigen, die wir nicht mal erkannt haben. Im Moment wurden wir uns nur der Schwachpunkte und Gefahren bewusst; ob sie nicht bereits ausgenutzt wurden, kann niemand sagen.

Angriffe?

Aus meiner Sicht haben die Teams, die die Schwachstellen entdeckt bzw. untersucht haben, bereits relativ detailliert aufgezeigt, wie und aus welchen Angriffswinkeln heraus man Angriffstools konstruieren muss. Gegen Meltdown in Intel-Prozessoren können Kernelmodifikationen der Betriebssysteme schützen. Das ist für relevante aktuelle und LTS-Linux-Kernel bereits der Fall. Spectre-Angriffe sind dagegen komplex, weil sie zielgerichtet und betriebssystem-spezifisch ausgelegt werden müssen. Andererseits ist die Verteidigung gegen Spectre wirklich komplex – und erfordert absehbar das Zusammenwirken von Microcode-Änderungen für die Prozessoren und neuen Kernel-Features (Stichworte: KPTI + Retpoline).

Aber auch dann ist aber sehr fraglich, ob alle denkbaren Seitenkanalvarianten, die in der Original-Publikation zu Spectre angesprochen wurden, abgedeckt werden können. Die Experten, die die Schwachstellen publizierten, sind da eher skeptisch.
Seiteneffekte, die sich durch eine zeitlich hochauflösende Analyse von Speicher/Cache-Vorgängen nutzen lassen, stellen nur einen Teil des möglichen Spektrums dar. Hierfür gibt es allerdings seit längerem sehr ausgereifte Tools.

Genau das Richtige also für ambitiöse Hacker … Das lässt nichts Gutes für den weiteren Verlauf des Jahres erahnen, da potentiell extrem viele Systeme betroffen sind.

Im nächsten Beitrag gehe ich auf Konsequenzen für normale Linux-Nutzer ein.

Links

Wo finde ich verständliche Informationen?
Nachfolgend ein paar Links, deren Inhalte aus meiner Sicht auch für Nicht-IT-Spezialisten verdaubar sind. In etwa geordnet nach steigendem Schwierigkeitsgrad.
http://www.sueddeutsche.de/digital/meltdown-und-spectre-chip-sicherheitsluecke-alle-sind-betroffen-1.3814322
https://www.heise.de/newsticker/meldung/FAQ-zu-Meltdown-und-Spectre-Was-ist-passiert-bin-ich-betroffen-wie-kann-ich-mich-schuetzen-3938146.html
https://www.heise.de/ct/ausgabe/2018-3-Sicherheitsluecken-in-den-meisten-modernen-Prozessoren-3942720.html
https://www.schneier.com/blog/archives/2018/01/spectre-_and-_mel-_1.html
https://solutionsreview.com/security-information-event-management/living-spectre-fallout-meltdown-spectre/
https://www.theregister.co.uk/2018/01/12/meltdown-_spectre-_researchers-_sitrep/
http://www.crn.de/software-services/artikel-115987.html
https://www.heise.de/newsticker/meldung/Analyse-zur-Prozessorluecke-Meltdown-und-Spectre-sind-ein-Security-Supergau-3935124.html
https://www.golem.de/news/updates-wie-man-spectre-und-meltdown-loswird-1801-132125.html

Movies
https://twitter.com/misc0110
https://www.youtube.com/watch?v=I5mRwzVvFGE

Interviews / History
https://www.golem.de/news/meltdown-und-spectre-dann-sind-wir-performancemaessig-wieder-am-ende-der-90er-1801-132224.html
https://www.gdata.de/blog/2018/01/30334-meltdown-spectre-interview-mit-anders-fogh
https://solutionsreview.com/security-information-event-management/dr-eric-cole-discusses-meltdown-spectre/
https://www.bloomberg.com/news/articles/2018-01-08/-it-can-t-be-true-inside-the-semiconductor-industry-s-meltdown
https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-
discovery/

https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/
https://www.theverge.com/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
https://www.riskbasedsecurity.com/2018/01/the-slow-burn-of-meltdown-and-spectre-exploits-lawsuits-and-perspective/

Original-Publikationen (für IT-Freaks wirklich lesenswert)
https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Linux/QEMU – Schutzverfahren ?
http://kroah.com/log/blog/2018/01/06/meltdown-status/
http://kroah.com/log/blog/2018/01/19/meltdown-status-2/
https://www.heise.de/ct/ausgabe/2018-3-Wie-die-Linux-Welt-auf-Meltdown-Spectre-reagiert-3942819.html
https://de.wikipedia.org/wiki/Kernel_page-table_isolation
https://www.cyberciti.biz/faq/check-linux-server-for-spectre-meltdown-vulnerability/
https://fedoramagazine.org/update-ongoing-meltdown-spectre-work/
https://www.pro-linux.de/news/1/25515/meltdown-und-spectre-weitere-kernelaktualisierungen.html
https://www.suse.com/de-de/support/kb/doc/?id=7022512
http://www.linux-magazin.de/news/meltdown-und-spectre-update-von-kernel-entwickler-kroah-hartman/
https://www.qemu.org/2018/01/04/spectre/
https://lwn.net/Articles/744287/

Warnung vor den Intel-Microcode Updates vom 08.01.
https://thehackernews.com/2018/01/intel-meltdown-spectre-patch.html
https://www.suse.com/de-de/support/kb/doc/?id=7022512https://www.theregister.co.uk/2018/01/18/red_hat_spectre_firmware_update_woes/