[libertymcateer]

So, tell me what I am misunderstanding here:

* On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch..., which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has user-level permissions can access the Chrome passwords? Because Chrome is not available through the app store, it does not store passwords on the OSX keychain, which, again, correct me if I'm mistaken, requires higher permissions to read? So that, for instance, a malicious script that only had user-level permissions could not access the contents of databases encrypted with credentials stored in the keychain?

[sleepychu]

If the malicious script can execute arbitrary code as you then you're owned, essentially you always allow unsupervised use of your computer which as discussed is not part of the threat model.

[libertymcateer]

Right, but I believe I have seen the threat model I describe actually functioning in the wild - cryptoviruses that archive files on your local drive that are likely to contain passwords and then mail them to the C&C server.

Would local encryption of these password stores be a (potentially) effective protection against this?

[md_]

To expand on this (correct answer) very slightly, what you say (libertymcateer) is true but misses the other vector:

A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any other process at the same or lower security level; in OSX, at a quick Google, it looks to me like http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_c... may do the same.

So the attack that this opens up is to basically wait until Safari is running and loads the credentials into its memory--which it has to do to prefill the password field in a page--and then just read that memory from your code running in the same process in a different thread (which shares the address space). And if you don't want to wait, you can simply request the credentials directly from the Keychain API; Keychain doesn't know you're not "Safari" (since you're running in the same process) and will happily give you the credentials!

Now, there's still a small advantage to the DPAPI/Keychain approach, namely that it allows the OS to show approvals to the user ("Unlock the keychain?" dialogs or whatever), ensuring that the malware can only steal credentials while the user is present. There are some circumstances where a credential API is nonetheless useful. Offhand:

1. Cases where there's a test-of-presence ("Do you want to unlock the Keychain?") conducted by the higher-privilege process, and where approval is not routine (so that the user is not going to just click "OK"). Browser password autofill is not such a case, however.

2. Cases where there's a test-of-presence and the user assent is transactional (i.e. they see what they're approving and the approval is only good for that one action--as with Windows UAC).

3. Cases where the credential granted is a signature and not a bearer-token, and we find some advantage in the token itself being bound to the device. (IOW, the down-level process can steal a signature, but it can only use the signature for some limited use, and cannot steal the signing secrets, which never leave the privileged domain.)

So to get this right requires a lot of thought about things like broker processes, transactional approval, etc. I'm far from an expert in this, but hopefully the above makes some sense.

[libertymcateer]

Right - you are describing a very well written worm up at the top of your comment.

However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on this.

In other words, what I am saying is that you are describing a very nasty theoretical worm - I am, however, describing to you a family of worms that is currently out in the wild and causing a hell of a lot of damage, and, as far as I know, actually does function in the way I describe. Filecryptor viruses can be made / purchased by any script kiddy jerk these days, and it seems to me that they do not function in this very sophisticated way you describe, but instead may actually be stymied by local encryption of files with passwords in them. (Or, rather, the distribution of your passwords to the virus owner would be stymied.)

I would very much like to know if is accurate or not. I understand that the devil is in the details, but if it is true, then I stand by my point that it seems unwise (borderline indefensible) not to encrypt local password stores - as there is a known valid threat. If it is not true, then I stand corrected - which happens all the time.

Either way, I am deeply interested to know.

[md_]

I don't have a huge amount of exposure to current malware trends, to be honest--it's not the area I work in at the moment. So tl;dr I can only guess.

You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.

Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.

However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.

So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?

You get the point.

[libertymcateer]

Found it: the worm is called Dynacrypt.

Check it out and let me know what you think.

Edit: from the top google result on Dynacrypt:

>While the ransomware portion of DynA-Crypt, as described in the next section, is a pain, the real problem is the amount of data and information this program steals from a computer. While running, DynA-Crypt will take screenshots of your active desktop, record system sounds from your computer, log commands you type on the keyboard, and steal data from numerous installed programs.

>The programs and data that DynACrypt steals includes:

>Screenshots

>Skype

>Steam

>Chrome

>Thunderbird

>Minecraft

>TeamSpeak

>Firefox

>Recordings of system audio