Eines der aus meiner Sicht hohen Gefährdungspotentiale von Spectre lässt sich womöglich daran festmachen, dass zumindest in der Theorie Angriffe auch mit Hilfe von Javascript geführt werden können. Es lohnt sich an dieser Stelle deshalb, ein wenig über Browser im Lichte von Spectre nachzudenken. Ich ergänze diesen Beitrag zudem durch ein paar Überlegungen zu Open Source im Kontext der neuen Bedrohungen.

Der Browser als Einfallstor – nicht erst seit Meltdown/Spectre

Sehr “schön” ist in diesem Zusammenhang die Seite 13 in https://meltdownattack.com/meltdown.pdf, in der gezeigt wird, wie Passwörter aus dem Firefox-Passwortspeicher ausgelesen werden können. Es gibt dazu auch ein nettes Video. Zugriffe auf Passwortspeicher sind allerdings auch mit Angriffsmustern gemäß Spectre möglich. Zwar kann man Cache-Analysen wie in den Originalveröffentlichungen diskutiert, womöglich von Seiten der Browser-Hersteller unterbinden. Man darf gespannt sein, wann die Barrieren für spezifischen Seitenkanal-Angriffsvariante, die genaue Zeitmessungen erfordern, durch Ausnutzen anderer Seitenkanalwirkungen des Prozessor-Cachings umschifft werden können. Die aktuelle Ausgangslage verspricht jedenfalls ein lustiges Jahr 2018 …

Das Angreifen von Browser-Subprozessen, zu denen Javascript-Programme keinen Zugang erhalten dürfen, ist an sich schon eine kritische Sache. Globaler betrachtet offenbart sich durch Meltdown/Spectre aber nur einmal mehr, dass die Anwendung “Browser” ein Angriffstor mit potentieller Tiefenwirkung für alle Betriebssysteme darstellen:

Aus Security-Perspektive sind Browser eigentlich als Anwendungen zu betrachten, die sich jederzeit in Schadcode-Implantations-Zentren verwandeln können.

Konnte man sich als Linuxer auf PCs bislang gegen landläufige Angriffsvektoren im Kontext von Browsern dadurch schützen, dass man Browser-Applikation dediziert in Containern oder besser noch virtuellen Maschinen unter KVM laufen ließ, so werden solche Konzepte durch die Prozessor-Schwachstellen ausgehebelt. Das gilt analog für Chrome/Chromium, die die Browserprozesse in separate Namespaces des Linux-Systems einbetten – und damit eine ähnliche Isolation wie Container erreichen.

Wenn aber selbst die Isolierung von Browsern unter Linux in eigenen Namespaces (s. Google) oder Containern aufgrund von kommenden Spectre-Angriffen nicht mehr hinreichend sein wird, um andere Systemprozesse und deren Datenkontexte zu schützen – tja, was dann?

Ursachen der Javascript-Misere

Eine interessante Frage ist zudem: Wem oder was haben wir eigentlich diese Misere von Angriffspfaden über Browser und Javascript zu verdanken?

Wenn man ehrlich ist, ist für viele Webseiten Javascript gar nicht zwingend erforderlich. Trotzdem wird es im Übermaß eingesetzt. Das liegt u.a. daran, dass sich viele Probleme leichter mit JS als mit CSS-Tricks lösen lassen. Nun wäre das nicht so schlimm, wenn sich das JS-Angebot auf das für die Funktionalität einer Seite Notwendige beschränken würde und die JS-Codes aus einer Quelle stammen würden. Das ist aber wegen der in viele Webseiten integrierten Werbung heute nicht mehr der Fall; s.u.. Zudem lässt leider auch das W3C immer JS-Funktionen zu, die potentiell problematisch werden können.

