News Sicherheitslücke: Browser speichern Passwörter im Klartext im Arbeitsspeicher

[Luftgucker]

Irgendwann muss man halt Klartext reden. Sonst fangs ich halt von der Tastatur ab. Und einen Browser kann man auch beenden und den PC neustarten wenn man niemanden mehr traut.

 

[Mickey Cohen]

Joa, wenig überraschend. Wenn ich im Firefox auf Zugangsdaten klicke, kann ich meine gespeicherten Passwörter im Klartext lesen. Ohne dass ich irgendeinen Schlüsselbund entsperren muss.

Wie soll es denn auch sonst funktionieren? Wenn man nirgendwo ein Passwort eintippen will oder sich sonst identifizieren will (Fingerabdruck oder so) muss das PW schließlich irgendwo im Klartext gespeichert sein.

Warum das jetzt im Ram so viel schlimmer als auf der Platte sein soll verstehe ich nicht...

 

[Xood]

Und einen Browser kann man auch beenden und den PC neustarten wenn man niemanden mehr traut.

Leider nicht, ich habe es gerade getestet. Selbst nach dem Neustart sind die Passwörter bereits im Arbeitsspeicher!
Der Edge wird mittels Explorer automatisch gestartet, und da scheint es wohl Standard zu sein die Passwörter gleich mit zu laden. Inklusive Browserverlauf...

Und zu "Irgendwann muss man halt Klartext reden." Das stimmt.
Jedoch sollte das so lange wie möglichst herausgezögert werden.

 

[Piktogramm]

Ich frags mal nochmal: Kann man nicht mit SELinux, AppArmor oder TOMOYO Prozessen verbieten, die Speicherbereiche anderer Prozesse zu lesen?

Exakt die Frage kam mir auch als erstes in den Sinn! Wäre cool wenn da jemand was genaueres zu weiß.

Unter Linux reicht es, den Nutzern den Zugriff auf/mittels ptrace zu verbieten (Link auf NSA Proposal):
https://media.defense.gov/2019/Jul/...MITING-PTRACE-ON-PRODUCTION-LINUX-SYSTEMS.PDF

Zumindest um das konkrete Problem hier abzustellen.
SeLinux, AppArmor & Co stehen ansonsten noch auf meiner "Musst ich mir mal anschauen"-Liste[1]

Das wäre für Linux Distributionen und Windows vielleicht ganz schlau, entsprechende APIs in der Standardkonfiguration für normale Nutzer nicht zu exponieren. Quasi default Nutzerprofile für "User, Dev, Sudo".


[1]Wird kaum passieren, solang es beruflich nicht notwendig wird. Die Liste ist schlicht zu lang.

 

[DarkSoul]

Interessant wäre zu wissen, ob man die Passwörter im selben Rechte-Kontext auch anderweitig auslesen kann. Z. B. über Automatisierungstools oder durch Keylogger.

 

[0x8100]

Warum das jetzt im Ram so viel schlimmer als auf der Platte sein soll verstehe ich nicht...

weil du damit auch sessions-cookies bekommst, die mit hilfe von 2fa erstellt wurden.

 

[SonyXP]

Wer speichert zB Bank Passwörter schon im Browser? Wer solche Sachen im Browser speichert , ist selbst schuld und lost.

Ich speichere nur Passwörter im Firefox, wo die Dienste unwichtig sind und mir der Verlust egal ist. Die pw weisen auch keinerlei Ähnlichkeit mit wichtigsten Daten auf...

Ich verstehe, was Du meinst - aber Du wirst mir zustimmen, dass auch Du die Weisheit nicht mit Löffeln gefressen hast. So eine Aussage wirkt schon sehr "überheblich". Ich selbst arbeite auch in der IT, würde mir aber nie anmaßen, mich auf eine Stufe mit einem IT-Security-Experten (um mal bei diesem Thema zu bleiben) zu stellen, nur weil ich Berührungspunkte hier und da habe.

Wenn ich aber beispielsweise an weitaus weniger technik-affine Menschen und Anwender (also den Otto-Normalverbraucher) denke, dann wird schnell deutlich, dass diesem Personenkreis ein solcher Zusammenhang eben nicht "mal eben so klar ist". Wenn jeder alles wüsste, hätten wir diese Unterhaltung nicht.

Es wäre doch viel charmanter, hier über seinen Tellerrand zu schauen und eben genau über solche Sachverhalte aufzuklären, anstatt fehlendes Wissen als "Lost" zu bezeichnen.

 

[flaphoschi]

