Wo wird die Information zur Standardsuchmaschine gespeichert?

  • Mit der Version 57 ist mir ein kleines Problem aufgefallen, für das ich bisher keine Erklärung finden konnte. Die Standardsuchmaschine stellt sich unter gewissen Umständen immer wieder auf Google um.

    Hintergrund zu den gewissen Umständen: Ich starte den Firefox über ein shell script, das unter anderem folgende Zeilen enthält:

    Code
    if [ ! -d /dev/shm/Fox_im_RAM ] 	
    	cp -r /home/Benutzer/.mozilla/firefox/axsybuju.Name/ /dev/shm/Fox_im_RAM/  	 
    fi
    firejail firefox -P Fox_im_RAM

    Das heißt, ich kopiere ein vollständiges Profil in den RAM und starte dann den Firefox in einer Sandbox mit diesem Profil. Das funktioniert seit Jahren einwandfrei.
    Als Standardsuchmaschine habe ich im originalen Profil startpage eingestellt. Diese Suchmachine wird dort auch benutzt. Also alles gut. Übrigens habe ich dieses Profil mit dem Update auf die 57 neu erstellt.

    Starte ich den Firefox nun mit der Kopie, wird die Standardsuchmaschine stets auf Google zurückgesetzt. Das passiert auch, wenn ich den Firefox außerhalb der Sandbox starte. Mit firejail hat es daher nichts zu tun.

    Das lässt mich vermuten, dass die Einstellung dazu entweder außerhalb des Profils gespeichert wird oder dass die Umstellung hard coded über den Firefox erfolgt.

    Interessanterweise passiert das nicht unter Windows 10. Dort benutze ich ein ähnliches Verfahren und starte den Firefox ebenfalls in einer Sandbox, die ihrerseits im RAM liegt. In dieser Sandbox finde ich keine Datei, außerhalb des Profils, in der ich vermuten würde, dass die Suchmaschine gespeichert wäre.
    Das klingt nach hard coded. Es erklärt nur nicht, weshalb es nur unter Linux auftritt.

    Hat dazu jemand eine Erklärung oder eine Idee, wie ich das Zurücksetzen auf Google abschalten kann?

  • Bevor ich mich aus dem Forum zurückziehe, möchte ich gern meinen Beitrag hier noch einmal noch vorn bringen. Selbst wenn dieses Verhalten nicht änderbar sein sollte, würde ich mich über die Bestätigung freuen. Das würde mir zumindest die weitere Suche ersparen.

  • Die Suchmaschinen inkl. der Standard-Suchmaschine sind in der Datei search.json.mozlz4 gespeichert. Du kannst in der Browserkonsole den folgenden Code ausführen und die entsprechende Datei auswählen. Das öffnet dir ein neues Firefox-Fenster mit dem dekomprimierten Inhalt (und speichert die Ausgabe außerdem als JSON-Datei im Profilverzeichnis).

    Durch dein Vorgehen stimmt wahrscheinlich der Hash nicht mehr, weswegen Firefox eine unbefugte Änderung von außen annimmt und das führt in Firefox 57.0.1 zu einem Zurücksetzen der Standard-Suchmaschine, weil durch dieses Vorgehen für Firefox unbekannt ist, woher die Änderung kommt.

  • Zunächst einmal vielen Dank.

    Das Script wirft einen Typ error, weil Cc undefiniert ist. Das schaue ich mir morgen mal in Ruhe an. Es kann sein, dass das an meiner Sandbox liegt. Vielleicht fehlt auch nur irgendwo ein ";" oder so. ;)
    Wenn es sich bei der Kompression um Standard LZ4 handelt, kann ich die Datei aber auch ohne Script dekomprimieren.

    Zunächst bitte zwei Fragen:


    Durch dein Vorgehen stimmt wahrscheinlich der Hash nicht mehr,

    Die Datei wird als Bestandteil des Profil kopiert. Ihr Hashwert ändert sich dabei dann nicht. Hältst du das für die Ursache?
    Unter Windows passiert bei meinem Vorgehen übrigens das Gleiche: Die Sandbox kopiert das Profil (bei mir ebenfalls in den RAM) und damit diese auch diese Datei. Dort tritt das Problem nicht auf. Das spricht doch sehr dafür, dass es nicht am Hash liegt?


    und speichert die Ausgabe außerdem als JSON-Datei im Profilverzeichnis)


    Bedeutet das, dass der Firefox dann die dekomprimierte JSON-Datei anstelle der LZ4 verwendet?

  • Das Script wirft einen Typ error, weil Cc undefiniert ist. Das schaue ich mir morgen mal in Ruhe an. Es kann sein, dass das an meiner Sandbox liegt. Vielleicht fehlt auch nur irgendwo ein ";" oder so. ;)

    Du musst das in der Browserkonsole ausführen, nicht in der Webkonsole.

    Zunächst bitte zwei Fragen:

    Die Datei wird als Bestandteil des Profil kopiert. Ihr Hashwert ändert sich dabei dann nicht. Hältst du das für die Ursache?

    Das halte ich für wahrscheinlich, ja. Die ganze Sache mit dem Hash wäre ja nutzlos, wenn eine externe Anwendung die Datei im Profilverzeichnis einfach austauschen kann. Dieser Mechanismus wurde eingeführt, um genau das zu verhindern, weil Drittanbieter-Anwendungen / Malware genau das in der Vergangenheit getan hat.

    Bedeutet das, dass der Firefox dann die dekomprimierte JSON-Datei anstelle der LZ4 verwendet?

    Nein. Nur falls du das Fenster schließt und später nochmal darauf zugreifen willst. Firefox verwendet immer die originale Datei.


  • Du musst das in der Browserkonsole ausführen, nicht in der Webkonsole.


    Ok, die Webconsole hat vermutlich nur die aktuelle Seite als Scope? Mache ich ggf. morgen.


    Das halte ich für wahrscheinlich, ja. Die ganze Sache mit dem Hash wäre ja nutzlos, wenn eine externe Anwendung die Datei im Profilverzeichnis einfach austauschen kann.


    Das leuchtet mir noch nicht ein. Es wird ja nichts ausgetauscht. Es wird das gesamte Profil kopiert. Sämtliche Dateien bleiben dabei identisch. Welcher Hash sollte sich denn dabei ändern? Selbst ein Hash über das gesamte Profil bliebe unverändert.


    Firefox verwendet immer die originale Datei.


    Gut, dann wäre mein Ansatz, dasss ich die Datei einfach dekomprimiere, die Suchmaschine ändere (sofern ersichtlich) und sie dann wieder in LZ4 komprimiere. Spricht aus deiner Sicht etwas gegen diese Vorgehensweise?

  • Ok, die Webconsole hat vermutlich nur die aktuelle Seite als Scope?

    Korrekt.

    Das leuchtet mir noch nicht ein. Es wird ja nichts ausgetauscht. Es wird das gesamte Profil kopiert. Sämtliche Dateien bleiben dabei identisch. Welcher Hash sollte sich denn dabei ändern? Selbst ein Hash über das gesamte Profil bliebe unverändert.

    Wenn du die Datei von einem anderen Ort kopierst, ist doch der Pfad der Datei anders. Der Pfad fließt in den Hash mit ein. Wie gesagt: der Sinn ist, dass die Datei eben nicht einfach von außen ausgetauscht werden kann. Der Pfad muss in irgendeiner Weise individuell sein und darf nicht für jede Installation gleich sein. Ansonsten wäre die ganze Maßnahme wirkungslos, weil dann Drittanbieter-Software / Malware einfach die Datei austauschen würde.

    Gut, dann wäre mein Ansatz, dasss ich die Datei einfach dekomprimiere, die Suchmaschine ändere (sofern ersichtlich) und sie dann wieder in LZ4 komprimiere. Spricht aus deiner Sicht etwas gegen diese Vorgehensweise?

    Dann passt der Hash nicht mehr zur Standard-Suchmaschine. Das wird nicht funktionieren.

  • Danke, dass du mit dran bleibst.


    Wenn du die Datei von einem anderen Ort kopierst, ist doch der Pfad der Datei anders. Der Pfad fließt in den Hash mit ein.


    Wenn der Pfad mit einfließen würde, dann wäre das natürlich eine Erklärung. Ich wüsste aus dem Stand aber keinen Grund, aus dem man das machen sollte. Was wäre damit gewonnen? Eine Änderung an der Datei search.json.mozlz4 würde auch ohne Pfadangabe einen anderen Hash ergeben. Eine Manipulation würde sofort auffallen, auch ohne den Pfad mit zu hashen.

    Dass der Pfad mit gehasht wird, kann meines Erachtens auch nicht zutreffen. Zumindest unter Windows 10 nicht. Ich habe zum Test gerade ein Profil vom Standardort auf eine andere Partition kopiert und diese Kopie als neues Profil im Firefox eingebunden. Wenn ich diese Profilkopie nun starte, verändert der Firefox die search.json.mozlz4 nicht. Die eingestellte Suchmaschine bleibt dann auch erhalten.
    Selbst wenn ich das Profil in ein RAM-Drive kopiere und den Firefox damit in einer Sandbox starte, wird die Suchmaschine nicht zurückgesetzt.

    Unter Linux ist das nicht der Fall. Dort wird die search.json.mozlz4 der Kopie gleich nach dem Start vom Firefox geändert.

    Ich schaue mir jetzt mal den Inhalt der search.json.mozlz4 an und melde mich wieder.

  • Wenn der Pfad mit einfließen würde, dann wäre das natürlich eine Erklärung. Ich wüsste aus dem Stand aber keinen Grund, aus dem man das machen sollte. Was wäre damit gewonnen? Eine Änderung an der Datei search.json.mozlz4 würde auch ohne Pfadangabe einen anderen Hash ergeben. Eine Manipulation würde sofort auffallen, auch ohne den Pfad mit zu hashen.

    Es gibt einen sehr einfachen Grund: das Profilverzeichnis ist individuell, eine Drittanbieter-Software oder Malware weiß nicht, wie dein Profilverzeichnis heißt. Dadurch reicht das Wissen, wie Mozilla den Hash generiert, nicht aus, um die Datei zu ersetzen. Eine allgemeine Ersetzung ist also ausgeschlossen. Die ersetzte Datei müsste bei jedem Anwender anders aussehen. Das heißt, es wird dadurch sehr, sehr viel schwerer für Drittanbieter-Software / Malware.

    Dass der Pfad mit gehasht wird, kann meines Erachtens auch nicht zutreffen.

    Es trifft zu. Ich habe den Quellcode vor meinem Beitrag extra noch einmal überprüft:
    https://searchfox.org/mozilla-centra…vice.js#778-787

  • Der Quellcode erweckt den Anschein, als würde der Pfad zum Salzen des Hashs benutzt. Das ist nicht ganz das Gleiche. Darum soll es mir aber bitte gar nicht gehen. Ich lenke mich und dich sonst selbst von meinem eigentlichen Problem ab.

    Das wird nämlich noch ein wenig verworrener. Vielleicht kannst du auch dazu mehr Licht ins Dunkel bringen. Ich habe mein Startscript für einen Test etwas ergänzt und die Datei search.json.mozlz4 schreibgeschützt.

    Code
    if [ ! -d /dev/shm/Fox_im_RAM ] 	
    	cp -r /home/Benutzer/.mozilla/firefox/axsybuju.Name/ /dev/shm/Fox_im_RAM/ 
     	chmod -w /dev/shm/Fox_im_RAM/search.json.mozlz4 
    fi
    firejail firefox -P Fox_im_RAM


    Dass der Schreibschutz dann auch tatsächlich gesetzt ist, habe ich nach dem Start des Firefox kontrolliert.

    Code
    casali@Q07H030101:/dev/shm/RamFox$ ls -l search*
    -r-------- 1 casali casali 12147 Dez 10 16:50 search.json.mozlz4

    Die Datei ist also wirklich schreibgeschützt und trägt auch das Datum vom 10.12. . An diesem Tag habe ich das originale Profil als Kopiervorlage frisch erstellt.
    Schaue ich in nun in die Einstellungen, dann sehe ich, dass meine Suchmaschinen vorhanden sind, auch die nachträglich installierte von Startpage. Diejenigen, die ich abgewählt habe sind auch abgewählt. Soweit, so gut.

    Der Firefox hat die Datei demnach also gelesen und benutzt auch die Daten daraus. Bis auf eine: Die Standardsuchmaschine ist trotzdem auf Google zurückgesetzt worden. Auch wenn der Firefox die Datei nicht neu schreiben kann, in seinen aktiven Einstellungen im RAM hat er die Zwangsänderung vorgenommen.
    Somit scheint klar, dass ich dieses Verhalten außerhalb des Firefox Quellcodes wohl nicht werde lösen können.

    Ein kleine Hoffnung bleibt noch: Weshalb klappt das alles unter Windows? Dort wird die kopierte search.json.mozlz4 akzeptiert und nicht verändert, obwohl sich auch hier der Pfad geändert hat. Hast du dazu eine Idee?

  • Der Quellcode erweckt den Anschein, als würde der Pfad zum Salzen des Hashs benutzt. Das ist nicht ganz das Gleiche.

    Ich weiß nicht, was du damit meinst, dass das nicht ganz das Gleiche sei. Ein Salt beeinflusst einen Hash maßgeblich. Veränderst du den Salt, ist der Hash ein vollkommen anderer. Das ist ein zusätzlicher Schutz, der den reinen Hash-Algorithmus sicherer macht. Also ist das im Ergenis so ziemlich das, was ich beschrieben habe: der Pfad fließt in den Hash ein.

  • Wie ich schon geschrieben habe, möchte ich eigentlich keine Schattendiskussion führen. Das hilft mir zur Lösung meines Problems nicht weiter. Ich bitte hier um Verständnis. Ich möchte wirklich nun unfreundlich oder undankbar rüberkommen.

    Den Test, ein Profil unter Windows an einen anderen Ort zu kopieren und von dort aus zu starten, kann jeder nachvollziehen. Wenn ich annehmen darf, dass das Hashing im Firefox unter Windows gleich erfolgt wie unter Linux, dann kann hier nicht die (alleinige) Ursache liegen. Es muss einen anderen oder zumindest einen weiteren Faktor geben. Den würde ich gern erfahren, weil sich daraus vielleicht doch noch eine Lösung erarbeiten lässt.
    Daher meine Frage:


    Weshalb klappt das alles unter Windows? Dort wird die kopierte search.json.mozlz4 akzeptiert und nicht verändert, obwohl sich auch hier der Pfad geändert hat. Hast du dazu eine Idee?

  • Casali, ich habe keine Ahnung, ob es für dich hilfreich ist oder einfacher, als die Standardsuchmaschine wieder zurückzustellen, aber sieh dir doch mal
    dieses Posting von Alice0775 in MozillaZine an.

    Wobei ich mich schon frage, wieso Du keine Probleme damit in Windows hast, das dürfte dann ein sicherheitsrelevanter Bug sein, wenn Sören recht hat.

  • Hallo Hoffnungsvoller, ...

    danke für den Hinweis. Dass sich search.json.mozlz4 nicht einfach so entpacken lässt, hatte ich vorgestern ebenfalls feststellen müssen. Mozilla verwendet nicht das Standard-LZ4. Die Endung mozlz4 deutet es schon an. Man kann die Datei mit den genannten Scripts entpacken oder mit Tools wie lz4json oder dejsonlz4.


    Wobei ich mich schon frage, wieso Du keine Probleme damit in Windows hast, das dürfte dann ein sicherheitsrelevanter Bug sein, wenn Sören recht hat.

    Darüber habe ich gestern noch etwas nachgedacht. Für den Sonderfall der Sandbox unter Windows ist mir inzwischen klar, warum es funktioniert. Das ist einfach zu verstehen, wenn man denn mal darauf gekommen ist.
    Ich verwende unter Windows Sandboxie und unter Ubuntu Firejail, wie man oben sieht. Sandboxie erstellt für die darin laufenden Programme eine eigene Umgebung und "emuliert" gewissermaßen das Filesystem. Dabei bleiben die Pfadnamen erhalten, auch wenn sie umgelenkt werden.

    Weshalb es auch ohne Sandbox klappt, also einfach nur durch Kopieren, weiß ich noch nicht. Ich werde darauf aber keine weitere Mühe verwenden. Ich habe stattdessen über einen Workaround nachgedacht und eine mich praktikable Lösung gefunden. Damit bin ich zufrieden.

    Dir weiterhin viel Spaß im Forum.


  • Für den Sonderfall der Sandbox unter Windows ist mir inzwischen klar, warum es funktioniert. Das ist einfach zu verstehen, wenn man denn mal darauf gekommen ist.
    Ich verwende unter Windows Sandboxie [.] Sandboxie erstellt für die darin laufenden Programme eine eigene Umgebung und "emuliert" gewissermaßen das Filesystem. Dabei bleiben die Pfadnamen erhalten, auch wenn sie umgelenkt werden.


    Aah, ja das ergibt Sinn.

  • Ich könnte mich soweit in das Thema einlesen um einen Bugreport schreiben (dank IT Background verstehe ich das geschriebene zum grössten Teil) wenn ihr Casali und @Sören der Meinung seid dass es sich um einen sicherheitsrelevanten Fehler handelt und ihr keine Zeit oder Lust dazu habt. Nicht dass wir (deutschsprachigen) Hackern schlussendlich ein Zero-Day-Sicherheitslücke auf dem Silbertablett präsentieren und Mozilla keine Ahnung davon hat.

  • Ich kann nicht beurteilen, ob das eine Sicherheitslücke darstellt. Ich kann nur folgendes feststellen: Wenn es die Absicht ist, durch Hashen und Salzen, eine Änderung der Datei search.json.mozlz4 zu verhindern - und zwar sowohl was ihren Inhalt betrifft als auch ihren Pfad - dann klappte das bei meinen Tests unter Windows nicht.

    Meine Tests zielten nur auf den Pfad ab. Ich habe nicht getestet, ob eine inhaltliche Änderung der Datei ebenfalls durchgehen würde. Das dürfte sie nicht. In diesem Fall hätte sich sogar der tatsächliche Hashwert der Datei und nicht nur das Salz geändert. Das wäre ein größeres Problem.

    Noch etwas ist mir bei den Tests aufgefallen. Bei mir hat sich ja nur der Pfad des Profils geändert. Wäre der Hash inklusive Salz nun das Kriterium, an dem erkannt wird, dass eine nicht gewünschte Änderung vorgenommen wurde, die vielleicht ein Sicherheitsrisiko darstellt, dann müsste der Firefox anders reagieren.
    Warum? Anhand es Hashwerts lässt sich nur erkennen, dass etwas geändert wurde. Man kann aus dem Hash nicht ermitteln, was geändert wurde. Die richtige Reaktion darauf wäre also, die fragliche Datei komplett durch eine sichere Standardversion zu ersetzen.
    Das passiert aber nicht. Alle anderen Einstellungen wie auch die von mir selbst installierten Suchmaschinen bleiben erhalten. Hätte ein Angreifer mir eine schädliche Suchmaschine untergejubelt, dann wäre sie immer noch da und auch auswählbar.

    Anders wäre die Situation, wenn der Firefox erkennt, dass nur das Salz nicht mehr stimmt. Dann wäre klar, dass die Datei selbst nicht verändert wurde, also auch kein Risiko darstellt. Dann könnte man sie so belassen. Dann wüsste ich aber auch keinen technisch notwendigen Grund, die Standardsuchmaschine auf Google zurückzusetzen.

    In Summe passt das für mich nach wie vor nicht zusammen, wie man es auch dreht. Jedoch kenne ich weder alle Details noch die Absicht dahinter und könnte nur mutmaßen.

    Wie geschrieben, habe ich mir einen Workaround gebastelt und bin Google als Standardsuchmaschine auch unter Linux los. Mein eigentliches Problem ist damit gelöst.

    Wenn du für dich zu der Erkenntnis kommst, dass es sich um einen sicherheitsrelevanten Bug handelt, dann teile es Mozilla zur Prüfung mit. Ich würde dich nur bitten, den Test zunächst auch selbst einmal auszuführen und zu bestätigen, dass auf deinem Rechner das gleiche Verhalten zu beobachten ist.

  • Danke für den Ping, ich hoffe noch auf eine zweite Beurteilung zur Sicherheit bevor ich hier etwas unternehme.
    Tests kann ich aber leider mangels Windows Maschine nicht vornehmen weshalb dies das Schreiben ein wenig erschwert.

  • Ich habe noch eine Neuigkeit dazu.

    Edit: Die Neuigkeit war dann doch keine. Deshalb lösche ich den vorherigen Inhalt dieses Beitrags, bevor er noch Verwirrung erzeugt.

    Ich habe gerade bemerkt, dass ich beim Auskommentieren meines Workarounds aus dem Startscript um eine Zeile verrutscht war. Damit war der Workaround bei meinem Test noch aktiv und deshalb funktionierte natürlich auch alles bestens.

    Also, der Stand ist der gemäß Beitrag 17. Alles gut.