User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Windows: Tried to extract Firefox Passwords via Processhacker - since it works for Chrome too

Blogpost/Guide: https://www.cyberark.com/resources/threat-research-blog/extracting-clear-text-credentials-directly-from-chromium-s-memory

Actual results:

Windows: Extracted passwords via Processhacker - since it works for Chrome too

Expected results:

Windows: I shouldn't be able to extract the Passwords - and it shoudn't it work for Chrome too

Tested OS: Windows 10 64 Bit

Hi Security-Team,

whatever decision you take (aka WontFix) - if someone (you or Microsoft) doesn't tackle this - and the dmg / skill ratio for this is way too low - I guarantee you this will take over and do lots of dmg.

Credits for this1 go the original Emotet Malware Authors and the Cyberark Folks!

Setting this as NEW and moving to Core: Security to have the developer's opinion on it. If this is not the right component, please feel free to move it to a more appropriate one. Thanks

:pdolinic thanks for filing this bug!

As you already guessed it will be closed as WONTFIX, but let me explain reasoning behind this first.

This is how Windows process model is designed and works. Any process can read memory from other process under the same user. Microsoft tried/tries to move to the better architecture (UWP) where processes can't read each other memory easily. It takes time. This problem should be solved at OS level, but I can't speak for Microsoft here.

Certain password managers are trying to configure their process memory in a way that other processes can't read it. While it's not as easy as opening a memory scanner tool, it's still quite easy to override and undo these configurations. More aggressively cleaning memory is a nice thing to do, but if there is a password in memory at some point in time, attacker would just wait for this point in time.

Once attacker is able to run their code under victim's user account, it's game over. They can configure system to their benefit, can install keyloggers, can replace user apps with malformed version where any defenses are turned off and so on.

The cost of developing any of these protections is high, the cost of breaking through these defenses is low. Personally I'd love to implement a few of these protections, but it's hard to justify building a Maginot Line.

There are related bugs, like Bug 952869, that we want to implement, but it will only temporary reduce the number of passwords that attacker can retrieve. It will not fix the problem for real. So best defense is to keep your OS user account secured.