I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default.
II. Less importantly, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:
1. Set dtrace probes on syscall::exec*:entry to fire whenever pass runs.
2. For each such run, save the arguments to pass (obtained in dtrace with copyinstr) and the pasteboard's contents[1], then poll the pasteboard for the next few seconds, and if it changes, save the new contents as well. Depending on the timing, I assume one or the other will be the password for the account described by the arguments to pass.
Finally, I'm not sure what the problem with Keychain here is supposed to be in the first place: after clicking "deny" about 1,000 times, the only passwords the suggested command
security dump-keychain -d ~/Library/Keychains/login.keychain
revealed on my systems were the blank ones, and my login keychain is not "locked". So I guess this means blank AFP and SMB passwords shouldn't be relied upon to provide meaningful security?[1] To access the pasteboard server, your "snooping agent" must run in the target user session's Mach bootstrap namespace. Running as root, this is easy:
launchctl bsexec PID /path/to/snooping-agent [snooping-agent-args]
should do the trick, where PID is the UNIX process ID of the appropriate loginwindow process (under normal circumstances this will be the only loginwindow with the target's EUID).Don't use -c then. Inherent weakness of clipboard.
> II. While I wouldn't personally consider it a "real" security problem, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:
This is ridiculous. Of course, if someone has root access they can do whatever they want.
Your technical comments are a bit overblown. If you're root, just replace the executable with a program that pilfers off the passwords. Easy as pie. But sure, you can also dtrace, or load a kernel module, or ... anything?
Not to mention, if you're root, you can just listen to keystrokes, or monitor browser logins, or sniff input fields, or take memory dumps of the whole system, or ... um... anything?
FUD.
As for root, while I completely agree, I guess I just prefer concrete examples. Even when running as root, one can never do "anything" for free, and costs are always important to security. Writing a dtrace script is much easier than reverse engineering...well, pretty much anything.
But I'm honestly more interested in how you feel your solution improves upon Keychain's security.
no, just trying to help you out by giving you my software.
> but open sourcing it would help get the ball rolling.
it is open source. what made you think otherwise?
> and not widely audited
it has been audited by security professionals.
And it's worth pointing out that the "other parts" have also been audited by security professionals.