> If an attacker gains administrative access on a terminal server, they can access the memory of all logged‑on user processes.
If an attacker has administrative access, they can also attach a debugger to every chrome process and force it to decrypt all the passwords. The only difference this really makes is in coldboot attacks, but even then it's still not clear whether it makes the attacker's job slightly easier, or allows an attack that's otherwise not possible.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure. No obfuscation will work, because the password manager itself needs to de-obfuscation it before use (and that memory too is dump-able).
All adding in-memory obfuscation does it make ignorant people feel better, while not moving the security needle even an inch.
Usually the confidential bits are hardware isolated away from the supervisor (host kernel/OS) in Enclaves, Realms, TEEs, Secure Elements, Security chips, etc.
I've seen orgs move to passkeys only, then offer reset-questions (e.g. city of first job, etc); because the Customer Service volume/workflow wasn't figured out.
Having passwords on post-it notes does make certain types of attacks much easier. For instance, coworkers hacking other coworkers, or people burglarizing the office. None of which really apply to the "If an attacker gains administrative access on a terminal server" scenario.
Continuing the analogy, what Edge is doing is like leaving cash in unlocked cabinets inside a vault, and what Chrome's doing is locking those cabinets with a padlock. Sure, having the padlocks makes the cash more secure, but if someone went through all the effort into breaking the vault (terminal server), a padlock probably isn't going to stop them. This is especially true nowadays with AI coding agents and ready-made stealers available for sale online.
It also makes other attacks much harder. Namely I don't need to worry about some zero-day in my password manager.
We should care about all kinds of attackers, and not assume that the protections against the most sophisticated will obviate the protections against the least sophisticated.
If you can cross over to the main Edge process, you can probably get it to remove any encryption it applied itself.
It would be stupid, wasteful, and overly-complex to encrypt forms just in case some malicious process somehow got ring0 access. In that case, a keylogger is likely more useful anyway. And you're fucked even if you are encrypting stuff (as keys are likely also somewhere in memory[1] and they need to be—gasp—unencrypted). There's no free lunch.
Stupid Twitter thread meant to rage-bait for engagement.
[1] They could also be on disk or on some peripheral, but still fully readable by a motivated-enough hacker.
[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...
If Process A and Process B are running in the same user context on a desktop OS, PAGE_NOACCESS is not a strong boundary by itself. Process B may be able to obtain PROCESS_VM_OPERATION/PROCESS_VM_READ, change the page protection with VirtualProtectEx, inject code that calls VirtualProtect inside Process A, load a DLL, attach as a debugger, duplicate useful handles, or tamper with the executable. That's the problem with same-user process isolation, it is a hugely leaky abstraction. There is no magical "just set this bit" fix.
On a desktop OS, once an evil process runs under the same user context, you are relying on process DACLs, integrity levels, code-signing, anti-injection hardening, and file-system protections. You can plug one path and still have several others.
https://support.microsoft.com/en-us/topic/export-passwords-i...
Nb. The above refers to KeePassX. No idea what the KeePass without the x is about. Naming things. So hard.
EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.
> Good examples of simple and safe password managers are keepass and keepassx
The fix isn't Edge Vs. Chrome. Vs KeePass Vs. Bitwarden, it is "How do I have my passwords exist in a different execution context than [evil process able to read all memory]?"
Android and iOS have an "answer" to this problem. Desktop OSs having all processes running side by side in the user's execution context, do not. It is only as secure as the least secure process running.
* I don't want to speak past my own experience so checking my work, Windows can store passkeys in a TPM if available but falls back to storing on disk... https://helgeklein.com/blog/checking-windows-hello-for-busin...
For example, here is a 2019 writeup from KeePassXC with similar notes: https://keepassxc.org/blog/2019-02-21-memory-security/ - even though they explicitly clear sensitive data, there is still a window of opportunity.
During my time working on confidential computing, we had a variety of demos showing similar attacks against lots of different datastores, scripts, etc. That's just how computers work and your options are very limited if this is part of your threat model (imo just confidential computing and, if you can handle the performance hit, fully-homomorphic encryption).
But you're correct that Chrome, Firefox, Edge, Lastpass, BitWarden, even Keepass have the same issue. It is an Operating System limitation, not a password manager problem.
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
I would think this is a local vulnerability assuming Windows works as other OSs.
mfro•1h ago
saghm•1h ago
mfro•1h ago
jazzyjackson•9m ago