On 10/11/2010 10:44 PM, Daniel Kahn Gillmor wrote: > It would help against the situation where the malicious client does > *not* have superuser access and cannot directly override the prompting > mechanism through other mechanisms.
This attack mode appears to me to be so niche that I don't see any point in defending against it. If my attack gives me local access I'm going to shoot for remote. If my attack gives me unprivileged access I'm going to escalate it to root. This is straight out of the malware playbook, and malware authors have a great many ways to achieve it. Heck, this doesn't even defend against an *unprivileged* attack. Give me unprivileged access to your user account I'll edit your .profile to put a .malware/ subdirectory on your PATH and drop my trojaned GnuPG in there. Once the malware executes, delete the hidden subdirectory, restore your original PATH, and send the passphrase it intercepted off towards my C4I server. And if we're assuming I've instead subverted an unprivileged non-user account (like a jailed service), then this "attack" is a nonissue, so why are we trying to solve it? This seems like an niche solution to a problem which, as of right now, is nonexistent.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
