Spectre und Meltdown

hustbaer schrieb:

Eh. Und? Ich denke du übersiehst hier den Umstand dass weder Meltdown noch Spectre Remote-Angriffe sind. D.h. der Angreifer muss sowieso schon Kontrolle über den Router haben. Und da man auf seinem Router normalerweise net so oft Zeugs installiert oder surft...

Nein, du übersiehst hier leider, dass man nur noch eine andere Sicherheitslücke als Sprungbrett benötigt und schon kann man Spectre ausnutzen um root Rechte zu erlangen.

Ich würde also einen Router, der für Spectre anfällig ist, als potentiell fatale Sicherheitslücke betrachten.
Es ist ja schon schlimm genug, dass die Desktoprechner davon betroffen sind und kaum mehr als ein Austausch der Hardware hilft.

Ich würde mich daher wesentlich wohler fühlen, wenn ich wüsste, dass mein AVM Router nicht davon betroffen ist.

Cisco hat beispielsweise schon diverse Router und Switches als anfällig für Spectre eingestuft:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel

AVM behauptet, nicht anfällig zu sein:
https://avm.de/service/aktuelle-sicherheitshinweise/

Allerdings lässt die Begründung einen faden Beigeschmack:

"Um die Schwachstellen auszunutzen, müsste ein Angreifer in der Lage sein, seine Anwendung auf dem AVM-Produkt zur Ausführung zu bringen. Anders als bei Systemen mit offener Architektur und Zugang zum Betriebssystem ist es für unsere Produkte prinzipiell nicht vorgesehen, Anwendungen Dritter auszuführen."

Denn es reicht ja wie schon gesagt nur eine andere Sicherheitslücke als Sprungbrett um dann mit Spectre noch mehr anzurichten.

Ich hatte noch keine Zeit die Papers zu Spectre zu lesen, aber wenn ich das richtig verstanden habe, dann ist das ein Angriffe, der nur das ausspionieren von Daten ermöglicht. Dies reicht aber schon um theoretisch das Root PW auszulesen und wenn man das hat, dann stehen einem praktisch Tür und Tor offen.

Es ist also die potentielle Verkettung der Nutzung von mehreren Sicherheitslücken, einschließlich Spectre, die das ganze in meinen Augen so gefährlich macht und dann betrifft es praktisch noch die gesamte Hardware der letzten 20 Jahre und kann nicht per Softwareupdate gefixt werden.

Der nationale US CERT Dienst hat die Gefahr daher meiner Meinung nach schon richtig eingestuft, man muss die gesamte, davon betroffene Hardware austauschen.
Das ist schlichtweg der Super-Gau.

Der Heartbleed Bug oder KRACK Angriff war da im Vergleich eine Kleinigkeit, da beides relativ schnell durch bessere Software behoben werden konnte, hier ist aber die gesamte IT Infrastruktur anfällig und bis neue, nicht anfällige Hardware zur Verfügung steht, kann es noch dauern.
Ich fühle mich also, bezüglich die Rechner in meinem LAN, mein Raspberry Pi 3 mal ausgenommen, als würde ich mit heruntergelassenen Hosen dastehen.

Also ich habe mal den von der TU Graz publizierten Spectre Mechanismus „Spectre Attacks: Exploiting Speculative Execution“auf einem WIN7 i5 Rechner ausprobiert und gefunden, dass es eben nur dann funktioniert, wenn sich das „secret“ in dem Programm-zugeordneten Speicherbereich befindet. Startet man ein zweites Program mit einem „secret“ und verwendet dessen Speicheradressen, dann funktioniert das Ganze schon nicht mehr. Gut ich habe jetzt den Code aus dem Paper as is verwendet und mich jetzt nicht noch selbst um dessen Optimierung bemüht- aber es wurde ja schließlich auch als Proof of Concept angepriesen.
Wenn es dem Mechanismus nicht gelingt, auf nicht freigegebenen Speicherbereich zuzugreifen, dann taugt das Ganze wohl auch nichts und riecht stark nach einem Hoax.

