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:

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.

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:

Zitat von Sören Hentzschel

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?

Zitat von Sören Hentzschel

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?

Zitat von Sören Hentzschel

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.

Zitat von Sören Hentzschel

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.

Zitat von Sören Hentzschel

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?

Danke, dass du mit dran bleibst.

Zitat von Sören Hentzschel

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.

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.

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.

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?

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:

Zitat von Casali

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?

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.

Zitat von Speravir

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.

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.

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.