Ins Feld geführt wird regelmäßig auch ein Performance-Aspekt: Interaktionen des Users mit Webseiten sollen nicht zu einem Nachladen neuer (ggf. auf Servern per Script generierter) HTML-Seiten führen, sondern im Browser selbst abgehandelt werden. Hätten wir Gigabit-Netz, wäre dieses Argument nicht unbedingt schlagend. So aber sind Nutzer für viele Seiten tatsächlich gezwungen, Javascript anzuschalten.

Eine andere Ursache ist die Werbeindustrie mit ihren Tracking-Verfahren. Auf vielen Seiten sind die Quellen von integrierten JS-Codes von Dritt- und Viert-
Firmen zur Analyse des Nutzerverhaltens derart unübersichtlich verteilt, dass man die betreffenden Seiten am besten gleich wieder schließt. Eien Analyse aller integrierten Codes ist in der Praxis unmöglich. AdBlocker helfen auch da nur bedingt.

Zudem ist der normale Nutzer im Westen ist inzwischen so stark an “kostenfreie” SW gewöhnt worden, dass er alle potentiellen Gefahren ignoriert. Zu was das am Smartphone führt sieht man ja bei der Installation vieler APPs und den dafür angeforderten Zugriffsrechten auf Speicher, Kontaktverwaltung und Kalender sowie Devices (Kamera, GPS, Mikrophon, …) – die Sicherheit bleibt dabei auf der Strecke. Die meisten Benutzern erlauben ihren ach so geliebten Apps den Zugriff auf fast alle Devices und Daten. So gibt es inzwischen denn auch Browser-Plugins, die auf diverse Elemente eines PCs (wie etwa den Desktop) zugreifen können … Eine Todsünde …

Ein weiterer wichtiger Grund ist aber auch der gottverdammte Cloud-Gedanke:
Applikationen und deren Daten sollen aus dem Internet von Provider-Servern geladen und lokal in Browsern mit maximaler Funktionalität ausgeführt werden – angeblich zum Komfort des Nutzers. Beispiel: Browserbasierte Office-Anwendungen. Der laufende Datenaustausch mit Cloud-Speichern erfordert dabei Ajax-Technologien und damit Javascript zwingend. Schöne neue Welt …

Es ist klar, dass diese Entwicklungen zusammen immer mehr ausführbaren Code im Browser erfordern – und dass solcher Code auch immer mehr Möglichkeiten und ggf. Rechte zur Manipulation lokaler Speicherinhalte bekommen muss.

Diese Entwicklungen werden in Kombination mit den nun bekannten Schwachstellen von Prozessoren zu einer immensen Gefahr. Staaten wie z.B. China zeigen bereits unverblümt, was sie mit den aktuellen technischen Möglichkeiten erreichen wollen: Die Kontrolle der eigenen Bürger. Warum das nicht auch auf Nutzer von APPs bzw. Webseiten, die im Auftrag von kontrollierten Firmen im Westen erstellt werden, ausweiten? Spectre liefert interessierten staatlichen Organisationen mit hinreichenden Ressourcen ganz neue Angriffspunkte, um Informationen über uns alle zu sammeln … Das Schlimme ist, dass es bis zu einer neuen Prozessorgeneration noch kein zuverlässiger Schutz absehbar ist. Die Geister, die wir alle in unserer Gier, laufend und in allen Lebensbereichen “online” zu sein, gerufen haben, sie wenden sich nun gegen uns. Wir sollten alle beginnen, völlig neu über unsere Nutzung des Internets nachzudenken.

Open Source – Chance oder Gefahrenquelle im Spectre-Kontext?

In einem früheren Beitrag hatte ich erwähnt, dass das Umsetzen von Spectre in massenhaft nutzbare Angriffsformen die intime Kenntnis von Anwendungen und Betriebssystemen verlangt – sowie natürlich hinreichende Entwicklerkapazität mit diesen Kenntnissen. Wo ist das am meisten gegeben? Bei den Herstellern von Anwendungen und Betriebssystemen, aber natürlich auch bei staatlichen Organisationen.

