[English]Das ist ist schon ein dickes Ei, auf das Sicherheitsforscher der CyberArk Labs beim Google Chrome-Browser gestoßen sind. Dieser speichert Passwörter und Cookies im Klartext im Arbeitsspeicher des eigenen Prozesses. Das bedeutet, ein entsprechendes Tool könnte diese Klartext-Passwörter auslesen. Ich habe es am Google Chrome und am Ungoogled-Chromium-Clone getestet – das Problem dürfte alle Chromium-Browser betreffen (also auch den Edge).
Anzeige
Ich bin die Woche auf Twitter auf den nachfolgenden Tweet der CyberArk Labs Sicherheitsforscher gestoßen, die den Sachverhalt offen legen und detaillierter im Blog-Beitrag Extracting Clear-Text Credentials Directly From Chromium's Memory beschreiben.
Das Ganze ist eine Zufallsentdeckung von Zeev Ben Porat, der im Rahmen eines Projekts einen Mini-Dump aller aktiven Chrome.exe-Prozesse anlegen ließ. Spontan beschloss er zu prüfen, ob ein Passwort, das er kürzlich in den Browser eingegeben hatte, in einem dieser Dumps auftaucht. Zu seiner Überraschung stellte er fest, dass das Kennwort im Klartext an mehreren verschiedenen Stellen im Speicher von zwei dieser Prozesse gespeichert war.
Er begann dann etwas genauer nachzuschauen und fand dabei heraus, dass Satyam Singh bereits 2015 Sicherheitsprobleme in Browsern in seinem Blog-Beitrag Browser-based vulnerabilities in web applications angesprochen hatte. Dazu gehörte auch das Thema "Passwörter werden im Arbeitsspeicher laufender Prozesse abgelegt".
Ein Alptraum für Nutzer
Nach diesen Erkenntnissen begann der Sicherheitsforscher genauer nachzuschauen, was der Google Chrome-Browser so treibt, und konnte seinen Augen kaum glauben, was er herausfand:
Anzeige
- Anmeldedaten (URL/Benutzername/Kennwort) werden im Speicher von Chrome im Klartextformat gespeichert.
- Zusätzlich zu den Daten, die dynamisch eingegeben werden, wenn man sich bei bestimmten Webanwendungen anmeldet, kann ein Angreifer den Browser dazu bringen, alle Passwörter in den Speicher zu laden, die im Passwort-Manager gespeichert sind ("Login-Daten"-Datei).
- Die Daten von Cookies (Wert und Eigenschaften von Cookies) werden im Speicher von Chrome im Klartext gespeichert (wenn die betreffende Anwendung aktiv ist). Dies schließt sensible Sitzungscookies ein.
Diese Informationen können effektiv von einem Standardprozess (ohne erhöhten Status) extrahiert werden, der auf dem lokalen Computer läuft und direkten Zugriff auf den Speicher von Chrome hat (unter Verwendung der APIs OpenProcess und ReadProcessMemory). Die extrahierten Daten können verwendet werden, um Benutzerkonten zu kapern. Das gilt selbst dann, wenn diese durch einen MFA-Mechanismus geschützt sind – denn dann ließen sich "Session-Cookies" auslesen und verwenden.
Der Sicherheitsforscher hat Beispiele für Session-Hijacking für Gmail, OneDrive und GitHub erfolgreich getestet. Er stellte ähnliche Schwachstellen im Microsoft Edge-Browser fest und vermutet, dass es bei anderen Chromium-Clones nicht anders ist. Die Details seiner Ermittlungen lassen sich im Blog-Beitrag Extracting Clear-Text Credentials Directly From Chromium's Memory nachlesen.
Mein eigener Test
Ich habe das zum Anlass genommen, am Samstag kurz einen eigenen Test mit dem Google Chrome, dem Ungoogled-Browser (Chromium-Clone) und dem Firefox-Browser zu fahren. Dazu habe ich mir das Tool Process Hacker für Windows von GitHub heruntergeladen und zur Auswertung der Memory-Inhalte verwendet.
Es reicht, den Hauptprozess per Rechtsklick anzuwählen und dann im Kontextmenü Properties anzuklicken. Im Eigenschaftenfenster geht man zur Registerkarte Memory und wählt dort die Schaltfläche Strings. Im angezeigten Dialogfeld ist eine String-Länge anzugeben (Standard ist 10). Das Ergebnisfenster listet alle Strings auf, die der Prozess-Hacker im Speicher für den jeweiligen Prozess gefunden hat.
Anschließend lässt sich im Ergebnisfenster mittels der Schaltfläche Filter ein Menü mit Befehlen zur Suche aufklappen. Ich habe mit für Contains bzw. die Variante ohne Groß-/Kleinschreibung beim Suchbegriff entschieden. Hier die Ergebnisse eines kurzen Tests:
- Google Chrome: Die Passwörter tauchen im Klartext auf
- Ungoogled-Browser: Die Passwörter tauchen im Klartext auf
- Firefox: Die Passwörter tauchen im Klartext auf
Die bittere Erkenntnis: Wer ein kompromittiertes System hat und den Google Chrome- oder einen anderen Chromium-Browser verwendet, hat keinen Schutz vor Passwort-Klau. Lediglich der Firefox schien es beim 1. Versuch, dass keine Passwörter gefunden werden. Mir scheint ein Fehler unterlaufen zu sein, da bei einem erneuten Test die Kennwörter im Klartext auftauchten. Ich habe das Ganze unter Windows 7 getestet, es dürfte aber in anderen Windows-Versionen ebenfalls so sein. Wie es unter macOS oder Linux ausschaut, und was auf Mobil-Plattformen wie Android oder iOS so beim Chrome passiert, habe ich nicht mehr testet.
Kein offizieller Fix …
Zeev Ben Porat hat das Ganze am 29. Juli 2021 an das Chrome-Team gemeldet und bekam umgehend von einem Projektmitglied die obige Rückmeldung, dass das Ganze nicht gefixt werde. Die Begründung, warum das Team das nicht als Problem ansieht, kann hier nachgelesen werden. Allgemein sind die Aussagen zutreffend, aber für den obigen Fall springt das Entwicklerteam in meinen Augen zu kurz – Kennwörter sollten nicht im Klartext im Browser-Speicher zu finden sein.
Zeev Ben Porat schreibt in seinem Blog-Beitrag, dass er nach seiner Meldung an das Chromium-Entwicklerteam aber einige Veränderungen beobachtet, die möglicherweise als "Entschärfungsversuche" zu werten sind. Ungefähr einen Monat nachdem er die Erkenntnisse an die Entwickler meldete, gelang es seinem Testprogramm nicht mehr, Cookies-Daten zu extrahieren. Es stellte sich heraus, dass das allgemeine Speicherlayout geändert worden war (sowohl in Chrome als auch in Edge). Mit einer Modifikation konnte er aber weiter Cookies extrahieren, bis das Programm nach zwei Monaten wieder (für Chrome und Edge) scheiterte. Aber die Klartext-Kennwörter lassen sich nach meinen Beobachtungen weiterhin aus dem Speicher extrahieren.
Ergänzung: Warum das ein echtes Problem ist, habe ich – aus gegebenem Anlass – gleich in meinem Blog-Beitrag 2. Nachlese zum gehärteten Sparkassen-Browser S-Protect aufgezeigt. Die benutzen die Web-Rendering-Engine von QT5 als Browser. Diese basiert wohl auf der Blink-Rendering Engine von Chromium (wenn ich nicht gänzlich falsch liege). Der gehärtete Browser soll auch auf infizierten Systemen mit Trojanern das Online-Banking schützen. Da wird richtig Aufwand getrieben, um das S-Protect-Browser-Paket abzusichern und das Abgreifen der Online-Banking-Zugangsdaten durch Phisher und Trojaner zu verhindern. Und dann kann ich die URL der Sparkasse samt meinem Zugangsdaten im Klartext aus dem Arbeitsspeicher auslesen.
Anzeige
Abwarten und Tee trinken. Bei Edge konnte ich das nicht nachvllziehen.
Ups, dann muss ich wohl meine Brille putzen, habe Tomaten auf den Augen, oder es ist um 01:55 Uhr draußen einfach zu dunkel, um graue Katzen noch deutlich zu erkennen. Sitze ja gerade am Artikel 2. Nachlese zum gehärteten Sparkassen-Browser S-Protect und hatte die Testumgebung offen. Schnell mal den Edge gestartet und am eigenen Blog angemeldet. Die größte Schwierigkeit bei dem Edge-Zeugs ist, dass bei einer geöffneten Seiten gleich acht Edge-Prozesse im Speicher gammeln. Aber ich formuliere mal so: Als ich genauer nachgeschaut habe, kam mir die Erleuchtung, dass ich das Passwort "Rumpelstilzchen" vielleicht nicht verwenden sollte ;-).
Kein echtes Problem, da Adminrechte und lokaler Zugriff nötig sind. Nur eine Überlegung:
Anders als bei TrueCrypt ist ein PW im Browser nicht dauerhaft im RAM nötig, da eine Anmeldung 1 Sekunde dauert. Bei TrueCrypt wird aber immer gelesen und geschrieben, deswegen ist bei der Festplattenverschlüsselung der Key immer im RAM oder den Registern der CPU lagern muss, wenn das System entsperrt ist.
Lösung: PW im RAM nach Verwendung durch Browser mit Zufallszahlen überschreiben. Dieser "Sicherheitsforscher" müsste eigentlich wissen, dass auf Daten die in Verwendung sind immer zugegriffen werden kann.
Selbst ein SSH-Key der auf einer Festplatte ruht kann mit Adminrechten ausgelesen werden, wenn er nicht zusätzlich Verschlüsselt wird. Stichwort: "Verschlüsselungs-at-Rest-Mechanismus". Auch die PWs lagern in einer DB im PC, wenn der Browser zu ist. Ohne Masterkey sieht man selbst bei geschlossenem Browser alt aus.
Wenn ich Admin bin, kann ich auch direkt Nutzereingaben der Tastatur loggen. Von daher war die einzige Erkenntnis hier: Keys werden nach verwendugn nicht korrekt mit zufallsdaten überschrieben. Was interessant und neu für mich war. Aber wie gesagt, kein Angriff da lokal+Admin nötig. Dann hat euch jeder Hacker sowieso in der Tasche.
"Lokaler Zugriff" ist zwar richtig, aber Admin braucht man nicht. ProcExp von den Sysinternals als normaler User öffnen und in den Properties von z.B. Edge hat man Zugriff auf die Strings. Dann noch in eine Datei speichern zum besseren durchsuchen oder Speicherabbild gleich mit ProcDump erstellen.
Das war jetzt mit Sysinternals, aber das lässt sich sicher auch mit Windows Board Mitteln scripten und das Ergebnis direkt irgendwo automatisiert hochladen. Das ganze noch schön per Spam als Download etc. verteilen und dann wars das auch mit lokalem Zugriff. Leute die drauf reinfallen scheint es ja genug zu geben, siehe fast täglich public werdende Ransomware-Fälle. Gut, Ransomware rentiert sich natürlich mehr, von daher ist die Frage warum jemand das machen sollte ;)
Daß im Speicher die gerade benötigten Daten im Klartext sind, ist eigentlich zu erwarten. Daß die komplette Liste der Paßwörter ständig geladen wird, ist aber unnötig. Er sollte nur die Paßwörter laden, die gebraucht werden.
Mit entsprechenden Berechtigungen kann man ja jederzeit einen Debugger anhängen und den Speicher auslesen. Das gilt auch für alle anderen Daten, die der Nutzer eingibt, zum Beispiel Kreditkartennummern.
gdb chromium -p 12345
dump memory …
Die Frage ist kann das aus der Ferne von der besuchten und kompromitierten Webseite aus initiiert werden?
Nen kompromitiertes Gerät, sorry da nützt dir auch ein verschlüsseltes Ablegen nix. Ist der Angreifer bereits auf dem System, stehen alle Türen speerangelweit offen.
Entscheidend ist also kann das auch auf einem sauberen System von außerhalb einfach ausgelesen werden? Wenn nicht ist das mal wieder nur Panikmache …
Es geht nur um Malware oder Angreifer, die direkt auf deinem Rechner mit deinem User laufen.
Der Autor sagt auch gar nicht, was Chromium anders machen sollte. Natürlich sind die Cookies der Seiten, die gerade angezeigt werden, im Speicher, sie müssen ja mit jedem Request mitgeschickt werden …
Valide ist aber die Kritik, daß alle Paßwörter geladen werden. Auch die, die man gar nicht gerade verwendet. Aber das macht es auch nur bequemer, richtig gut schützen kann man die auch nicht, wenn man den Nutzer nicht jedesmal nach einem Masterpaßwort fragen will.
Zitat: "Es geht nur um Malware oder Angreifer, die direkt auf deinem Rechner mit deinem User laufen."
Was glaubst du, auf wie vielen Rechnern, sei es privat oder in Firmen, so "ganz nebenbei" Malware mit läuft, genau hier Passwörter automatisiert abgreift und dann, bei Gelegenheit, dem Hacker mitteilt.
Unsere Admins auf Arbeit haben genau damit täglich zu tun. Die meisten Nutzer bestätigen "fast" alles, was aufpoppt, um einfach weiter arbeiten zu können.
Das sollte nicht so sein – aber die meisten Nutzer sind halt "nur" Nutzer – die wissen das nicht oder wollen das nicht wissen. Ist nun einmal so, wir werden nichts daran ändern.
Es wäre schön, wenn es anders wäre – aber es ist nun einmal so.
Und genau deshalb sollte solche "Fehler" nie passieren.
So ist das. Dagegen ist man am PC quasi schutzlos. Das gilt auch für typische Linux-Desktops. Dazu bräuchte man schon so eingesperrte Apps wie bei iOS und Android.
Unter Linux lege ich gern für bestimmte Dinge eigene Benutzer an. Das ist nicht viel Aufwand, bringt dafür aber recht viel. Die Programme kommen dann wenigstens nicht an die Dateien und Prozesse der anderen Nutzer.
Wenn man eine Malware mit Rootrechten hat, hilft es natürlich trotzdem wenig. Aber es macht die Trennung einfacher. Und man kann so einen Nutzer auch einfacher rückstandslos löschen.
Beispiel:
a) Hauptnutzer, mit dem man surft, private Mails liest und seine alltäglichen Programme benutzt.
b) Zweiter Nutzer, bei dem ich Mails und andere Dinge der Firma einrichte, die man zwischendurch mal braucht, wenn man seinen Arbeitsrechner nicht dabei hat. Die dürfte ich zwar auch unter dem Hauptnutzer einrichten, aber so habe ich eine bessere Trennung bei geringem Aufwand. Außerdem hat dieser Nutzer gleich auch ein eigenes Browserprofil mit arbeitsrelevanter History.
Und wenn ich mal verreisen will und mir mit den Firmendaten unwohl ist, kann ich den Benutzer einfach komplett löschen (oder Backup machen). Dann weiß ich ganz sicher, daß in meinen Dateien vom Hauptnutzer nicht noch irgendwelche Reste von Firmendaten versteckt sind.
c) Wenn ich ein Programm nur mal kurz testen oder für eine einzige Aktion ausführen will, aber dem nicht ganz traue, ob es nicht meine Konfiguration durcheinander bringt, lege ich einfach schnell einen neuen User an. Das ist vor allem nett bei Programmen, die nicht im Repo der Distri sind und mit jeder Menge Dependencies kommen (Node NPM oder Python PIP sind da so Kandidaten).
Warum ist das relevant zum Thema? Das Programm, das ich mal kurz teste, kann so keinen Debugger an den Browser des Hauptnutzers oder Firmennutzers anhängen, ein Programm des Hauptnutzers kann auch nicht an die Mails des Firmennutzers, usw.
Nachtrag:
Natürlich habe ich bei allen portablen Geräten die gesamte Platte verschlüsselt. Zusätzlich kann man auch noch das Verzeichnis eines Benutzers mit dem Anmeldepaßwort verschlüsseln. Dann ist es sogar vor Root geschützt, solange er nicht eingeloggt ist.
"… eingesperrte Apps wie bei iOS und Android."
aber wenn man einen Browser für alle Seiten benutzt, dann muß eine "böse" nur die App kapern …
… Kuketz empfiehlt seit Jahren das "Drei-Browser-Konzept", an das ich mich je nach Gerät auch halte.
ich habe die Vermutung, daß Google seinem eigenen Browser nicht mehr traut, vor etlichen Monaten wurde unter Android eine weitere "Chrome"basierte "App" hinzugefügt. "com.google.android.trichromelibrary". Still und heimlich hinzugefügt und aktualisiert wurde und wird sie. Ohne root nicht sichtbar, dann bekommt man höchstens die bis zum nächsten Update gültige UID mit. Versionsnummern wie bei "Chrome" und "Android System WebView" mit gleichem Update-Zyklus. Jedesmal ca. 110MB Speichermüll mehr hinterlassend, da die alte Version nicht beseitigt wird (hier auf allen Geräten mit Android 10 und 11). Wohl verwendet für Google-eigene Apps als Webkomponente a la "Chrome" oder "Android System WebView". Merkt man auch, wenn man ein neues oder geresetes Gerät, welches die "Trichromelibrary" nicht mitbrachte, mit gesicherten aktuellen Apps auf neuesten Stand bringen möchte, dann gibt es bezüglich der fehlenden, sonst unsichtbaren App eine Fehlermeldung.
Google geht mittlerweile anscheinend auch das "Drei-Browser-Konzept" unter Android. WebView für die Masse der App, wenn nicht auf Chrome eingestellt, Chrome als Browser für den Benutzer und die "unsichtbare" Trichromelibrary für die Sicherheit der eigenen Apps.
Wenn man danach sucht, dann findet man auch was bei xda-developers dazu – daß man mit root die alten Versionen manuell löschen kann …
… wenn man root-Rechte hat …
Meine Anfrage an den Support des PlayStores von Google war natürlich nutzlos, soll mich an android… wenden, nö, denn die sollten das Problem kennen.
Ansich ein Browser für eine Seite. Aber vllt. auch nicht unbedingt mehrere Apps gleichzeitig nutzen, die alle "Android System WebView" nutzen. Vor root-"Attacken" schützt das freilich alles nicht …
Ich den Process-Hacker gerade auf Firefox v101.0.1 los gelassen und fand u.A.
das Password für mein gerade geöffnetes pi-hole Backend:
0x19083c11c08 (28): pw=xxx (maskiert)
Interessant – möglicherweise habe ich die Nacht was beim FF übersehen – werde gelegentlich nochmals einen Test wiederholen.
Ergänzung: Du hast Recht – ich habe den Test nochmals wiederholt und konnte die Kennwörter aufstöbern – mir muss beim ersten Test ein Fehler unterlaufen sein (ich tippe darauf, dass ich den Firefox bereits beendet hatte, während der Eintrag noch im Process Hacker zu sehen ist). Ich habe das in obigem Text berücksichtigt. Danke für den Hinweis.
Naja technisch muss man erstmal klären warum der Processhacker oder ein anderes Programm das nicht dürfen soll. Immerhin könnte er ja einfach selbst die Passwortdatenbank von der Festplatte lesen.
Im Falle einer Benutzer Installation sogar problemlos die exe verändern.
Das ganze Sicherheitsmodell von Windows, Linux, und MacOs hat dieses Problem, dass Programme immer alles Treuhandisch im Namen des Users dürfen.
"ein entsprechendes Tool"
Es wäre lehrreicher, wenn dort stehen würde, welches Tool das ist. Die Bösen kennen das Tool ja.
Oder muß man schon Angast haben wg. der Nennung eines Hackertool ein Strafverfahren zu bekommen?
Ich bin völlig Überrascht, wieso ich einfach so in den Speicher eines anderen Processes schauen kann.
Sicher könnte ich den Process unter einem Debugger starten(lassen), aber dann greift doch wohl die Debugger-Sperre, wenn die Software mit Passwörtern hantiert. Man hält m. W. die Passwörter z. B. ausschließlich in CPU registern oder dem CPU Cache oder der Befehls-Que
Kommt da einer mit einem Debugger, gehen die Daten unvermeidlich kaputt.
Tool ist weiter unten genannt…
Ein Speicherabbild lässt sich auch mit dem Windows-eigenen Taskmanager auslesen. Man muss nur auf die erweiterte Ansicht gehen, dann in den Tab Details, und dann den Prozess mit der rechten Maustaste anklicken. Anschließend primitiverweise das Speicherabbild mit Notepad durchsuchen..
"Die bittere Erkenntnis: Wer ein kompromittiertes System hat und den Google Chrome- oder einen anderen Chromium-Browser verwendet, hat keinen Schutz vor Passwort-Klau."
Oje oje.. wer ein Kompromittiertest System hat bekommt Passwörter aus dem Speicher geklaut…
Was ein Quatsch, wenn das system sowieso schon Kompromittiert ist, braucht man keine Speicherdumps mehr.
> wenn das system sowieso schon Kompromittiert ist
Korrekt, aber es gibt Produkte, die auch für diesen Fall sicheres Onlinebanking versprechen, siehe auch spätere Ergänzung im Artikel, daher die "bittere Erkenntnis" …
https://www.borncity.com/blog/?s=S-Protect
Interessant, wie tote Pferde von einer zur nächsten Generation weitergereicht werden. Das Thema ist so alt wie der Computer selbst. Je nach System sind davon auch Swapfile.sys, Hiberfil.sys & Pagefile.sys betroffen.
Sowas, also eine Verschleierung, ist im Prozess/Speichermanagment von Windows halt nicht vorgesehen.
Das betrifft aber nur Passwörter die in Chrome selber gespeichert wurden?
Wenn ich mich jetzt "manuell" auf einer Webseite einlogge, ohne die netten Helferlein-Komfortfunktionen der Browser zu benutzen, dann sollte das Passwort gar nicht oder wenn überhaupt nur während der Übermittlung im Speicher "kurz auftauchen" *Hust*?
Wobei ich mich jetzt auch frage wie sowas vermieden wird. Zu irgendeinem Zeitpunkt muss doch das Passwort doch sicher im Klartext im Speicher landen?
Ich habe mir das jetzt nochmal bei Cyberark angesehen, und auch den Nachfolge-Kommentar "Go Blue" ( https://www.cyberark.com/resources/threat-research-blog/go-blue-a-protection-plan-for-credentials-in-chromium-based-browsers ) , der die Sache teilweise relativiert. Dabei ist mir eingefallen:
nirsoft.net -> "WebBrowserPassView – View the passwords stored by your Web browser (Supports Internet Explorer, Firefox, Chrome, Safari, and Opera) "
Also, wenn es einem Angreifer gelingt, auf einem Zielsystem ProcessHacker.exe zu starten, dann schafft er es sicher auch, auf dem gleichen Zielsystem das NirSoft-Tool zu starten, und von dort aus allen Browsern alle gespeicherten Passwörter herauszuholen. Und dieses Tool liest die Sachen nicht aus dem RAM, sondern aus den Benutzerprofildateien des Browsers.
Hiergegen hilft nur eins: Keepass oder vergleichbares, und die Login-Daten per Auto-Type oder Browser-Plugin aus dem wirklich verschlüsselten Passwortconatiner an den Browser zu schicken. Und wo es geht, die 2-Faktor-Authentifizierung zu aktivieren. Letzteres hilft aber nur bedingt, denn bei vielen Seiten meldet man sich nur ein Mal oder nur sehr selten mit dem 2. Faktor an, ansonsten vertraut die Seite dem Browser auf diesem PC erstmal eine Weile.
google – won't fix so eine heuchlerpartie. Aber wehe andere haben irgendwo Lücken drinnen, da gehts seitens google so richtig ab. bei den eigenen produkten nimmt man es halt nicht so genau. wenn man schon so etwas wie einen pw manager in den browser einbaut, sollte man tunlichst trachten, dass das die pws nicht ewig im speicher bleiben und wenn sie im speicher sind, verschlüsselt sind. alles andere hat mit security nichts zu tun.
aber jetzt wo google quasi 100% browser markt hat, spielt das wohl alles nur mehr eine sekundäre rolle.
Dieses Problem hat nicht nur Chrome/CHromium/Edge/Firefox .
Hab grade mal mit ProcessHacker das Passwort aus einem Forticlient ausgelesen, da steht auch alles im Klartext drin, wenn man nur den Forticlient startet.
Processhacker benötigt dazu Nichtmal Administratorrechte.
Das Problem ist einfach, dass eine Anwendung unter Windows ohne Administratorrechte den Speicher einer anderen Anwendung auslesen kann.
Hier noch ein Nachtrag.
Anscheinend hat das einer schonmal 2016! bei Fortinet gemeldet.
https://packetstormsecurity.com/files/138586/FortiClient-SSL-VPN-5.4-Clear-Text-Password-Extraction.html
Scheint aber bei Fortinet niemanden zu interessieren, da dort scheinbar seit 6 Jahren nichts passiert ist.
Klar, wenn man im Browser nichts an den Boolean, String und Integer ändert, sind die Türe und Tore stets weit geöffnet. Für Firefox kann man das verhindern. Klar, man verlässt vollständig die Komfortzone, gewinnt aber wirkllich an Sicherheit. Wie das geht, kann man hier erfahren: https://human-dignity.org/wp-content/uploads/2022/04/Rechner-richtig-konfigurieren_Win-10_Ver_1_1.ods
Die Einstellungen gelten auch Teilweise für Thunderbird und TOR.
Für Chromium wusste ich nicht, wie man genau im Systemwurzel der Anwendung käme, denn es handelt sich um eine proprietäre Entwicklung.