Firefox: wie man nur noch Passwörter der eigentlichen Webseite sieht

Moin, Moin,

im Zuge des Bugtrackings für das Erscheinen der Passwortbox bei nicht Loginfeldern, kam auch endlich eine Lösung für dem Umstand ans Licht, daß meine Passwortbox einen halben Kilometer lang ist 🙂

Firefox: wie man nur noch Passwörter der eigentlichen Webseite sieht

Ich betreue ja einen Cluster und muß mich auf vielen Webseiten einloggen, da sammelt der Firefox natürlich eine Menge von Logindaten für Subdomains von uns und unseren Servern. Die Standardeinstellungen für Firefox zeigen in der PasswortBox alle Logindaten für die Hauptseite und alle Subdomains davon an.

Wenn man jetzt son Servercluster mit Subdomains adressiert: han1.domain.de han2.domain.de etc. etc. , dann bietet Firefox auf domain.de auch han1 und han2 und han… an. Für uns ist das wenig hilfreich, weil wir Logindaten nicht recyceln, also für jeden Login wirklich neue Daten verwenden, daher wird uns sehr viel angezeigt, daß wir nicht brauchen.

Dem Problem kann man jetzt elegant abhelfen, einfach in der about:config diesen Wert auf „Falsch“ setzen:

signon.includeOtherSubdomainsInLookup

Wer auf verschiedenen Subdomains die gleichen Zugangsdaten benutzt, so daß das Feature Sinn machen würde, der verdient es IMHO nicht besser, als das die Daten im nächsten großen Datenleck landen 😀

Firefox: Fehlerfix in der Passwordbox in FF 91

Für Euch kurz zur Info: Ich hatte soeben Gelegenheit Firefox 91.0a1 für Linux zu testen, da mal wieder ein Bugreport fällig war 😉 Läuft 😀

Firefox: Fehlerfix in der Passwordbox in FF 91

Mein Bugreport betraf dabei die Passwordbox, die kommt normalerweise nur, wenn man in einem Formular Felder mit der Bezeichnung Password oder Login anklickt. Dummerweise kam die auch bei anderen Inputboxen ohne Loginbezug und das ist einfach falsch. In FF91 ist das behoben worden.

Ansonsten lief der FF91 gut, da ist wenig zu befürchten 🙂

Firefox: Sicherheitsloch „Memory-Dump“

Im Zuge eines Bugreports für Jitsi Meet kam raus, daß die Speicherfunktion im Firefox Modul „about:memory“ nicht nur den eigenen Speicherinhalt, sondern wohl auch den von anderen Prozessen abspeichern kann. So oder so, muß man aufpassen, was man heraus gibt.

Firefox: Sicherheitsloch „Memory-Dump“

Eine aktuelle Instanz von Jitsi Meet führt zusammen mit der „Hintergrund Blur“ Funktion der Videokonferenzsoftware zu einem massiven Speicherverbrauch von Firefox, der das System nach einiger Zeit zum Swap-of-Death treiben kann. Ob und wann das passiert, hängt natürlich stark von Eurem PC-Setup ab. Bei mir waren es 16 GB Hauptspeicher, die Firefox in knapp 3 Stunden mit 8+ GB eigenem Speicher gefüllt hatte, der Rest war vom System und OBS belegt, als das Problem aus heiterem Himmel auftrat. Da es sich um das LPD Live-Streaming handelte, hatte ich zum Glück noch eine zweite OBS Instanz in der Hinterhand, die das Streaming dann direkt übernommen hat.

Im Zuge des Bugreports an Mozilla wurde ein Speicherdump angefordert, der allerdings (aller Wahrscheinlichkeit nach) auch Daten des laufenden Matrixclientens enthielt, sowie sensible Zugangsdaten, die Firefox gerade in Benutzung hatte. Die teilweise 190 MB großen Textfiles von Hand nach sensiblen Informationen zu durchsuchen würde viel zu lange dauern. Insgesamt sprechen wir hier über eine etwas weniger als 1 GB große Textfilesammlung.

URLs, Userids und Matrixdaten

In den Files habe ich besuchte URLs mit GET Parametern, UserIDs für Jitsi und sämtliche Nutzernamen von dem Clienten bekannten Matrixbenutzern gefunden. Da Firefox nur mit einem Testbenutzer in Kontakt kam, kann es fast unmöglich Firefox gewesen sein, dessen Speicher die Benutzerkennungen von anderen Matrixaccounts enthielt.

Ich kann Euch nur raten, diese Textfiles vor dem Übersenden an den Support von Mozilla in Augenschein zu nehmen, damit Euch nicht sensible Daten abhanden kommen. Wenn der Bugreport im Tracker nicht als „Security“ Report markiert ist, kann jeder diese Datenfiles runterladen und darin nach Herzenslust rumstöbern.

Am Wochenende hatte erst von Golem den neuen Firefox-Absturzreport als „positiv für andere Software-Projekte“ bezeichnet. Nachdem was in meinem Dump ( nicht vom Absturztool erzeugt ) drin war, glaube ich das sofort, nur bin ich da anderer Ansicht. Ein Browser ist heute ein sehr sensibles Stück Datenhalde, da kann man nicht mehr einfach alles zum Hersteller schicken und schon gar nicht von an dem Problem unbeteiligten Prozessen.

Kleiner Lacher am Rande: Das angeforderte „Mozilla-Regressiontool“ 4.0.17 muß wohl auch erst einmal gefixt werden, es crasht nämlich beim Start hart und schmeißt einen Coredump 😉


Fontconfig warning: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: unknown element „its:translateRule“
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ‚translate‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ’selector‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚xmlns:its‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚version‘
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Fontconfig warning: FcPattern object weight does not accept value [0 205)
Speicherzugriffsfehler (Speicherabzug geschrieben)

Da ist wohl „einiges“ im Argen bei Mozilla 😉

Quelle: https://github.com/mozilla/mozregression/releases