Ich möchte hier (positive) Kritik üben, vor allem an den Kommentaren auf Seite1. Hier steht etwas von Sicherheitlücke und niemand fragt nach den verwendeten Funktionen in der Win32 API?

https://docs.microsoft.com/en-us/wi...ssthreadsapi/nf-processthreadsapi-openprocess

The access to the process object. This access right is checked against the security descriptor for the process. This parameter can be one or more of the process access rights.

If the caller has enabled the SeDebugPrivilege privilege, the requested access is granted regardless of the contents of the security descriptor.

https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-readprocessmemory

A handle to the process with memory that is being read. The handle must have PROCESS_VM_READ access to the process.

Wenn ich das richtig sehe, wir hier ein Sicherheitsbruch auf der lokalen Maschine angenommen. Der Nutzer ist der gleiche oder der Administrator (Windowssprech für Superuser). Sowohl BSD, Linux, MacOS als auch Windows NT sind Multiprozess- und Multiusersystem. Ohne Erlaubnis des Betriebssystems darf bei keinem der genannten Betriebssystem ein Prozess in den Speicherbereich eines fremden Prozesses greifen.

Möglichkeiten

• Hier besteht eine Sicherheitsproblem im Betriebssystem Windows
• Hier besteht einer Hardwarproblem e.g. Side-Channel-Angriff etwa Spectre oder Meltdown
• Hier behauptet jemand, definiertes und korrektes Verhalten wäre eine Sicherheitslücke. Das ist nicht korrekt und da bin ich voll bei Google.

Könnte Chrome den Speicher intern nochmal verschlüsseln? Könnten sie. Sie können auch den Cache verschlüsseln. Sie könnten auch die Bookmarks verschlüsseln. Sie könnten auch ein Passwort beim Start des Webbrowsers abfragen. Tun sie nicht! Warum? Weil ihr euch mit einem Passwort am Betriebssystem anmeldet, selbiges übernimmt mit Unterstützung der Hardware die lokale Sicherheit in der Hand, die Kommunikationssicherheit übernimmt teilweise die Browserengine und teilweise auch das Betriebssystem (HTTPS). Das heißt hier, das Betriebssystem trennt die Speicherbereiche der Prozesse, verschlüsstelt in Software oder sogar in Hardware (in der Regel bei SSDs aus dem Profibereich) und kümmert sich um die Privilegien der Nutzer. Das ist wohlbekannt.
Verschlüsselung führt man wohl überlegt aus und wirft damit nicht um sich, am besten verwendet man dafür eine bestehende, gut getestet Implementierung - oder lässt nur Experten heran. Gelegentlich kommt es mal vor, dass Programmierer gezielt Speicherbereiche (geht effektiv nur mit Systemprogrammiersprachen wie C/C++) ausnullen und überschreiben. Soweit ich weiß wird das bei OpenSSH (richtig?) getan und leider habe sie dabei auch schon Fehler gemacht.

Es nicht Aufgabe von Google sich gegen das Betriebssystem Windows abzusichern. Das ist kein Aufgabenfeld der Anwendungsprogrammierung. Es ist nicht zielführend, dass jede Anwendung ein "Sicherheitstheater" betreibt. Das geht nach Hinten los. Sieht man bei vielen Virenscanner, Kopierschutz und Anticheatwerkzeugen. Hinterher hat man dann mehr Sicherheitsprobleme als vorher.

Ich möchte euch also Bitten zu überlegen, ob udn welche der genannten Optionen oben zutrifft.
Danke


// edit
Ich habe das Gefühl die "Empöreria" aus Twitter schwappt in andere Bereich. Das ist nicht gut und macht mir Angst. Ich möchte die Redaktion bitten vielleicht auch mal über ein Update im Kopfbereich des Artikels nachzudenken:

Um diese auszulesen ist bei entsprechendem Zugriff auf das System lediglich das kleine Tool ProcessHacker respektive die ProcessHacker.exe notwendig.

Und diesen Sachverhalt hervorheben.

Aber Artikel von "Sicherheitsforschern", wo mal wieder irgendeine Sau durchs Dorf getrieben wird, überfliege ich nur noch weil die meist fern jeglicher Praxis sind.

Leider wahr. Es gibt keine Meldung bei Hacker News? Ich vermute derlei Meldung würde dort kein Publikum finden.

 

[DarkSoul]

weil du damit auch sessions-cookies bekommst, die mit hilfe von 2fa erstellt wurden.

Wer eine Exe starten kann (oder anderweitig Code im genannten Rechtekontext ausführen kann), wird die Cookies doch dann auch direkt laden können... oder hab ich das Problem falsch verstanden?

 

[Unnu]

