alt Hacker NewsThis 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....
Replies
It's a very standard defense-in-depth technique to put secrets between guard pages and only make the secret page readable when needed. That way any inadvertent access, be it programming error or exploit, simply causes a segfault, unless it's raced with a valid access (in a multithreaded or shm context) or the exploit explicitly changed the permission bits. Most memory disclosure vulnerabilities don't allow you to do that.
That being said any single password, when used, passes through so many layers and components that it's likely impossible to even just wipe the contaminated memory locations. But that's fine, the password database is opened for most of the browser's lifetime, any given password actively being used is a rare event in comparison.
Come on, they could still get a blood sample to really verify that its the user
> I doubt this is an Edge-specific issue.
It absolutely ain't Edge-specific. Firefox (AFAICT) also keeps stored passwords in clear-text unless encrypted with a passphrase (which is not the default on desktop; on Android there's a fingerprint/PIN check to access them, but I don't know offhand if there's any encryption involved with that).
Really this is true of most credentials stored within applications; unless you're providing a decryption key on open (whether explicitly or on OS-level login using some keychain mechanism), the stored credentials are probably plaintext.