This feels like a case of "It rather involved being on the other side of this airtight hatchway"[1]. If you can read arbitrary process memory, you're probably also in a position to just dump out the passwords by pretending to be the user in question.

> 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 logic is perfectly aligned with the Chromium threat model. Once an attacker gains administrator access, it is game over by definition.

I doubt this is an Edge-specific issue. Microsoft has no interest in making their browser less secure than its upstream.

> Why aren‘t physically-local attacks in Chrome’s threat model?

> We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

https://chromium.googlesource.com/chromium/src/+/148.0.7778....

In recent years we've also had browser-exploitable vulnerabilities that allowed reading arbitrary memory as a regular user, but slowly or without full control over the locations. I think wiping credentials as soon as possible after use is a very sensible precaution, even if it's only a moat.

Security isn't black and white. If i leave a post-it note of my logins on my monitor, that's definitely less safe than in a unlocked drawer, and so on.

Have we already forgotten Cloudbleed [0]?

[0] https://en.wikipedia.org/wiki/Cloudbleed

Agreed. I keep seeing "high priority" "vulns" that require so much system access to actually exploit that they become pointless. If an untrusted process can read your memory or run as an administrator you have already lost.

It honestly feels like more and more "security" people and businesses have less interest in actually securing systems and more in marketing themselves and their business hence the tendency to make every niche attack into a five alarm fire.

All true, but it is still bad style. There is no need to keep decrypted passwords in memory the user hasn’t even used in the session (or after they logged in to a certain website).

So as a user, when I go to paste any password, I first need to log in with biometrics, yet any random user process can just snag the password from memory?

What am I missing here?

So you're saying it's an Edge case?

Reading arbitrary process memory can be done as a standard user. No admin needed. Any Win32 program can do it. You just can't access the memory from processes that are admin-level.

This is a fallacious belief. While there is not point in obscurity, there is much value in not making it trivially easy to read passwords, as most exploits (especially of chromium) are not full user compromise, but the ability to massage some memory structures and read/write specific interesting bytes.

Additionally, the passwords could be kept encrypted in another process, and decrypted on demand, essentially a password vault. This lets you use techniques like biometric or physical button approval for password use, and reduces the likelihood of a browser memory dump containing passwords.

File audit capabilities in the OS can also be tuned so that only the vault application should be reading the vault file. Make info stealers job difficult.

>If you can read arbitrary process memory, you're probably also in a position to just dump out the passwords by pretending to be the user in question.

This is the load bearing argument and it is false.

There are plenty of circumstances were you can grab a piece of process memory but not all of it.

There are plenty more circumstances where you can grab process memory but not kernel memory.

There are plenty more (almost all) where you can dump kernel and process memory but you can't access the keys stored in the TPM module.

Leaving the door open for anyone with the smallest exploit is stupid and bad security.

They want obscurity and think it's security. Everything needed to get the passwords must be present in memory but they don't want to be able to actually see the passwords directly.

There's little hope of protecting against a snooper seeing the passwords you actually use, since they have to exist in plaintext at some point. But there's no reason to expose the entire password database when no passwords are even being used.

This is 100% that case. Basically every form (like this very one I'm typing in) is held in userspace memory un-encrypted. And yet lawyers and doctors and CIA operatives all use forms to type very sensitive stuff in.

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.