On Fri, May 16, 2014 at 07:31:18AM -0600, Daniel Kahn Gillmor wrote: > On 05/15/2014 06:22 AM, Josef Wolf wrote: > > Nikos, I'm not really sure whether this is a good idea. After all, insisting > > on regular files prevents against symlink attacks. > > can you describe what symlink attack you're concerned about in the > context of reading a password from a file? > > If the attacker is in control of the certtool invocation, they can > already specify an arbitrary file.
For a symlink attack, the attacker don't need to have control of the invocation of the tool. Instead, the attacker needs to guess the file name you are going to write to and create a link for that name that points to some place where you won't delete it. For example: if I happen to know that your wrapping script will write the template to e.g. /pki/CA/cert.cfg, I would create a symlink /pki/CA/cert.cfg -> /var/tmp/some-innocent-looking-filename Now you invoke your wrapping script and write the password to /var/tmp/some-innocent-looking-filename. When done, your wrapping script deletes the symlink instead of the file the link points to and the password is left for me to read when I come back the next time. With the check for regular files, you'd at least get a warning from certtool. Granted, I need write access to /PKI/CA for this attack to work. You might argue that once an attacker has FS-access everything is lost anyway. But this is exactly what the passphrase is good for: protecting the private key in the case somebody has FS-access. > If the attacker is *not* in control > of the invocation, then the user should be able to responsibly choose > the file that they're interested in without certtool risking opening the > wrong one. The problem here is the word "responsibly". For sure, _some_ people will think hard about it. But most people won't think at all about it. And even for those who think hard about it, certtool don't have a proper solution. All the examples of certtool invocation google finds are using fixed names for the template file. Even the example on www.gnutls.org/manual/html_node/certtool-Invocation.html uses a fixed filename for the template file! So I'd be willing to bet that 90% of the users won't think about randomizing the filename and make sure the file don't exist before they write to it. Not a single invocation example google finds even _mentions_ mktemp or something. You can bet that at least _some_ people will blindly follow recipes like they find them on the internet (e.g. blog.tremily.us/posts/X.509_certificates/) without even thinking about it. Please remember that security always has to deal with highly intelligent attackers and clueless or dumb users. This doesn't mean that all users are dumb. But _some_ definitely are. Call me paranoid, but in general, I don't think it is a good idea to store a password in a file. Even _if_ you do all sorts of checks and delete the file before actually writing to it: in the worst case the password can end up in unallocated blocks on the disk. > PS i also like the idea of being able to set it to a fifo, so that a > wrapper script around certtool can set up a program that feeds its input > to the fifo and the password never hits the disk. Named pipes? Please note that there's still a race condition here. The attacker might replace the fifo with a symlink after creation and before certtool-invocation. To prevent races, you need to pass an already-opened filehandle. Every program gets an already-opened filehandle passed for reading at startup: stdin. I'd rather pipe to stdin. This way, the attacker would have to attack either my wrapper or certtool directly. Or the OS. But that's a totally different story. -- Josef Wolf [email protected] _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
