easy-rsa
easy-rsa copied to clipboard
Avoid storing password in insecure disk file
mktemp create a world readable file in /tmp to temporary save CA password. An attacker could either read this file during build-ca or retrieve it afterwards directly from disk blocks if not overwritten.
Now it uses named pipes accessible only to owner inside pki dir.
Signed-off-by: Luiz Angelo Daros de Luca [email protected]
Splitting from #213
Fixing #230 might break this PR. :-/
#230 is independent of this PR. Fixing shellcheck warning
This is still an issue but I'll wait for #240
Rebased on #312 (for obvious reasons) Ideally, mkfifo should be available (somehow) for windows as well.
How does this effect this PR https://github.com/OpenVPN/easy-rsa/commit/4463e1d08fd7eebaa73f7d79634b93d1e34d7b42
How does this effect this PR 4463e1d
That alternative easyrsa mktemp is still non-secure. mktemp(1) does extra steps to make sure that it creates a new file and not reuse an existing one (https://github.com/coreutils/gnulib/blob/3c99da63be95a3bc6cc881e1ca6c849a921569e1/lib/tempname.c#L177). The new easyrsa code simply creates a random temporary filename and assumes that is enough. If that tmp dir is world writable (like /tmp with +t), a malicious user could create all the possible values (16M variants) for an temp file as a file or a symlink and wait easyrsa to write the password.
For some time, I only use temporary directory (which windows mktemp does seem to work with) and put all my temp files inside that directory. It is easier to cleanup all of them together at the end of the script.
EasyRSA could have EASYRSA_PRIVATE_TEMP
?
Apply that to all private data, as an advanced option. Then point it where-ever you like.
EasyRSA could have
EASYRSA_PRIVATE_TEMP
?Apply that to all private data, as an advanced option. Then point it where-ever you like.
If you will protect part of temp files, there is no reason for not doing it for everything. There is no need for that.
EasyRSA already creates a tmp dir inside the user provided dir. But it is purely focused on making cleaning easier, without improving security. When you define the directory beforehand and create it, you leave an opportunity for an atacker to create that directory under their control between those two steps. it was assuming that each temp file would be securely created. But 4463e1d made the temp file creation even less secure.
My suggestion is to either securely creste the session tmp dir (relaxing the security needs for temp files insde it) or use a secure way to create temp files (mktemp) as much as possible. I don't believe standard shell can securely creste a temp file without a dedicated program. It needs to create a new file atomically, avoiding collisions with existing files.
The current tmp session dir is intentionally insecure to allow a subshell create it under demand, avoiding excess useless writes to disk. Too much writes might wore off some embedded device flashes
@luizluca can you rebase or even resubmit, please.
I am considering reverting https://github.com/OpenVPN/easy-rsa/commit/4463e1d08fd7eebaa73f7d79634b93d1e34d7b42
@luizluca Please take a look at #535 - Comments welcome.
I am considering reverting 4463e1d
I would. EASYRSA_TEMP_DIR_session is not a secure temporary directory but merely a way to make it easier to cleanup the temporary files in a single step (mktemp -u is never secure). The security precautions were delegated to the mktemp that was creating files inside EASYRSA_TEMP_DIR_session. The windows case is just a workaround that introduce a security issue (race between "mktemp -du" and the actual file creation) to workaround a even worse security and functional issue (no random file at all). However, the UNIX code was still secure. Using a simple random to create tempfiles is just naive.
@luizluca can you rebase or even resubmit, please.
Only the https://github.com/OpenVPN/easy-rsa/pull/232/commits/396149d54e87bf71126693c81dbb50829d060a93 from this PR wasn't merged. I'll wait for the fate of https://github.com/OpenVPN/easy-rsa/commit/4463e1d08fd7eebaa73f7d79634b93d1e34d7b42 . As an attacker, if I noticed easy-rsa is in use, I would definitely test every unused disk block data as a possible ca password.
As I cited in the commit message, ideally easyrsa should bundle a mkpipe-alike for Windows. A quick google show me https://github.com/psmay/windows-named-pipe-utils, that might be an option (but I don't know if it was built with security in mind). Using a secure pipe would prevent sensitive data to be written to the disk. Windows might have a way to store a temporary sensitive data in a secure, volatile storage, but I'm no Window dev.
@luizluca
Do you know the reason why EasyRSA uses hide_read_pass()
?
Why not use the SSL library to hide the password on screen ?
I have lightly tested this and it seems to work as expected without hide_read_pass()
.
@luizluca
Do you know the reason why EasyRSA uses
hide_read_pass()
?
Because read -s failed in some OSs (Windows or BSD).
Why not use the SSL library to hide the password on screen ?
You'll need to ask the same password multiple times. It was used to generate the key and the ca certificate. If a newer version of openssl can do both at the same time with all easyrsa possible option, the hide_read_pass could go away.
I have lightly tested this and it seems to work as expected without
hide_read_pass()
.
It works but it would ask the ca password three times.
e2a8b78d9a6ad9aa8352ba795b1d8c00f70efe96 "workaround win32 mktemp bug" has been resolved.
396149d54e87bf71126693c81dbb50829d060a93 "Avoid storing password in disk file"
This change strikes me as too complex for Easy-RSA (Simple shell based CA utility).
There is a simple solution to the problem of a disk file, which is to point $EASYRSA_TMP_DIR to a RAM disk.
Simple solution provided. Closed.