Zweifler schrieb:

Also ich habe mal den von der TU Graz publizierten Spectre Mechanismus „Spectre Attacks: Exploiting Speculative Execution“auf einem WIN7 i5 Rechner ausprobiert und gefunden, dass es eben nur dann funktioniert, wenn sich das „secret“ in dem Programm-zugeordneten Speicherbereich befindet. Startet man ein zweites Program mit einem „secret“ und verwendet dessen Speicheradressen, dann funktioniert das Ganze schon nicht mehr. Gut ich habe jetzt den Code aus dem Paper as is verwendet und mich jetzt nicht noch selbst um dessen Optimierung bemüht- aber es wurde ja schließlich auch als Proof of Concept angepriesen.
Wenn es dem Mechanismus nicht gelingt, auf nicht freigegebenen Speicherbereich zuzugreifen, dann taugt das Ganze wohl auch nichts und riecht stark nach einem Hoax.

Das was du vor hast sollte mit Meltdown funktionieren.
Mit Spectre kann man so wie ich das habe nur Speicher im gleichen Programm auslesen. Als in einem Browser kann ein Script auf Daten einer anderen Seite zugreifen, die du auch im selben Browser offen hast oder sowas.

Mechanics

computertrolls schrieb:

Nein, du übersiehst hier leider, dass man nur noch eine andere Sicherheitslücke als Sprungbrett benötigt und schon kann man Spectre ausnutzen um root Rechte zu erlangen.

Mochmal. Das ist bei einem AVM Router völlig irrelevant. Da bist du immer root, brauchst keine privilege escalation.
Und ganz so besonders ist es jetzt auch nicht. Privilege escalation Lücken gabs schon immer. Ist ja nicht so, dass deine Router dadurch jetzt erst in Gefahr wären.

Mechanics schrieb:

computertrolls schrieb:

Nein, du übersiehst hier leider, dass man nur noch eine andere Sicherheitslücke als Sprungbrett benötigt und schon kann man Spectre ausnutzen um root Rechte zu erlangen.

Mochmal. Das ist bei einem AVM Router völlig irrelevant. Da bist du immer root, brauchst keine privilege escalation.
Und ganz so besonders ist es jetzt auch nicht. Privilege escalation Lücken gabs schon immer. Ist ja nicht so, dass deine Router dadurch jetzt erst in Gefahr wären.

Arbeitest du bei AVM?

Oftmals wird bei vielen Herstellern irgendein FreeBSD, Minix oder sonstiges Mehrbenutzerfähiges OS installiert und diese lassen sich somit auch entsprechend einrichten und nutzen.
Das bedeutet also, das verschiedene Dienste, die auf dem Router laufen, unter verschiedenen Nutzerkonten laufen, entsprechend hat auch nicht alles immer root Rechte und das müssen auch keine Single User Betriebssysteme sein, bei denen alles root wäre.

Der Webserver, Druckerserver und Samba Dienst könnte bspw. jeweils unter seinem eigenen Account laufen ohne groß Nachteile zu bewirken und das erhöht wiederum die Sicherheit.

Früher habe ich einen alten 486er als Router verwendet und da hatte ich die Dienste auch gut getrennt.
Es wäre naiv anzunehmen, dass bei AVM alles im Single User Betrieb läuft.

Und auf meiner Fritzbox läuft mindestens ein Webserver, damit das Webinterface funktioniert, dann ein Druckerserver, damit man USB GUI Drucker an die Fritbox anschließen kann und ein Dateiserverdienst läuft ebenfalls, inkl. Mediaserverfunktion.
Ich bezweifle, dass sie alle mit root Rechten laufen. Gerade bei AVM könnte ich mir das nicht vorstellen, wenn das O2, Dlink oder Vodafone wäre, ok, da könnte das anders aussehen, aber AVM hat doch etwas mehr Ahnung von Sicherheit als die drei genannten.

Mechanics