Aber sein Leben im Browser zu speichern, muss ja echt nicht sein

... stimmt. Das machen so gut wie alle mittlerweile alle via Mobile.

unabhängig davon ob lokal oder remote, ist sowieso schon alles zu spät.

... naja, alles nicht unbedingt. Vor allem nicht falls Remote. Da könnten ein paar Minuten / Stunden schon helfen.
Aber letztlich muss man halt irgendwo seine Root of Trust haben. Irgendjemanden MUSST Du vertrauen.
Das Spielchen kann man beliebig weiterspielen.
Das mit dem Trusted Computing ist die neueste Spielart. Oder auch das Rechnen auf immer noch verschlüsselten Dateien, auch so ein hochtheoretisches Konstrukt. Ob das jemals was wird? ich glaube nicht.

Google kümmert sich einen Furz um die Sicherheit der Nutzer.

... äh whut? Schon mal was von Project Zero gehört?
Aber ich glaube ich weiß worauf Du anspielst:
Dass Google seine Geschäftsinteressen (also Datamaining und der gezielte Verkauf von werberelevanten Informationen) nachhaltig und durchaus robust vertritt.

[1]Wird kaum passieren, solang es beruflich nicht notwendig wird. Die Liste ist schlicht zu lang.

... und sie wird mit jedem Tag länger ... !

 

[hippiemanuide]

Deswegen speichere ich keine PW mehr im Browser ab und muss nun mal checken welche PW Manager das gleiche Problem haben um auch die auf die Blackliste zu setzen

 

[kim88]

@hippiemanuide die arbeit kannst du dir sparen. Im Grunde darfst du dich nirgendwo mehr einloggen. Das Problem ist das man auch die Session Cookies auslesen kann - und damit umgeht man sogar die 2FA.

 

[TomH22]

Dass es die APIs gibt ist bekannt, dass sie von jedem beliebigen Prozess genutzt werden können nicht. Ich dachte eben, mein Debugger würde mit erhöhten Rechten laufen

Fragt Dich Windows oder Linux danach, wenn Du einen Debugger startest? Debugger sind "normale" Programme, die werden nirgendwo als "Debugger" registriert. So eine Liste von Rechten die einer App eingeräumt werden, wie etwas bei Anrdoid, gibt es bei Windows/Linux nicht.

Insofern könnte eine angreifender Prozess tatsächlich einfach einen Breakpoint im Browser setzen, an der Stelle wo der die Passwörter fertig entschlüsselt hat.

BTW:

Mich hat die Diskussion neugierig gemacht, und wollte es mal unter Linux testen. Einfach hexdump /proc/<procid>/mem gab einen I/O Error. Aber ich habe nach zwei Minuten Googlen diesen Beitrag bei Stackoverflow gefunden: https://stackoverflow.com/questions/12977179/reading-living-process-memory-without-interrupting-it

Auf einen Raspi mit dem Default User "pi" konnte ich den Speicher eines eigenen Prozesses ohne sudo, etc. auslesen:

Ich habe die pid der "eigenen" Bash genommen, es ging aber mit jedem anderen Prozess mit dem Benutzer pi, außer mit impersonifizierten Root Prozessen (z.B der ssh Prozess)

 

[flaphoschi]

Die „Sicherheitsforscher“ beschreiben zwar das Problem richtig, aber benennen die komplett falschen Schuldigen. Mit Chrome oder Firefox hat das nichts zu tun, sondern mit dem Sicherheitsmodell üblicher Desktop Betriebssysteme, und das sind Windows und Linux im Prinzip gleich.

Das ist mit Bezug auf Linux nicht korrekt. Hier gibt es seit vielen Jahren cgroup und namespaces und darauf aufbauend Container (Podman oder Docker) und Flatpak. Auch Systemd verwendet diese Techniken.

https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
https://docs.flatpak.org/en/latest/sandbox-permissions.html
https://man7.org/linux/man-pages/man7/user_namespaces.7.html
https://en.wikipedia.org/wiki/Linux_namespaces # Mit kleiner Anmerkung zu Chrome unten

Wir sind nur nicht daran gewöhnt. Die Techniken sind vorhanden, etabliert und seit Jahren in der Nutzung. Mit Fokus auf Container (Server) und jetzt kommt das auch mit Flatpak (PC) beim Anwender langsam an. Da wir auch Legacysoftware und Hardwarezugriff ermöglichen kann man mit Flatpak voll gesichert, teilgesichert oder herkömmlich arbeiten. Richtig Sinn macht Flatpak zur Sicherung zusammen Wayland.

 

[Whistl0r]

