Tor-Browser-Exploit verrät Nutzer-IP-Adresse


Filippo Cavallarin, Chef der Sicherheitsfirma We Are Segment, hat bereits am 26. Oktober auf eine von ihm entdeckte Schwachstelle im Tor-Browser hingewiesen, die unter bestimmten Umständen Nutzer enttarnen kann. Betroffen sind nur Mac und Linux-Versionen des Firefox-Bundles, ein Fix steht bereits zum Download bereit.



Die TorMoil (Anspielung auf Englisch turmoil: Aufruhr) genannte Lücke befindet sich in den Mac- und Linux-Versionen des Tor-Browsers. Die aktuellen Versionen des Tor-Browsers für Linux und macOS weisen einen Fehler auf, wodurch die Anonymisierung ausgehebelt wird und zwar genau dann, wenn Nutzer eine Adresse mit dem Präfix file:// aufrufen und nicht, wie gewöhnlich mit http:// oder



Das Problem entsteht dadurch, wie der Firefox-Browser, auf dessen Grundlage der Tor-Browser basiert, diese Art Links öffnet. Die betroffenen Betriebssysteme versuchen dabei offenbar die Adresse am Tor-Browser vorbei zu öffnen. In Kombination mit den betroffenen Betriebssystemen kann dann der beschriebene Fehler auftreten. Dabei wird die echte IP-Adresse des Nutzers übertragen und er so enttarnt. Die Windows-Version des Tor-Browsers ist nicht davon betroffen.

Bisher wurde am 04.11.2017 zur Verfügung gestellt, bei der man das Problem behoben hat. Jedoch funktionieren bei diesem Update URLs, die mit file:// beginnen, nicht. Deshalb sollte man solche Adressen direkt in die Adressleiste ziehen. Es gibt keine Hinweise darauf, dass die Schwachstelle ausgenutzt wurde.

Bild: , thx!






Autor: Antonia
 


Due to a Firefox bug in handling file:// URLs it is possible on both systems that users leak their IP address. Once an affected user navigates to a specially crafted web page, the operating system may directly connect to the remote host, bypassing Tor Browser.

Quelle, der verlinkte Blog Post

Edit: Vermutlich also beim Downloadrequest.
 
Zuletzt bearbeitet:
allein schon von der syntax her sollte es unmöglich sein, dass die file://-url irgendwo anders als auf dem lokalen dateisystem angefragt wird.. ich kann mir auch kaum vorstellen, dass es "zufällig" die funktionalität besitzt, lokale dateipfade per DNS aufzulösen und dann per HTTP abzurufen - wie um alles in der welt kommt man auf die idee, so ein "feature" in die lokale dateizugriffsroutine einzubauen? :confused:
ich könnte mir allenfalls vorstellen, dass ein fauler programmierer für den dateizugriff unter windows irgendeine unsichere internet-explorer-funktion nutzt - aber unter linux!? :eek:
 
allein schon von der syntax her sollte es unmöglich sein, dass die file://-url irgendwo anders als auf dem lokalen dateisystem angefragt wird.. ich kann mir auch kaum vorstellen, dass es "zufällig" die funktionalität besitzt, lokale dateipfade per DNS aufzulösen und dann per HTTP abzurufen - wie um alles in der welt kommt man auf die idee, so ein "feature" in die lokale dateizugriffsroutine einzubauen? :confused:

Unter GNU-Hurd kann man http und ftp als Dateipfade einbinden, in entsprechende Folder :p. Wie genau das under-the-hood funktioniert, habe ich mir aber auch noch nicht angesehen.

Ansonsten scheint es wohl eher am Firefox zu liegen.... und nicht ein "generelles Linux Problem" zu sein das alles "online" abfragen kann mit normalen Dateizugriffsfunktionen! - da, nach etwas nachlesen, "file://" Urls immer auf das lokale System verweisen, wie du selbst sagst.
Zu mehr müsste man Zugriff in den Bugtracker Bug von Firefox haben, der auch im Tor Release Announcement zur letzten Version verlinkt ist.
 
sicher kann man externe ressourcen als lokalen dateipfad einbinden, aber dann haben sie trotzdem einen lokalen alias/link/whatever, der eben vorher erzeugt werden muss (das ist ja gerade der sinn).. es ist schwer vorstellbar, wie man einen parser programmieren kann, der eine url wie "file://scamurl.org" nicht vom dateisystem requestet, sondern versucht sie aufzulösen und per system-http-client abzurufen.. wie gesagt, sowas erwarte ich eher, wenn man den inhalt ins windows-10-suchfenster tippt und nicht vom aufruf einer dateisystem-API :confused:
 
Ja, irgendwie kurios.
Vielleicht zeigt der lokale Pfad ja auf die existierende, temporär abgelegte html-Datei die so gebaut ist, dass externe Inhalte auf jeden Fall nachgeladen werden müssen, wenn sie lokal aufgerufen wird und diese werden dann aber auf direktem Weg abgefragt?
 
Eigentlich ein sehr guter Gedanke, aber mal ein selbsttest: Gebt mal "about:cache" in Firefox ein und dann auf die Übersicht des "Disk Caches"...

Die Dateien werder per Default so gespeichert:
/home/USERNAME/.cache/mozilla/firefox/profilID_x1678924idx.default/cache

Um das Auszunutzen, müsste die ProfilID irgendwie bekannt sein und der Benutzername auch noch, weil "file:///" in das Wurzeldateisystem verweist, und "file://~" geht so direkt nicht, hier wird nicht der Accountordner anvisiert. Soweit ich das richtig gelesen habe. Bzw. durch kurzes testen. Wobei, vielleicht ruft ja das "File://usr/bin/BROWSER URL --newTab" auf? - Letzteres sollte ja eigentlich nicht gehen, aber wer weiß wie Firefox das verarbeitet... getestet habe ich es nicht ;)

Ich könnte mir aber vorstellen, wenn es eine Datei ist, würde ja nur ein Bildload von einer URL von "localhost" zu "Domain" ausreichen über ein verändertes Source Attribut im Image-Tag, erklärt aber immer noch nicht wie die Datei aus dem Browser auf das OS kommen kann bzw. direkt angesteuert wird, wenn das mit dem "cache" zutrifft, die dann als Link verlinkt wird.
 
in dem fall muss der angreifer bereits eine derart präparierte html-datei unter einem ihm bekannten pfad auf deinen rechner geschmuggelt haben - was ich schon im ersten post gesagt habe..
aber selbst dann sollte es nie zu der situation kommen, dass ausgerechnet ein browser web-inhalte über die system-API nachlädt statt über - ähm - seinen eingebauten web-client ( ).. wenn eine html-datei externe inhalte nachlädt (img-tag o.ä.), dann ruft sie der browser ganz normal ab, so wie jede andere web-url (also insbesondere unter beachtung der proxy-einstellungen usw.), egal ob die html-datei aus dem web oder von der festplatte kommt.. diesen teil werden sie sicher nicht vergeigt haben, sonst wäre es ein plattformunabhängiges problem..
 
Zurück
Oben