pwsafe creates random files in home folder

[rwd2]

Steps to reproduce:

1) run pwsafe with any valid (or no ) arguments, for example 'pwsafe -ulpE test'

Expected result:

pwsafe runs and does not create any random files in the home folder

Actual result:

pwsafe runs as it should, but eacht time it exits it creates a single file with a random name with question marks, containing binary data, in my home folder. These files seem like they don't serve any purpose and are the result of some bug.

I have been using pwsafe for years this problem started somewhere in 2020. Tested it with current version ( 20181220-1 from Arch Linux AUR)

output of ls -al ~/

(...) -rw------- 1 user1 user1 1024 Sep 4 13:21 ?W???? -rw------- 1 user1 user1 1024 Sep 4 13:20 ??c

output of stat ~/*

File: �W��� Size: 1024 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 6292008 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/ user1) Gid: ( 1000/ user1) Access: 2020-09-04 13:21:17.047276447 +0200 Modify: 2020-09-04 13:21:17.047276447 +0200 Change: 2020-09-04 13:21:17.047276447 +0200 Birth: 2020-09-04 13:21:17.047276447 +0200 File: ��c Size: 1024 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 6291997 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/ user1) Gid: ( 1000/ user1) Access: 2020-09-04 13:20:17.720395830 +0200 Modify: 2020-09-04 13:20:17.720395830 +0200 Change: 2020-09-04 13:20:17.720395830 +0200 Birth: 2020-09-04 13:20:17.720395830 +0200

output of

strace -o strace.log -f -tt -s 512 pwsafe -ulpE test

https://pastebin.com/G49NCdaY

[hymie0]

So I see this in your strace log:

59936 13:20:17.727300 openat(AT_FDCWD, "\370\247c", O_WRONLY|O_CREAT, 0600) = 3
59936 13:20:17.729831 fcntl(3, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
59936 13:20:17.730006 chmod("\370\247c", 0600) = 0
59936 13:20:17.730203 fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
59936 13:20:17.730380 write(3, "e[\341,Q\251\320|O\nw;\350\345\246\243'\31\17\260\310n]\343~\27426\373\220N\345\247
[...]
\"+\332\346\364\16\373\324V\262\303\211\302\7\2131\4\350\377\362a\264r\322\330U"..., 1024) = 1024
59936 13:20:17.730609 close(3)          = 0

I notice that, after I run pwsafe , I end up with a file named ~/.rnd which is similarly 1024 bytes.

It looks like this is your problem -- instead of opening the file ~/.rnd , it's opening a file with a ... random name?

Not saying I can fix your problem, just that I can see it.

Do you by chance have an environment variable named RANDFILE ? The man page says that this variable is used to select the random number generator file.

[rwd2]

'$ env | grep RANDFILE' gives no result. I will ask on the Arch forums how to fix that.

[nsd20463]

Thanks for the strace --- it make this much easier to figure out. Comparing your strace with one where ~/.rng is created shows that this is indeed pwsafe trying to restore some prng state to openssl's prng. It also shows pwsafe complained about the value of RANDFILE, and never opened nor read ~/.rng:

59936 13:20:14.384750 write(2, "WARNING: pwsafe unable to seed rng. Check $RANDFILE.\n", 53) = 53

in this same location, my local pwsafe opens and reads ~/.rnd and then calls getrandom(2). RANDFILE can also be defined in your openssl.cnf

pwsafe is asking openssl for the name of the randfile (RAND_file_name(3)), and aha, there's a bug in handling the case where there is no rand file at all. I'll fix it in a minute. As a work around, set RANDFILE=$HOME/.rnd and if pwsafe is installed with SIUD set, remove that flag. Aka chmod 755 $(which pwsafe).

(Edited to add the bit about SUID)

[rwd2]

The workaround does not work. The cause was the pwsafe executable having setuid permissons.

Secure_getenv will return NULL when executed through setuid so $HOME and $RANDFILE are null so RAND_file_name is guaranteed to fail when used in an setuid binary.

(source: https://bbs.archlinux.org/viewtopic.php?pid=1924549#p1924549).

[nsd20463]

You and loqs are absolutely correct. When the OS sets up the SUID environment all environment variables not known to be safe (and RANDFILE definitely is not safe --- you could overwrite any file in the system with 1k of randomness with it) are cleared.

To use pwsafe with SUID you'd need to built your own with the 1-line fix https://github.com/nsd20463/pwsafe/commit/7cf95579fd0c0849749b1f1dcbd67ca143f76b61

---

With hindsight, my use of mlock() years ago (which is why SUID is needed) to prevent swapping out of the memory containing the secrets was the wrong trade off. In fact the BSD maintainer of pwsafe at the time patched the mlock out entirely, preferring that pwsafe was not SUID, because for them (and can I agree with the principle) fewer SUID binaries is better than the chance of the passwords ending up in the swapfile.

In this decade, my swapfiles are encrypted with a random, ephemeral key, and I don't worry about what gets swapped out being readable once power is cut. (Of course this also means my computers can suspend but not hibernate, but such is the price of security).

[rwd2]

Ok I built 7cf9557

Changed the permissions of the executable to setuid:

-rwsr-sr-x 1 root root 110K Sep 6 16:46 pwsafe

Bit still the same "WARNING: pwsafe unable to seed rng. Check $RANDFILE." error. Included is the strace of :

strace -o strace.log.1 -f -tt -s 512 pwsafe

https://pastebin.com/NGVcyee5

[nsd20463]

The warning is correct. There is no rand file, and there won't be one. The difference is that with the patch, you no longer get randomly names files in the current directory after running pwsafe.

[nsd20463]

And since you know why, you can safely ignore the warning.