Nun könnte man argumentieren, dass gerade Open Source hier ein Nachteil sei. Das Argument ist mir in Diskussionen tatsächlich schon begegnet: Schließlich eröffne ja gerade die Offenlegung der Betriebssystem- und der Anwendungscodes Hackern die Möglichkeit, sich tief einzuarbeiten und passende Code-Segmente für transiente Codeblöcke in Spectre-Angriffen auszuwählen. Stimmt – das Ausnutzen von Schwachstellen in Open Source Anwendungscode ist tatsächlich auch unabhängig von Spectre schon passiert. Aber:

Das vorgebrachte Argument gilt natürlich noch viel mehr für die Hersteller proprietärer Software und Betriebssysteme. Die dortigen Entwickler müssen sich ja gar nicht mehr einarbeiten – die kennen ihre Umgebung ja schon! Und wir als Benutzer haben bei proprietärem Code keine Chance nachzuprüfen, ob die Hersteller oder evtl. korrupte Mitarbeiter solcher Unternehmen durch Elemente ihrer Betriebssystem- oder Anwendungs-SW künftig nicht gezielt globale Schwachstellen wie Spectre ausnutzen (werden) – zu welchem Zweck auch immer.
Es gibt keine wirkliche Verteidigung dagegen.

Aus den Forschungsergebnissen zu Meltdown/Spectre wird zudem klar, dass Spectre-basierte Angriffe so gut wie keine Spuren im angegriffenen System hinterlassen würden. Ein Eldorado für hinreichend skrupellose Ersteller proprietären Codes.

Aus diesen Gründen ist eine essentielle Konsequenz aus den Erkenntnissen zu Spectre und Meltdown:

Ein Umsteigen auf Open Source-Systeme ist mehr denn je notwendig! Für Privatpersonen, Unternehmen, aber auch Institutionen der öffentlichen Verwaltung.

Dieses Argument gilt dabei in ganz besonderem Maße für die öffentliche Verwaltung, die immer im Interesse der Bürger (hier Datenschutz und Datensicherheit) handeln sollte. Spectre und Meltdown lassen deshalb die Entscheidung der Stadt München, künftig auf proprietäre SW zu setzen, nicht nur unter Kosten- und Abhängigkeitsgesichtspunkten als grundfalsch erscheinen. Diese Entscheidung ist vor allem unter dem Aspekt der Sicherheit in Frage zu stellen. Gerade dann, wenn die Stadt – wie seit Jahren bekundet – verstärkt auf E-Government setzen will.

An dieser Stelle sei abschließend auf folgende Artikel verwiesen, der das Thema Datenschutz und Microsoft noch unter einem ganz anderen Gesichtspunkt beleuchtet:
http://www.handelsblatt.com/politik/international/datenschutz-in-gefahr-ende-des-internets-wie-wir-es-heute-kennen/20876998.html

Man kombiniere das dort Beschriebene einmal mit den Möglichkeiten von Spectre. Das alles ficht aber wohl die Mitglieder des Stadtrates nicht an. Die Mitarbeiter eines Beratungsunternehmens mit Hauptsitz in Dublin, welches nicht für Linux-Affinität bekannt ist, und vor allem die Chefs eines Betriebssystemherstellers aus Übersee können sich dagegen ein paar Sektgläser füllen und sich gratulieren. Ein neuer Trinkspruch von IT-lern soll ja sein: Prosit Meltdown …

Nebenbei: Besagtes Beratungsunternehmen hat seit letztem Jahr auch die Aktienmehrheit beim größten deutschen Internetdienstleister erworben. Ein Schelm, wer da anfängt, über künftige Outsourcing-Möglichkeiten zu spekulieren …

Im nächsten Beitrag wende ich mich weiterem Fallout von Spectre/Meltdown zu – nämlich Servern, Virtualisierung und wiederum Cloud-Diensten.

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.