Ich kenne AVM zugegebenermaßen nicht genauer. Früher (so vor über 10 Jahren) hab ich paar mal an solchen Routern rumgebastelt und mir ist zumindest keins untergekommen, das verschiedene Benutzer verwendet hätte.
So oder so, ich finde das einfach nicht dramatisch. Irgendeine Lücke, die man bei einem Router remote ausnutzen kann, finde ich viel schlimmer, als eine theoretische Möglichkeit von privilege escalation zu haben, die man danach vielleicht anwenden könnte.

hustbaer

computertrolls schrieb:

hustbaer schrieb:

Eh. Und? Ich denke du übersiehst hier den Umstand dass weder Meltdown noch Spectre Remote-Angriffe sind. D.h. der Angreifer muss sowieso schon Kontrolle über den Router haben. Und da man auf seinem Router normalerweise net so oft Zeugs installiert oder surft...

Nein, du übersiehst hier leider, dass man nur noch eine andere Sicherheitslücke als Sprungbrett benötigt und schon kann man Spectre ausnutzen um root Rechte zu erlangen.

Ich würde also einen Router, der für Spectre anfällig ist, als potentiell fatale Sicherheitslücke betrachten.

Du kannst als potentiell fatale Sicherheitslücke betrachten was du willst. Ich sehe es anders. Denn wie Mechanics schon geschrieben hat läuft auf nem Router normalerweise sowieso alles als root. Wenn da ein Remote-Angriff möglich ist, dann hast du sowieso verloren.

Aber selbst wenn ich annehme dass es nicht so wäre, wäre es für die meisten Heimanwender immer noch egal. Weil die keine vertraulichen Daten auf ihrem Router liegen haben. VPN Keys oder ähnliches wären ein Problem, hat Otto Normalverbraucher aber nicht. Und wie gesagt: das ist ne theoretisch Überlegung, weil wenn jmd. den Router von aussen knackt, dann ist die Kacke sowieso am Dampfen. Zumindest was den Router angeht. Wie viel schlimmer es dann noch wird hängt von der Sicherheit der Geräte ab die mit dem Router verbunden sind.

hustbaer

computertrolls schrieb:

Und auf meiner Fritzbox läuft mindestens ein Webserver, damit das Webinterface funktioniert, dann ein Druckerserver, damit man USB GUI Drucker an die Fritbox anschließen kann und ein Dateiserverdienst läuft ebenfalls, inkl. Mediaserverfunktion.
Ich bezweifle, dass sie alle mit root Rechten laufen.

Otto-Normalverbraucher hat keinen dieser Dienste von aussen erreichbar. Reinhacken könnte man sich also maximal über den TCP/IP Stack, und der läuft im Kernel-Mode.

Es gibt sicher Fälle wo Anwendungen die als normaler User laufen (oder sogar noch weiter eingeschränkt sind), wo Meltdown/Spectre dann ein Problem werden könnten, wenn die Anwendung selbst nen Expoit ermöglicht. Lässt sich aber einfach dadurch fixen dass man diese Anwendungen auf eine 2. Box verlagert. Was überall wo es wirklich um die Wurst geht allerdings sowieso schon so sein wird. Übrig bleibt ein prozentuell relativ kleiner Teil, nämlich Power-User/Enthusiasten/Bastler die irgend einen von aussen erreichbaren Dienst auf ihrem Router laufen lassen, weil sie so keinen eigenen Rechner dafür brauchen (der Geld kosten würde, Strom fressen würde etc.).

computertrolls schrieb:

Ich bezweifle, dass sie alle mit root Rechten laufen.

Probier es aus. Du kannst dich ja sicher per SSH auf deinen Router verbinden. Dann kannst du ja einfach checken mit welchen Accounts die jeweiligen Dienste laufen.

hustbaer

Mechanics schrieb:

So oder so, ich finde das einfach nicht dramatisch. Irgendeine Lücke, die man bei einem Router remote ausnutzen kann, finde ich viel schlimmer, als eine theoretische Möglichkeit von privilege escalation zu haben, die man danach vielleicht anwenden könnte.

Bei Routern sehe ich das auch so. Bei Desktops machen mir Privilege Escalation & Co. schon Angst.
Ganz speziell die "von Java-Script aus den Browser-Speicher auslesen" Sache.

