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

[TomH22]

Es lässt sich nicht vermeiden, das Passwort sollte nur nicht länger im RAM liegen als nötig, was es wohl auch nicht wird.

Selbst wenn es nur kurz entschlüsselt wird, ist es nicht so sehr schwer diesen Zeitpunkt abzupassen. Außerdem muss ja, falls man den Benutzer nicht alle paar Minuten nach eine Passphrase fragen möchte, auch der Key zur Entschlüsselung im Speicher liegen.

Ok mein Kennwort im RAM zu suchen ist eine Sache, aber ist die Speicherstruktur bekannt sodaß ich dort fremde Kennwörter oder Sessions etc. auslesen kann? Vermutlich NICHT. Wieder viel Wind um Nichts.

Chrome und Edge basieren auf dem Open Source Browser Chromium, Firefox ist direkt Open Source. Ja, jeder kann die Speicherstrukturen in GitHub nachsehen. Er kennt nicht die exakten Speicheradressen des Builds beim Angegriffenen, aber im Speicher nach Mustern zu suchen ist nicht schwer.

Deswegen kann es auch nicht gefixt werden. Selbst wenn man es verschlüsselt in den Speicher schreibt - irgendwann braucht man es, muss es wieder entschlüsseln, und dann liegt es auch wieder im Klartext vor. So funktionieren Computer nun mal.

Nein, auf diese Weise kann man es nicht fixen. Die Lösung ist, Prozesse besser zu isolieren, indem sie z.B. in eine eigenen VM gepackt werden die den Speicher hardwaremäßig verschlüsselt, und zwar für jeden Prozess mit einem eigenen Key. Natürlich kann es dann immer noch Angriffszenarien geben, über Schwachstellen im Hypervisor oder der Hardware selbst, aber so trivial wie in heutigen Desktop Systemen geht es nicht mehr.
Rein auf Softwareebene könnte man aber auch Userland Prozesse einfach besser isolieren, dann bräuchte man für legitime Anwendungen wie Debugger eben spezielle Berechtigungen.

Ich muss gestehen, ich hätte nicht gedacht, dass ein normaler Prozess einfach den Speicher eines anderen Prozesses auslesen kann

Insofern ist dieser Clickbait Artikel ja doch von Nutzen. Es ist eigentlich eine Banalität, die jedem der unter Windows oder Linux Software entwickelt eigentlich bekannt sein sollte. Als Entwickler nutzt man diese Funktionalität mehrmals am Tag, wenn man den Debugger anschmeißt, der liest die Daten genau über diese APIs

Aber interessant ist doch auch, dass FF das selbe "Problem" hat. Zwei unabhängige Team lösen eine Aufgabe auf ähnliche Weise, bzw hat sich keiner Gedanken gemacht, was passieren "könnte"...

Wie gesagt, jeder Entwickler weiß dass es so ist, und weiß auch, dass es ein Problem ist, was man auf Ebene der Anwendung nicht nachhaltig lösen kann. Also braucht man es auch nicht zu betrachten.

Also in der Zeit, in der die Google-Leute diese umfangreiche Erklärung erdacht, ausformuliert und mit dem Bereichsleiter abgestimmt haben, hätten die auch einfach den Fehler flicken können!

Nein, das Problem kann man nur durch eine Änderung der Betriebssystem Architektur (und ggf. eben auch der Hardware) lösen. Google hat auch schon eine (Teil)Lösung dafür, die nennt sich Android. Dort läuft jede App mit einer eigenen UserID, und damit getrennten Berechtigungen. Das ist aber auch eine Art Workaround, weil Linux hier das gleiche Verhalten hat, wie Windows.

BTW: Neben dem im Artikel genannten APIs kann man bei Windows auch die, im Prinzip seit Windows 1.0 gleiche, Clipboard API benutzen, um Passwörter abzufangen, die über die Zwischenablage übertragen werden. Die in vielen Password Managern vorhandene Funktion, ein Passwort in die Zwischenablage zu kopieren ist quasi eine Einladung an alle laufenden Prozesse sich das Passwort abzugreifen.

 

