Hacker News Reader

Comment by scintill76 | Hacker News Reader

I cry a little when someone says something is wrong, without explaining how to do it right. What's insecure with this, and how should it be done instead?

View on HN

The default umode of /tmp is usually world-writeable, so files created like this could be manipulated by bad actors on the same system. Not so critical in this case, but it can be seen as "code smell"

This of course assumes you are running around an actual multiuser system without 1777 /tmp and 077 umask like it is 1989.

All the attacker has to do is:

  touch /tmp/pubkey.pem
  chmod a+w /tmp/pubkey.pem

before the victim runs the code.

No sticky bit, no restrictive umask, also no protected_hardlinks/protected_symlinks is going to save you.

Proof-of-concept code like this can't anticipate everything about the environment it's going to run in, without risking distracting from its point. I guess it would be better to just put the files in the current directory, to not encourage the use of /tmp. The script[0] looks safer.

While we're on the subject of the openssl tool and file permissions, I've been disappointed... On my system, this command creates key.pem word-readable: "openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes" I've been meaning to set my umask to fix issues like this, as I have rare need to let another user account access my files. On the other hand, there aren't supposed to be any other users on my systems, and it's more likely my browser will get pwned and have access to my self-readable private keys anyway.

[0] https://github.com/hannob/tlshelpers/blob/46c50b27adf79476ae...

rrix explained why it is bad. The safe way is to create the file using mkstemp (to avoid accidental collisions) in a directory owned by you (to avoid malicious collisions).

Reply on news.ycombinator.com