• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Tarnkappe] Tor-Browser-Exploit verrät Nutzer-IP-Adresse


Filippo Cavallarin, Chef der Sicherheitsfirma We Are Segment, hat bereits am 26. Oktober in einem Blog-Post 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 https://.



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 eine neue Version des Tor-Browsers 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: Wikimedia, thx!

https://tarnkappe.info/?flattrss_redirect&id=23398&md5=662d286680764b46a0ab645c27dff77d



https://tarnkappe.info/tor-browser-exploit-verraet-nutzer-ip-adresse/Quelle
Autor: Antonia
Quelle
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.573
@Novgorod:

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:

Novgorod

ngb-Nutte

Registriert
14 Juli 2013
Beiträge
3.055
@theSplit: 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:
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.573
@theSplit: 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.
 

Novgorod

ngb-Nutte

Registriert
14 Juli 2013
Beiträge
3.055
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:
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.507
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?
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.573
@BurnerR: 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.
 

Novgorod

ngb-Nutte

Registriert
14 Juli 2013
Beiträge
3.055
@BurnerR: 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 (you had one job!).. 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..
 
Oben