10 ms·

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 a

• turtlebits 6mo ago
  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.
  • stouset 6mo ago
    If I leave a post-it note of passwords on my monitor inside a vault to which only I have access, it’s not a big deal. That’s the point of the “airtight hatch” metaphor.
    • Someone1234 6mo ago
      Right; but in the scenario of this Tweek, you've invited someone untrustworthy into the vault and are then freaking out because they can see the post-it note of passwords. It is inherently irrational. 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.
      • ignoramous 6mo ago
        > This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure Usually the confidential bits are hardware isolated away from the supervisor (host kernel/OS) in Enclaves/TEEs, Realms, Secure Elements, Security chips, etc.
        • jazzyjackson 6mo ago
          One more reason to use hardware-bound passkeys and not passwords.
          • Someone1234 6mo ago
            True. But then your hardware dies, and you're locked out of every account you own. It is objectively good security, but has a ton of usability headaches yet to be really solved. 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.
            • jazzyjackson 6mo ago
              oh lawd, yes it does come down to 'who has the power to reset your account', and very few people want to take the path of 'no one has the power' in the case of lost credentials.
            • alterom 6mo ago
              >your hardware dies Or your backpack gets stolen. Oops. I swear, people who idolize passkey security must never travel anywhere. PS: "just have more devices with passkeys", they invariably say. Yeah right because people are made of money, everyone has the forethought, and a 2nd laptop in the US is a great asset when you're in Poland and can't login anywhere.
              • StilesCrisis 6mo ago
                I've been avoiding passkeys but more and more websites are trying to push them, and one website I use now requires them. I've already got a password manager! I don't need to change everything again!
    • solidasparagus 6mo ago
      I think we've moved away from the secure perimeter thinking and towards defense in depth - if that list of passwords helps you get somewhere other than the vault, removing the post-it improves security. Vaults get infiltrated all the time - and often in partial ways like being able to see into the vault but not reach in.
      • dwattttt 6mo ago
        Defence in depth matters, but an analysis here shows that the same mechanism used to breach the outer layers (getting administrative access) can be used to breach the next layer (more thoroughly prodding Edge or Chrome to give up passwords).
  • gruez 6mo ago
    > 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. 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.
    • forgotaccount3 6mo ago
      > Having passwords on post-it notes does make certain types of attacks much easier. It also makes other attacks much harder. Namely I don't need to worry about some zero-day in my password manager.
  • RajT88 6mo ago
    The way to think about security is as a system of layers, each of which filters out ever more sophisticated attackers. 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.
    • cachius 6mo ago
      The Swiss cheese model. Each single layer has holes, but when stacked the combined hole area is minimized https://en.wikipedia.org/wiki/Swiss_cheese_model https://en.wikipedia.org/wiki/Swiss_cheese_model
      • ButlerianJihad 6mo ago
        That was an enlightening read, considering the colloquial meaning of "your firewall security is like Swiss cheese" https://en.wiktionary.org/wiki/Swiss_cheese#Noun https://en.wiktionary.org/wiki/Swiss_cheese#Noun What's next? A system so secure that you can drive a truck through it? A honeypot in the center of a wasp nest?
      • slow_typist 6mo ago
        The Swiss cheese model is what people use to sell you more 'security' related software systems that inherently involve more problems. (Also cheese is not very durable, even the kind without holes.)
        • LorenPechtel 6mo ago
          Swiss cheese applies to more than just security systems. Hiking with two GPS-capable devices is Swiss cheese.
          • slow_typist 6mo ago
            That is redundancy in my book. I don’t expect holes in my GNSS devices. And if you want to be sure, bring three, because two GNSS units with different readings are not very helpful.
  • yjftsjthsd-h 6mo ago
    Okay. Can you describe an attack / threat model where it would matter in this particular case?
    • keithnz 6mo ago
      isn't it at risk of any code pathway that somehow allows you exceed a buffer and read memory unbounded? Then a nefarious web page could capture that? That's a huge exposure surface.
      • Dylan16807 6mo ago
        I'm pretty sure a read exploit in a web page wouldn't be in the same process as the passwords. If you can cross over to the main Edge process, you can probably get it to remove any encryption it applied itself.
    • wat10000 6mo ago
      https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
• dvt 6mo ago
  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.