hustbaer

andereAttacke schrieb:

Mit Spectre kann man so wie ich das habe nur Speicher im gleichen Programm auslesen. Als in einem Browser kann ein Script auf Daten einer anderen Seite zugreifen, die du auch im selben Browser offen hast oder sowas.

Nö, du kannst auch mit Spectre auf den Speicher anderer Programme zugreifen. Ist bloss viel schwieriger, und mit Java-Script vermutlich nicht durchführbar, zumindest nicht praktikabel. Wenn du allerdings ein anderes Programm genau analysiert hast und ganz gezielt eine .exe zusammenbasteln kannst um dieses andere Programm anzugreifen, dann kannst du mittels Spectre Techniken auch den Speicher dieses anderen Programms auslesen. Langsam und mühsam, aber es geht.

Zumindest wird das im Spectre Paper so beschrieben. In dem Beispiel werden dazu der Branch-Prediction Cache und Branch-Target-Buffer dazu gebracht dass sie bei einem indirekten Sprungbefehl der an Adresse X steht als Ziel Adresse Y vorhersagen.* Dazu muss der Angreifer in seinem eigenen Programm allerdings ebenfalls einen indirekten Sprungbefehl an Adresse X schreiben und mehrfach ausführen können - und idealerweise auch Code (z.B. ein einfaches "return") an Adresse Y.
D.h. er muss vorgegebene Maschinenbefehle an vorgegebene Adressen schreiben und dort ausführen können. Mit Java-Script bekommst du das nicht hin, da du die Adresse nicht kontrollieren kannst wo der JIT Compiler den Code hin generiert. (Auch das Erzeugen ganz bestimmter Befehlsfolgen wäre schwierig, aber je nach JIT Compiler wäre dieses Hindernis u.U. überwindbar.)

*: Das funktioniert bloss, weil der Branch Prediction Cache und Branch Target Buffer von allen Cores geteilt werden. MMn. wäre es also schonmal eine gute Massnahme gegen Cross-Process Spectre Angriffe diese pro Core zu machen. Oder alternativ den Key dieser Caches um einen zusätzlichen Wert zu erweitern (z.B. Core ID, Thread ID, Process ID, User ID - oder eine Kombination davon).
Dummerweise hilft das nicht gegen die Variante wo man über Java-Script den Speicher des Browser Prozesses ausliest.

Mechanics schrieb:

Ich kenne AVM zugegebenermaßen nicht genauer. Früher (so vor über 10 Jahren) hab ich paar mal an solchen Routern rumgebastelt und mir ist zumindest keins untergekommen, das verschiedene Benutzer verwendet hätte.
So oder so, ich finde das einfach nicht dramatisch. Irgendeine Lücke, die man bei einem Router remote ausnutzen kann, finde ich viel schlimmer, als eine theoretische Möglichkeit von privilege escalation zu haben, die man danach vielleicht anwenden könnte.

Der CERT vom BSI schreibt, dass die Sicherheitslücken CVE-2017-5715 (Spectre) und CVE-2017-5753 (Spectre) vermutlich von einem Angreifer im benachbarten Netzwerk ausgenutzt werden kann.
Damit wäre ein gegen diese Schwachstellen anfälliger Router direkt betroffen und für den gilt, dass das benachbarte Netzwerk auch das Internet selbst sein kann, schließlich hat er eine eigene öffentliche IP.

Leider darf man Ausschnitte aus CERT Meldungen nicht veröffentlichen, deswegen liest du am besten selber nach, in der Beschreibung steht es drin (Absätze haben die leider nur in der Meldung, die per E-Mail kommt):
https://www.cert-bund.de/advisoryshort/CB-K18-0010 UPDATE 1

hustbaer schrieb:

Probier es aus. Du kannst dich ja sicher per SSH auf deinen Router verbinden. Dann kannst du ja einfach checken mit welchen Accounts die jeweiligen Dienste laufen.

Meine (Kabel-) Fritzbox erlaubt keinen Zugriff via SSH.

