I mean, this is why things like "secure elements" and "trusted platform modules" exist.
You have a piece of hardware that stores encrypted data, and it can't be accessed until that hardware is convinced that the operator is requesting the access. The simplest example is a U2F key. It will not even sign an authentication request for a website until it detects that a human operator has asked it to do so (by touching it while flashing). That prevents malware from authenticating on your behalf. (You can still be tricked into authenticating, through, and then the malware will just steal the cookie you got. That is why things like secure boot exist; if the hardware verifies the OS and the OS verifies the hardware, then you can be reasonably sure that security protections are in place and that random software downloaded from the Internet can't interact with secure areas of your hardware. Modulo bugs in the OS, which is hardly a guarantee given how complex they are these days.)
> Could you elaborate what you're talking about? Stealing passwords/sensitive info from Chrome temporary files?
Yes. Your browser stores passwords in a reversible format locally. If it's done well it may require root/ring0 privileges to abuse, but I'm unclear on how well local secret stores actually work for application-level secrets. However, if chrome temporary data becomes 100% secure I'll just steal all your documents, ssh keys and other application metadata - thus code exec is game over.
> How can one mitigate this threat?
Don't give me code exec on your box (eg don't run malware).
On a more actionable level, sandboxing every application should mitigate lots of malicious behaviors - iOS and (I've heard) chromebooks do this well, I think MacOS has some degree of sandboxing too. That being said, I don't think it'd be a practical solution for a 'power user' such as a web developer etc given the permissions power tools require are the same ones that are damaging in the hands of an attacker.
How can one mitigate this threat?