• Dwedit 6mo ago
  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.
  • dvt 6mo ago
    This is not true. The canonical way to prevent access is via PAGE_NOACCESS[1]. Obviously, running as admin or in kernel mode breaks the whole thing since you can re-call `VirtualProtect` on that page and open it up. [1] https://learn.microsoft.com/en-us/windows/win32/memory/memory-protection-constants https://learn.microsoft.com/en-us/windows/win32/memory/memor...
    • LtdJorge 6mo ago
      And if the malware is running as admin, you’re pretty fucked either way
      • munk-a 6mo ago
        Thankfully our recent experiences with OpenClaw have given us all a lot of faith that users are extremely diligent in what processes they allow access to what information.
    • Someone1234 6mo ago
      This is accurate as far as page protection goes. The problem is the largest threat model. 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.
• wat10000 6mo ago
  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.
  • hWuxH 6mo ago
    What's the threat model where not storing them all at once provides any benefit? If someone has admin it's already game over. Can just hook the browser to retrieve all passwords on demand.
    • wat10000 6mo ago
      An attacker might only have read access. Could be a read buffer overflow like Heartbleed, a partial sandbox escape, a sophisticated Spectre-type vulnerability, a cold boot attack, or something mundane like a core file taken from a crashed process that gets into the wrong hands.
• tardedmeme 6mo ago
  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.
• mintplant 6mo ago
  Have we already forgotten Cloudbleed [0]? [0] https://en.wikipedia.org/wiki/Cloudbleed https://en.wikipedia.org/wiki/Cloudbleed
• Lorkki 6mo ago
  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.
  • avereveard 6mo ago
    It's surprisingly hard to do the compiler or cpu may see a write without a read and optimize it away. Windows has a SecureZeroMemory and a few other barrier primitives but not all languages reach to it
  • giancarlostoro 6mo ago
    I wonder about those kinds of exploits that sit on a webpage, but what stops someone from injecting their payload on a sites login page? JS can grab the password in plaintext in such a scenario, at which point the password manager does not save you. Can we normalize Passkey more?
    • IgorPartola 6mo ago
      I think the point is that you can have arbitrary website read the browser’s memory so example.com can read the password for example.org and example.net.
      • traderj0e 6mo ago
        Or the computer's memory via Meltdown and Spectre-like attacks
    • anthk 6mo ago
      That's why I disable JS by default with UBlock Origin. And OFC never allow JS to acces your clipbaord.
• slow_typist 6mo ago
  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).
  • netrap 6mo ago
    So you decrypt each time you need it? What is the difference in the attack surface?
    • slow_typist 6mo ago
      What I don’t need doesn’t need to live unencrypted in my RAM. Of course I do. It is standard behaviour of iOS, and of a lot of password managers. If someone grabs my laptop and runs, at least they can’t capture my hn account.
• pibaker 6mo ago
  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.
  • userbinator 6mo ago
    Many of them also have vested interests in furthering corporate authoritarianism, which is why letting users have full control over their devices is considered a security risk to them.
• asdfman123 6mo ago
  So you're saying it's an Edge case?
• maxloh 6mo ago
  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.121/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model https://chromium.googlesource.com/chromium/src/+/148.0.7778....
  • NewsaHackO 6mo ago
    Come on, they could still get a blood sample to really verify that its the user
  • yellowapple 6mo ago
    > 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.
    • cromka 6mo ago
      Or unless you need to reenter password/offer fingerprint after certain amount of time. Which, I think, should be the actual standard, and typically is with the apps like Bitwarden.
• angry_octet 6mo ago
  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.
• cush 6mo ago
  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?
• colechristensen 6mo ago
  >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.
• jurf 6mo ago
  Yeah because Meltdown and Spectre [0] weren't a thing. [0] https://spectreattack.com/ https://spectreattack.com/
  • hWuxH 6mo ago
    If passwords are fetched remotely on-demand, you steal the account API key from memory. If they're encrypted, you steal the master password or decryption key. ... So what's your solution?
    • jurf 6mo ago
      I think it’s more about layers of defense being always better than relying on a single point of failure. IIRC those bugs could only steal data, not do remote execution. If you did not store even the encrypted passwords in memory, getting the password/key to them compromised would still keep you safe, or at least upgrade it to a timing attack.