| 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. |
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.