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

Das ganze Thema wird hier gerade viel heißer gekocht als es gegessen wird:

Die Erklärung von Google ist absolut schlüssig. Sofern eine Kompromittierung des zugrundeliegenden Betriebssystem passiert ist, unabhängig davon ob lokal oder remote, ist sowieso schon alles zu spät. Ein verschlüsseltes Speichern der Informationen im RAM erfordert auch einen passenden Schlüssel zum Entschlüsseln der Informationen. Bei einer Kompromittierung des Gesamtsystems ist das nur eine weitere kleine Hürde, die man mit dem gleichen Angriffsvektor überwinden kann.
 
  • Gefällt mir
Reaktionen: Dark_Soul, Slvr, xlf12 und 6 andere
ZenMasterTM schrieb:
AMD wirbt doch mit ihrem Memory Guard, der den RAM vollständig verschlüsselt.
siehe https://developer.amd.com/sev/ "Uses one key per virtual machine to isolate guests and the hypervisor from one another." das schützt nur die vms untereinander und vor dem hypervisor. innerhalb einer vm bleibt alles beim gleichen.
 
  • Gefällt mir
Reaktionen: Dark_Soul, ZenMasterTM und Unnu
KamfPudding schrieb:
Mit dem hatte ich dann ein hoffentlich aufschlussreiches Gespräch als ich ihm erzählt hatte, dass ich theoretisch TAN freie Beträge vom Bankkonto seiner Frau abbuchen könnte.
Kann man denn nicht von jedem Konto dessen IBAN und Besitzer bekannt ist bestimmte Beträge (bis so ~ 50 oder 70 Euro) ohne explizite Zustimmung per Lastschift abbuchen lassen - weil die Zustimmung hier implizit gilt?

Jeder der sein Konto irgendwann mal für irgendeine Überweisung genutzt hat oder darauf Geld durch irgendeine Überweisung empfangen hat, wäre davon auch betroffen :D
 
Zuletzt bearbeitet von einem Moderator:
KamfPudding schrieb:
Der "Hacker" kann sich die Passwörter auch im Chrome direkt ansehen. Wer im Chrome seine Passwörter speichert, hat die Kontrolle über sein Leben verloren.
Ein ehemaliger Kollege von mir hatte in seinem Browser Passwörter zu Online Banking, Amazon, einfach allem gespeichert. Mit dem hatte ich dann ein hoffentlich aufschlussreiches Gespräch als ich ihm erzählt hatte, dass ich theoretisch TAN freie Beträge vom Bankkonto seiner Frau abbuchen könnte.

Ich habe vor einem Jahr mal einen ganzen Laptop gekauft, wo in in allen installierten Browsern noch die Passwörter gespeichert waren.
U.a. für PayPal und Amazon.

Habe dann die HDD ausgebaut, weil eh eine SSD rein sollte und dem Verkäufer zurückgeschickt.
 
  • Gefällt mir
Reaktionen: Alphacrypt, cruse, Geringverdiener und eine weitere Person
Viel Wirbel um nichts in meinen Augen. Der Browser braucht diverse Daten wie Session-Cookies halt im Klartext. Wenn es im RAM verschlüsselt werden würde, muss auch eben dieser Schlüssel irgendwo im Speicher liegen den man ebenfalls mit abgreifen kann. Man würde damit nur eine Indirektion schaffen und nichts wirklich gewinnen.

Was man machen könnte, wäre die PW-DB zu verschlüsseln und immer nur für einen kurzen Zeitraum zu öffnen und danach wieder "alles vergessen" und im RAM überschreiben. Das würde aber auch bedeuten, dass man bei jedem Login z.B. das Master-PW eingeben muss. So handhaben das im übrigen gute Passwortmanager.
 
  • Gefällt mir
Reaktionen: Unnu und Piktogramm
StardustOne schrieb:
StardustOne schrieb:
Google und Sicherheit in einem Absatz zu nennen ist sowieso schon falsch. Google kümmert sich einen Furz um die Sicherheit der Nutzer. Die interessieren sich einfach nicht dafür und das hier zeigt es mal wieder ganz deutlich. Die sind nur an ihrem Profit interessiert und an sonst nichts. Ansonsten würde man seine E-Mails ja auch nicht an GMail gegen Werbefreiheit und Speicherplatz verkaufen bzw verschenken, damit sie diese durchforsten können.
 