In meinen Augen versucht sich hier ein Unternehmen mit kommerziellen Interessen zu profilieren und verspielt dabei seinen möglichen Ruf.

Betrachten wir die Verwundbarkeit:
Der Angreifer muss es also geschafft haben eine Schadsoftware auf den Rechner des Opfer aufzuspielen und dort auch zur Ausführung gebracht haben.

Schon seit mehr als einer Dekade gilt:

Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore

https://www.marshall.edu/it/departments/information-security/10-immutable-laws-of-security/

Damit sollte alles gesagt sein.

Nun schreibt CyberArk Labs aber selber

• Why this is a significant issue: If one accepts the “assume breach” paradigm, then [all] the weaknesses in the way Chromium-based browsers treat sensitive credential data should be considered a major security risk. Mitigation should treat all these weaknesses.

D.h. sie scheinen diese Sichtweise ('"assume breach" paradigm' wie sie es nennen) zu kennen und pochen darauf, dass doch bitte ernst zu nehmen und zu fixen!

Nur leider kann man das nicht korrigieren oder mitigieren.

Es gibt keine 100% Sicherheit. Würde es sie geben, könnte man auf diesem System machen was man wollte und die Magie würde dafür sorgen, dass nichts passiert. Nun gibt es keine Magie. Und KI wird es auch nicht schaffen.

Stattdessen haben wir besagte Paradigmen. Wir definieren Bedrohungen gegen die wir uns schützen möchten womit wir gleichzeitig definieren (oder ehrlich zu uns selber sind) wogegen wir uns nicht schützen bzw. wo wir die Grenzen des Schutzes benennen. Und hier gilt eben besagte Annahme: Wenn es ein Angreifer schafft beliebigen Code auf dem eigenen System zur Ausführung zu bringen, dann hat er die volle Kontrolle und du hast verloren.

Genau deshalb setzt Microsoft (und auch Apple) auf ein System aus TPM, SecureBoot und FDE für die System-Partition etc. weil nur wenn sichergestellt ist, dass vom Einschalten bis zum Laden des Betriebssystems kein anderer Code ausgeführt wird, die Integrität des Systems sichergestellt sein kann. So zumindest die Annahme (Hallo PSP oder IME bzw. DMA Angriffe).

Warum kann man das Problem nicht beheben?

Weil zu irgendeinem Zeitpunkt das eigentliche Kennwort übergeben werden muss. Solange es diesen Zeitpunkt gibt kann ich diesen immer angreifen.

Schauen wir uns bspw. einmal an was die Besten der Besten machen, KeePass: https://keepass.info/help/base/security.html#secmemprot

Mehr geht nicht. Aber sobald ich eben an das Kennwort kommen muss (ich es selber im Klartext lesen möchte, es per STRG+C kopiere oder bspw. in eine Datei exportieren würde), kann es abgegriffen werden. Und wenn laut CyberArk Labs davon auszugehen ist, dass beliebige Schadsoftware zu diesem Zeitpunkt auf meinem System aktiv ist, habe ich eben verloren.

Spannend wäre jetzt noch zu wissen wie es aussieht wenn man "Isolated browsing" nutzt. Das kann man bequem für Microsoft Edge via Windows Security -> App & browser control aktivieren, sofern das eigene System dies unterstützt.
In diesem Modus läuft der Browser virtualisiert in einem Container. Entsprechend können (User-)Prozesse von außerhalb nicht auf die Speicherbereiche des Browsers zugreifen.
Microsoft Defender Application Guard kann auch für Google Chrome, Mozilla Firefox oder andere Anwendungen genutzt werden.

Ist damit alles gut?

Nach der Logik von CyberArk Labs dürfte damit nicht alles gut sein. Denn wieso sollten wir annehmen, dass der selbe Angreifer, der es geschafft hat beliebigen Code auf unserem Rechner zur Ausführung zu bringen, es nicht schafft den Hypervisor zu hacken oder den Browser direkt zu exploiten um dann bspw. einen Child-Prozess in der isolierten Umgebung zu bekommen womit er wieder auf den Speicher zugreift.

 

[Oteph]

Damit ein anderes Programm auf den Speicher eines anderen zugreifen kann benötigt es Root/Admin Berechtigungen.
Damit sind auch alle anderen Passwörter aus anderen Passwort Managern verloren. Mit Admin rechten kann man z.B. auch einfach einen Keylogger laufen lassen und so keePass Passwörter auslesen, oder aber eben das Master Passwort nach Eingabe direkt aus dem RAM auslesen.

Wenn jemand Vollständigen zugriff auf dein System hat - dann hast du einfach verloren.