Skynet kann jetzt dank Spectre und Meltdown richtig durchstarten.

Nachdem ich nun auch das Meltdown –Beispiel (nur für Linux) getestet habe, das merkwürdigerweise heute wohl nicht mehr auf github erreichbar ist, muss ich feststellen, dass dieses so nicht funktioniert. Vielleicht haben die Autoren es auch deshalb entfernt oder vielleicht habe ich die asm Routinen nicht richtig nach 32bit umgeschrieben – ich habe leider keinen 64bit Linux Testcomputer. Es gibt aktuell noch ein anderes github Projekt zum dem Thema - aber auch hier kommt der Autor selbst zu dem Ergebnis, das es so nicht funktioniert.
Sowohl das Original als auch die "Weiterentwicklung" lesen grundsätzlich nur Nullen aus und können auch nicht auf den Programm- zugewiesenen Speicher zugreifen. Es scheitert wohl an dem, was die Autoren auch schon als Problem identifiziert haben: „Need for Exception Suppression“.
Im Moment stellt sich mir die Frage: Was bleibt nun übrig von der ach so großen Sicherheitslücke ?

hustbaer

Das Auslesen von Speicher anderer Prozesse funktioniert mit Meltdown nur auf 64 Bit Kernels. Das Auslesen des Kernel Speichers sollte überall funktionieren.

Zweifler schrieb:

Was bleibt nun übrig von der ach so großen Sicherheitslücke ?

Weil du und 1-2 andere "Profis" es nicht hinbekommen haben funktioniert es nicht, hm? Na dann ist ja alles in Butter und Microsoft, Apple, Intel etc. waren alle bloss zu doof es auszuprobieren und haben Patches wegen nichts entwickelt.

Mechanics

computertrolls schrieb:

Der CERT vom BSI schreibt, dass die Sicherheitslücken CVE-2017-5715 (Spectre) und CVE-2017-5753 (Spectre) vermutlich von einem Angreifer im benachbarten Netzwerk ausgenutzt werden kann.
Damit wäre ein gegen diese Schwachstellen anfälliger Router direkt betroffen und für den gilt, dass das benachbarte Netzwerk auch das Internet selbst sein kann, schließlich hat er eine eigene öffentliche IP.

Irgendwie schaut deren Beschreibung nicht wirklich sinnvoll aus. Und oben steht in der Zusammenfassung ja auch, remote ausführbar - nein.

hustbaer

computertrolls schrieb:

Der CERT vom BSI schreibt, dass die Sicherheitslücken CVE-2017-5715 (Spectre) und CVE-2017-5753 (Spectre) vermutlich von einem Angreifer im benachbarten Netzwerk ausgenutzt werden kann.

Ja, tun sie.
In der Beschreibung zu https://nvd.nist.gov/vuln/detail/CVE-2017-5715 steht allerdings
Attack Vector (AV): Local

Und in der Beschreibung von https://nvd.nist.gov/vuln/detail/CVE-2017-5753 steht

Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

Ich würde also sagen die CERT Jungs haben Mist geschrieben.

Ist meine Vermutung richtig, dass es sicherer ist zum Surfen jetzt Chrome anstatt Firefox zu verwenden, weil Chrome im Gegensatz zu Firefox die einzelnen geöffneten Webseiten in getrennte Prozesse auslagert, was bei Firefox noch alles ein Prozess ist?

Denn immerhin kann mithilfe von Spectre unter Verwendung von JavaScript der Speicher des JavaScript Interpreters ausgelesen werden.
D.h. die Sicherheit wird also dadurch erhöht, in dem jede Webseite und der dafür zuständige JS Interpreter in einem eigenständigen Prozess läuft.
Damit wären die Webseiten voneinander ausreichend getrennt.

Ist das so richtig?

hustbaer

Bei der aktuellen Chrome Version musst du extra noch ein Setting aktivieren um gegen den JavaScript Angriff geschützt zu sein: \1://flags#enable-site-per-process
In der aktuellen Chrome Version (63) ist Default noch "disabled" - wird angeblich mit Version 64 auf "default=enabled" umgestellt.