Kontroverse Meinung: Google denkt sich seinen Teil, mit Projekt Zero haben sie jahrelang die Industrie vor sich hergetrieben... Glaube nicht, dass sie einfach nur keine Lust haben.
 
  • Gefällt mir
Reaktionen: Unnu
Bei all der Kritik die hier an Browserpasswortmanagern geäußert wird... Gab es jemals einen Bug, der das auslesen von Passwörtern durch Webseiten ermöglicht hat?

Wenn nein, spielt es doch keine Rolle, ob das Passwort im Browser oder in Keepass o.ä. gespeichert ist. Das Angriffsszenario ist doch das selbe.
 
ZenMasterTM schrieb:
Aber ist nicht genau das das Szenario, dass in dem Artikel beschrieben wird?
Nein, mit Elektrisch meine ich tatsächlich Elektrisch, am RAM-Modul über die Kontakte.

In dem Fall hier liest man den RAM vom PC über Software aus, und die Betriebssysteme kapseln Prozesse nicht ausreichend voneinander ab, um das zu verhindern. Das ist ein OS Thema, das aber auch Probleme mit sich bringt. Beispiel war da Wayland, da Wayland die Prozesse voneinander abkapselt, sodass ein Programm nicht auf die Ausgabe/Anzeige eines anderen Programms zugreifen kann. Nur liefen die Ausnahmen anfangs nicht richtig, sodass man zB keine Screen Recordings machen konnte
 
  • Gefällt mir
Reaktionen: ZenMasterTM
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.

Man kann Dinge verschlüsseln für das Ablegen auf Festspeichern oder die Übertragung durchs Netzwerk. Aber für die interne Verarbeitung? Viel Spaß.

Wenn eine Schadsoftware die Möglichkeit hat, in den Arbeitsspeicherbereich einer anderen Software herumzuschnüffeln, dann ist es eh schon zu spät. Das eigentliche Problem liegt ganz wo anders.
 
  • Gefällt mir
Reaktionen: Bl4ckD3ath, cruse, allli84 und 7 andere
Spike S. schrieb:
Andererseits kann man auch fragen, warum das nicht einfach verschlüsselt im Speicher liegt und erst im letzten Schritt vor dem Eingabefeld oder Weitergabe im HTTP Post entschlüsselt wird?

Irgendwo muss es halt entschlüsselt werden?
 
  • Gefällt mir
Reaktionen: Unnu und pvcf
Marcel55 schrieb:
Man kann Dinge verschlüsseln für das Ablegen auf Festspeichern oder die Übertragung durchs Netzwerk. Aber für die interne Verarbeitung? Viel Spaß.

Wenn eine Schadsoftware die Möglichkeit hat, in den Arbeitsspeicherbereich einer anderen Software herumzuschnüffeln, dann ist es eh schon zu spät.
anscheinend kann ein prozess ja seinen eigenen speicher schützen (lassen). keepass z.b. weisst explizit darauf hin und erwähnt CryptProtectMemory und ProtectedMemory. ich vermute mal, die wissen schon, wie man sowas macht :)

der unterschied ist hier auch, dass eine schadsoftware hier keine besonderen rechte braucht oder andere lücken ausnutzen muss. jedes programm, das du sonst so startest kann potenziell die daten aus dem browser abgreifen.
 
Web-Schecki schrieb:
Was bedeutet das? Dass die Browser in einer VM laufen? Das erschwert dann ja nur das Auslesen, verhindert es aber nicht, oder? Denn auch da liegen die Sachen ja irgendwo im RAM, und wenn man auf den Host Zugriff hat und den der VM zugewiesenen Speicher auslesen kann, kommt man weiterhin daran.
Dass die Passwörter in einem geschützten Speicherbereich liegen, nicht der Browser. Der Browser ist dann der einzige "Prozess" der über eine API mit dem Passwortspeicher kommunizieren kann.
 
  • Gefällt mir
Reaktionen: Web-Schecki
cyberpirate schrieb:
Betrifft ja nicht nur Google.
Die haben sich aber bereits lautstark geäußert, das die kein Interesse daran haben, das zu beheben. Was mit MS und Mozilla ist, weiß man aktuell nicht.
 