[Spike S.]

und trotzdem benötigt man noch immer Zugriff auf den PC.

Nein. Denn wenn ein Angreifer über einen Bug in einer anderen Software remote Zugriff mit Adminrechten bekommt, kann er das bequem von zu Hause in der Unterhose und mit einer Tüte Chips machen. Das ganze kann heutzutage auch automatisiert werden, zur Not über entsprechende Crime-as-a-service Angebote, da kann der Angreifer sich auch mal zwischendurch ne neue Tüte Chips holen.
Solche Fehler die Angreifer bis zum Arbeitsspeicher kommen lassen gibt es zu Hauf...

Wie gesagt, schwere Fehler stehen selten für sich allein.

 

[haloo]

Unter Linux sollte Yama die Möglichkeit andere Prozesse zu untersuchen einschränken.

 

[TomH22]

Dafür gibt es in der Regel eine OS-API. Bei Windows z.B. https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectmemory

Zitat aus dem Text zu dieser API:
"Encrypting the password prevents others from viewing it when the process is paged out to the swap file. "

Das ist der primäre Usecase für diese API.
Um die Daten zu benutzen, wird eine nicht verschlüsselte Kopie angelegt. Die kann man dann wieder abgreifen.

Natürlich hätte dieser API einen gewissen Nutzen, weil die Daten nicht ununterbrochen unverschlüsselt im Speicher liegen. Aber es wäre nur ein holpriger Workaround, der das Problem abmildert, aber nicht beseitigt.

Kritischer als die Passwörter, die meist nur einmal am Anfang einer Session übertragen werden, sind aber Authentikation Tokens, etc. Die müssen ständig mitgeschickt werden, müssen also ständig unverschlüsselt vorliegen, und ermöglichen einem Angreifer die Umgehung von 2FA.

 

[hemmi1982]

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...

Du hast schon gelesen das auch eingegebene PW im RAM landen? Aber ja Bank Passwörter sollte man nicht im Browser oder sonst wo speichern.

Kann man nicht in den Browser-Einstellungen die Passwörter sowieso unverschlüsselt ansehen? Dass die im RAM dann unverschlüsselt vorliegen, macht ja dann irgendwie Sinn

Ja aber nur wenn man das Passwort eingibt. Vorher nicht.



Vielleicht wäre die Lösung für Google die Passwörter direkt aus dem RAM wieder zu löschen.

 

[tollertyp]

Ich frage mich gerade wie es anders gehen soll. Der wird die Passwörter bei Verwendung laden aber die müssen ja entschlüsselt werden. Wenn sie verschlüsselt in den RAM geladen werden würden, müsste man auch den entsprechen Schlüssel in den RAM laden. Welcher natürlich auch wieder ausgelesen werden kann. Damit hätte man nichts gewonnen. So oder so, sollte 2FA Pflicht werden

Eben. Wenn eine Angreifer-Software eh schon so viel "Macht" auf dem lokalen PC hat, dann ist schon viel schief gegangen. Dann kann sie auch Tastatureingaben und Zwischenablagen überwadchen usw... ich kann Google da schon verstehen, das zu korrigieren würde die Sicherheit nicht wirklich erhöhen, das hätte eher Placebo-Wirkung wie die DNS-Sperren.

 

[Zer0DEV]

Diese "Sicherheitslücke" hat nur dann Auswirkungen, wenn man während der Laufzeit des Browsers sich auf einer Webseite anmeldet.

Ist man auf Grund eines Cookies beim Neustart des Browsers noch angemeldet, sagen wir z.B. auf Computerbase.de, dann kann man über Process Hacker gar keine Passwörter einsehen.

Auch nicht einsehen kann man darüber die im Browser gespeicherten Passwörter, wenn man sie nicht während der aktuellen Sitzung des Browsers für die Anmeldung auf der entsprechenden Webseite verwendet.

Die Berichterstattung (nicht nur hier) ist in meinen Augen daher nicht vollständig!!

 

[ModellbahnerTT]