Die einzige Möglichkeit die Passwörter dennoch abzusichern, ist Sie in einem noch besser abgesicherten System zu speichern. z.B. Apples Secure Enclave


Ich habe alle meine Passwörter in chrome - und werde daran nichts ändern. Hätte sowieso erwartet dass Chrome die Passwörter als Klartext im RAM speichert.

Bei wichtigen Accounts sollte man sowieso MFA nutzen.

 

[DJMadMax]

Deswegen speichere ich keine PW mehr im Browser ab und muss nun mal checken welche PW Manager das gleiche Problem haben um auch die auf die Blackliste zu setzen

@hippiemanuide die arbeit kannst du dir sparen. Im Grunde darfst du dich nirgendwo mehr einloggen. Das Problem ist das man auch die Session Cookies auslesen kann - und damit umgeht man sogar die 2FA.

Das wäre tatsächlich meine Frage zu dem Thema. Können die Daten live aus dem RAM ausgelesen werden, während sie eingetippt werden? Dann wäre das Ganze nichts weiter, als ein Keylogger, der lediglich umständlicher funktioniert. Wenn es sich jedoch um das Abspeichern der Passwörter im Browser handelt, dann bin ich ebenfalls aussen vor, denn so etwas lehne ich kategorisch ab.

In Cookies, egal ob Session oder nicht, sollten generell keine Passwörter im Klartext liegen, das wäre definitiv ein Sicherheitsfehler, der auf den jeweiligen Browserentwickler zurückzuführen ist.

Dass Google hier argumentiert, dass ein "local thread" nicht in deren Handhabe liegt, kann ich aber tatsächlich nachvollziehen. Erneut: für den Einsatz eines Keyloggers kann ein Unternehmen nichts, jedoch kann ich dafür sorgen, dass Passwörter nicht im Klartext in Session Cookies hinterlegt werden.

 

[T_55]

Warum geht sowas überhaupt, sollte heute nicht jedes OS einem Programm A den Zugriff auf Speicherbereich von Programm B verbieten? Ist das nicht eine Speicherzugriffsverletzung?

 

[TomH22]

Das ist mit Bezug auf Linux nicht korrekt. Hier gibt es seit vielen Jahren cgroup und namespaces und darauf aufbauend Container (Podman oder Docker) und Flatpak. Auch Systemd verwendet diese Techniken

Es kommt halt nicht darauf an, was grundsätzlich geht, sondern wie die beim durchschnittlichen Endbenutzer installierten Systeme konfiguriert sind.

Und da ist der Zugriff über die APIs oder das /proc Filesystem scheinbar üblicherweise noch möglich. Bei der Vielzahl an Linux Distributionen gibt es sicher Unterschiede.

Ich habe vorhin einen Raspi mit einem "Out-of-the-Box" Raspberry PI OS und eben ein Ubuntu 18.04 in WSL2 mit dem oben verlinkten Python Script probiert. Bei beiden konnte ich den Speicher eines belieben Prozesses mit dem gleichen User auslesen.

Windows hat schon seit den ersten Versionen von Windows NT grundsätzlich die Möglichkeit über die ACLs den Zugriff auf die genannten APIs zu beschränken. Es ist nur nicht so konfigiert.

Insofern ist auch Google Haltung zu dem Thema richtig, man sollte sich den Link https://chromium.googlesource.com/c...sically_local-attacks-in-chromes-threat-model wirklich mal durchlesen.

Ich weiß nicht welche Motivation CyberArk Labs und im Schlepptau Günther Born dazu getrieben hat, hier Google an den Pranger zu stellen. Sie haben eine Banalität gefunden, und vielleicht hat es sie gewurmt, das Google sich den Schuh nicht angezogen hat.

Damit ein anderes Programm auf den Speicher eines anderen zugreifen kann benötigt es Root/Admin Berechtigungen

Nein, es reichen normale User-Berechtigungen um auf eigene Prozesse zuzugreifen.

Warum geht sowas überhaupt, sollte heute nicht jedes OS einem Programm A den Zugriff auf Speicherbereich von Programm B verbieten?

Also genutzt wird es unter anderem für Debugger. Das Betriebssystem verhindert den direkten Zugriff, aber es erlaubt den Zugriff über dafür vorgesehene Schnittstellen wenn die benötigten Berechtigungen vorhanden sind.

 

[Oteph]

Nein, es reichen normale User-Berechtigungen um auf eigene Prozesse zuzugreifen.

Unter windows braucht dafür normalerweise dafür Adminrechte:

https://stackoverflow.com/questions/1989783/how-is-it-possible-to-access-memory-of-other-processes