[gnutls-help] Creating password protected private keys with certtool?

[Josef Wolf]

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
jw at raven.inka.de