Erschreckend das so etwas nicht bereits bei der Planung der Browser aufgefallen ist und dort dann behoben wurde.

 

[Combine]

Und wenn das Auslese-Tool am Ende dann doch wieder Admin-Rechte braucht, muss ich wieder ganz groß gähnen, weil ein Prozess mit Adminrechten auch einen Keylogger installieren kann.

Weil Systeme nicht als uneingeschränkt vertrauenswürdig eingestuft werden können, wurden Sicherheitschips entwickelt. Die Verbreitung dauert im PC-Bereich länger als bei Smartphones. Rembrandt soll als erste Plattform mit Microsoft Pluton erscheinen.

 

[Xood]

Und wenn das Auslese-Tool am Ende dann doch wieder Admin-Rechte braucht, muss ich wieder ganz groß gähnen, weil ein Prozess mit Adminrechten auch einen Keylogger installieren kann.

Das "Auslese-Tool" benötigt jedoch keine Admin-Rechte.

 

[Tomsenq]

Nein. Denn wenn ein Angreifer über einen Bug in einer anderen Software remote Zugriff mit Adminrechten bekommt,

Was anderes habe ich nicht geschrieben. Man benötigt zugriff auf den PC

 

[Spike S.]

Hab ich dann wohl falsch verstanden. Bin von physischem Zugriff ausgegangen.

 

[Miuwa]

Insofern ist dieser Clickbait Artikel ja doch von Nutzen. Es ist eigentlich eine Banalität, die jedem der unter Windows oder Linux Software entwickelt eigentlich bekannt sein sollte. Als Entwickler nutzt man diese Funktionalität mehrmals am Tag, wenn man den Debugger anschmeißt, der liest die Daten genau über diese APIs

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.

 

[NPC]

WebBrowserPassView von Nirsoft. Gibt es seit gefühlt 100 Jahren.... Was ist daran jetzt eine Neuigkeit? Fix ne Bounty abstauben, oder was?

 

[Cl4whammer!]

Wie sicher ist den der ganze Spaß mit eigenem Bitwarden Server und dann Firefox + Bitwarden Plugin.
(Im Vergleich zu das PWs im Browser gespeichert werden)

 

[MountWalker]

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

 

[Miuwa]

Wobei man natürlich generell sagen mus: Wenn auf dem eigenen PC bereits ein Schadprogram sein unwesen treibt hat es ohnehin zugriff auf so viele Daten und Dateien (auch ohne Admin rechte), dass PWs im Browser wirklich nur ein Problem von vielen ist. Ich mein, die komplette userconfig vom Browser (inklusive diverser Sicheheitseinstellungen) könnte z.B. verändert werden. Von Cryptotrojanern ganz zu schweigen.

 

[0x8100]

WebBrowserPassView von Nirsoft. Gibt es seit gefühlt 100 Jahren.... Was ist daran jetzt eine Neuigkeit? Fix ne Bounty abstauben, oder was?

das tool holt die passwörter (und nur die, keine cookies o.ä.) aus den auf dem system gespeicherten datenbanken, nicht aus den laufenden prozessen.

 

[kim88]

Natürlich ist sowas als Klartext in Arbeitsspeicher. Man will ja auch damit arbeiten können. Schließlich muss man das Passwort im Klartext in das Textfeld der Webseite reinschreiben. Anders geht es nicht.
Haben die werten Herrschaften überhaupt mal Software entwickelt?
Deswegen kann es auch nicht gefixt werden. Selbst wenn man es verschlüsselt in den Speicher schreibt - irgendwann braucht man es, muss es wieder entschlüsseln, und dann liegt es auch wieder im Klartext vor. So funktionieren Computer nun mal.

Naja es gebe schon Lösungsmöglichkeiten. 1Password löscht z.b. ein kopiertes Passwort nach 30 Sekunden oder so wieder aus dem Arbeitsspeicher.

Das Bedrohungsszenario wirkt für mich aber eh total konstruiert, daher macht der #wontfix für mich durchaus sinn.

 

[Beelzebot]

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ß, vielleicht der @SVΞN ?