Wie schon mehrfach geschrieben - An irgendeiner Stelle (aller spätestens wenn das PW bzw. das Session Cookie versendet wird) muss das Passwort im Klartext im Memory liegen.

PS: Bzgl. Keypass: Ja das Memory ist geschützt, aber sobald ich das Passwort kopiere bzw. irgendwo einfügen lasse ist es genauso unverschlüsselt - und damit ist der ganze Schutz "ausgehebelt" (ja ich kann immerhin nicht alle PWs auf einmal auslesen).
 
Zuletzt bearbeitet:
0x8100 schrieb:
der unterschied ist hier auch, dass eine schadsoftware hier keine besonderen rechte braucht oder andere lücken ausnutzen muss. jedes programm, das du sonst so startest kann potenziell die daten aus dem browser abgreifen.

Springt hier nicht das Antivirenprogramm rein?
 
Ich muss gestehen, ich hätte nicht gedacht, dass ein normaler Prozess einfach den Speicher eines anderen Prozesses auslesen kann
Ergänzung ()

ZenMasterTM schrieb:
Ich möchte gerne wissen, wie es auf der Hardware-Seite aussieht. Was für ein System wurde verwendet? AMD wirbt doch mit ihrem Memory Guard, der den RAM vollständig verschlüsselt.
Intel hatte mal Total Memory Encryption (TME) beziehungsweise Multi-Key Total Memory Encryption (MKTME) angekündigt, aber eine CPU, die das bietet gibt es meines Wissens nach noch nicht.

Wäre mit sowas das Problem gelöst?
Nein, wäre es nicht. Der Zugriff erfolgt scheinbar ganz normal über die Windows API im laufenden Betrieb. Diese HW Verschllüsselung hilft, wenn der Angreifer in der Lage ist, die Kommunikation zwischen CPU und RAM auf HW ebene mitzuhören, oder (Stichwort Cold Boot Attack) die Daten aus den RAM-Modulen anderweitig extrahieren kann. Aber aus sicht der SW liegen die Daten meines Wissens komplett unverschlüsselt vor.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ZenMasterTM und Piktogramm
Ihr hängt euch gerade an den Passwörtern auf, aber der wichtigste Punkt ist: JEGLICHE Authentifikation via Browser kann ausgelesen werden. Denn: NATÜRLICH speichert eine Anwendung ihre Variablen unverschlüsselt. Denn um die Zugangsdaten anwenden zu können, müssen sie ja unverschlüsselt zwischen Browser und Webseite übergeben werden. Selbst, wenn also die Cookies, Token und Passwörter verschlüsselt vorlägen, müssten sie zur Nutzung entschlüsselt werden, dem Zielhost zugewiesen werden und im Prozess für den Ziel-Host dann wieder via HTTPS-Verschlüsselung verschlüsselt werden.

Das KANN man nicht fixen, ohne massiv am Authentifizierungssystem des WWW zu schrauben oder Dingen wie der ME/PSP ("Sicherheitsprozessoren" innerhalb der CPU) zu vertrauen.

Ich bin mir nichtmal sicher, ob kryptographische Verfahren wie Authentifikation via TPM oder E-Perso sicher wären. Weil: Selbst WENN die Authentifikation erstmal sicher wäre, würde anschließend schlicht ein Cookie gesetzt, welches der Webseite sagt "Jo... passt. Der darf das." Und das kann man wieder abschnorcheln und jemand anderes kann mit den gleichen Session-Daten weiterarbeiten.

Daher waren in meinen Augen ja Sicherheitslücken wie Meltdown und Co so dramatisch. Bislang durften nämlich nur Prozesse mit den gleichen Userrechten im Speicher nach solchen Daten suchen. Mit Meltdown, Rowhammer und Co konnte das dann jeder. (Damals wurde ich nichtmal im Ansatz ernstgenommen.) :(

Regards, Bigfoot29

Nachtrag: Nicht umsonst gibt es z.B. Qubes-OS. Das packt empfindliche Dinge wie Browser in eine separate VM, so dass ein Auslesen der Daten aus anderen Prozessen deutlich erschwert wird. - Aber natürlich auch aus gegenteiligen Gründen, denn ein Browser ist auf einem Desktop-OS so ziemlich das größte Einfalltor für Schadsoftware überhaupt. ;)
 
  • Gefällt mir
Reaktionen: Felix94, FGA, Unnu und 3 andere
Zurück
Oben