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.