Firefox löst das Problem anders, nämlich indem die Auflösung der High-Resolution Clock ( Performance.now ) künstlich beschnitten wird und das SharedArrayBuffer Feature (mit dem man sich in einem Worker-Thread eine eigene High-Resolution Clock nachbauen könnte) deaktiviert.
Diese Änderungen sind dafür bereits im aktuellen Firefox Release (Update 57.0.4) enthalten.

Was davon jetzt die sicherere Variante ist weiss ich nicht. *

Auf jeden Fall sollten die Browser-Hersteller mMn. zusehen dass so wenig wie möglich "problematische" Daten im Speicher von Prozessen stehen die auch Java-Script Code ausführen. Bzw. allgemein in jedem Prozess. Also z.B. auch gespeicherte Passwörter nur verschlüsselt vorhalten, und zwar so verschlüsselt dass der zum Entschlüsseln nötige Key nur im Kernel-Mode bekannt ist. Und nur kurzfristig entschlüsseln was gerade gebraucht wird, und danach sofort wieder überschreiben. (Oder gleich gar nicht im Speicher halten und nur jedes mal bei Bedarf aus dem File laden. Wobei das eingegebene Passwort muss im Speicher bleiben, sonst müsste man jedes mal das Master-Passwort neu eingeben. D.h. zumindest das eingegebene Passwort müsste irgendwie so verschlüsselt werden dass nur der Kernel es entschlüsseln kann.)

Ich kann nur hoffen dass zumindest das Firefox und das Chrome Team bereits daran arbeiten.

*: Wenn man annimmt dass die Änderungen die Firefox gemacht hat ausreichend sind, dann ist mir Firefox lieber, da diese Änderungen dann das Auslesen komplett verhindern anstatt nur zu versuchen so viel wie möglich Daten aus dem verwundbaren Prozess raus zu bekommen. Ideal wäre vermutlich beides. Wobei man SharedArrayBuffer ein Feature ist das man vermutlich sehr vermissen würde wenn es für ewig deaktiviert bleiben muss. Womit wir dann wieder bei der Chrome Variante landen würden.
Andrerseits könnte man vielleicht den JIT so anpassen dass er erkennt wenn ein JavaScript Worker-Thread immer wieder die selbe Speicherstelle in einem shared buffer überschreibt. Solche Threads massiv zu bremsen könnte vielleicht auch reichen.

hustbaer schrieb:

Firefox löst das Problem anders, nämlich indem die Auflösung der High-Resolution Clock ( Performance.now ) künstlich beschnitten wird und das SharedArrayBuffer Feature (mit dem man sich in einem Worker-Thread eine eigene High-Resolution Clock nachbauen könnte) deaktiviert.
Diese Änderungen sind dafür bereits im aktuellen Firefox Release (Update 57.0.4) enthalten.

Was davon jetzt die sicherere Variante ist weiss ich nicht. *

Der Firefox Fix ist mir bekannt. Das Problem bleibt bei dem aber, dass alle Passwörter aller Webseiten, die der Prozess ins RAM geladen hat, theoretisch im Adressraum des Prozess verfügbar sind.

Die Herabsetzung der Genauigkeit der Uhr löst das Problem also unter Umständen nicht gänzlich, sondern macht nur den Spectre Angriff schwieriger

Bei Chrome wäre das zur Webseite passende Passwort, in seinem jeweils eigenen Prozess und somit eigenem Adressraum.
Eine Webseite mit einer Javascript Malware, könnte somit nicht auf das Passwort von einer anderen Webseite zugreifen, weil die beide in unterschiedlichen Prozessen in ihrem jeweils eigenen Adressraum laufen.

Ein PW Diebstahl wäre hier also unmöglich, bei FF wäre er theoretisch noch möglich, falls der Angreifer mit der ungenauen Uhr trotzdem noch einen Weg findet den Spectre Angriff zu nutzen.
So wäre zumindest meine Überlegung zu dem Thema.