#1872 Database.key world readable

[Martin Mokrejs]

Hi,
I recently installed app-admin/keepass-2.42.1 on Gentoo Linux and I wonder how did I manage to get the following file privs on my ext4 filesystem:

  -rw-r--r--  1 foo foo  177 Jul  7 23:36 Database.key
-rw-------  1 foo foo 3486 Jul 20 14:09 Database.kdbx

I wonder how come the key file is readable. Please verify the sources. My parent shell umask is 0077 enforced through "umask 077" in ~/.bashrc. I tried to reproduce it with a new database+key now but failed, however I am still looking for an answer how did this happen. Especially why one file is world readable and the other is not. Also, the directory they were placed in was "a+rx", which smells as well.

Thank you for your attempts to reproduce the issue.

[Martin Mokrejs]

Doh, I found it!

I did not start keepass manually from xterm cmdline (so from bash) but I used an icon in the xfce4 menu. Of course xfce4 does not read my ~/.bashrc.

So, I clicked "cancel" when asked to unlock an existing database. Then from the KeePass main menu I did: File -> New entry, that gave a window "Create composite master key" to specify new master passphrase. I set one, then I select to have a separate Keyfile/Provider, clicked "Create". I did NOT click yet the "OK" button of the "Create composite master key"window.

By running a shell command in the background I can already see what I got:

-rw-r--r-- 1 foo foo 177 Jul 25 20:38 /home/foo/Database.key

Please enforce secure file permissions before opening a new file. Check if you opened the file you wanted to (symlink redicrections). Only after that write key contents into it.

To workaround the existing bug, introduce a hack that new keepass versions will sanitize insecure file permissions on the next startup. I assume such users will need to be informed by the KeePass application that their keyfile was unprotected, and showing the original filestamps and permissions.

I assume quite a few people use their Gnome/KDE/Xfce4 and other window managers and who knows how many have insecure umasks.

[Martin Mokrejs]

And, I finished the "Create composite master key" window by clicking OK, then defining a database name in the next window, xclciking OK. Then leaving the application and letting it finally save the *.kdbx file. Then, again, I see what was created on disk:

-rw-r--r-- 1 foo foo 1870 Jul 25 20:55 /home/foo/Database.kdbx

[Paul]

KeePass does not manage file permissions, it just asks (net/mono) to create a file.
More importantly, key files are not secure by their nature. They are not meant to be available with the database unless you are present, via a USB / external map etc.

cheers, Paul

[Martin Mokrejs]

That is bad. The only secure way is to create a file, check what has been actually opened, alter file privs, then write into it.

The *.kdbx file had stricter perms because later, when I ran keepass from within my bash, it got overwritten with new contens while my umask 077 kicked in.

BTW, it looks like keepass creates a new file and then moves it over the original database file. So the issue with loose file permission will repeat whenever user launches keepass with loose umask. This is also quite unexpected, I would have hoped that once I change the file perms to my wish on a file, they will stay.

I am sorry but this experience is so sad that I will probably turn away from keepass. If net/mono is so crappy, then I do not understand how could one write a secure application if developer is unable to ask for strict file permissions from within application's code.

How many people have unprotected key files and database files?

[Paul]

KeePass uses file transactions, as you've seen, to guarantee no data loss when writing the database.

My database files are unprotected, but they have strong passwords so nobody will open them anytime this millenium.
File permissions are not security.

cheers, Paul

[Dominik Reichl]

KeePass/Mono creates files with the default permissions; I don't see a problem here. Like Paul wrote, key files should be kept separate from database files (for instance on a USB stick), and as we don't know where the user will store or copy the file to, using stricter permissions could result in problems.

However, I agree with your second point and have added this now; on Unix-like systems, file transactions now preserve the Unix file access permissions, the user ID and the group ID.

Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_190803.zip

Thanks and best regards,
Dominik

[Martin Mokrejs]

Hi,
thank you for your past answer, however, I still think Keepass should by default use umask 077 and offer an option to set a different umask on newly created files. I understand you think the enryption is strong enough but that still, creating a world-readable master key is bad. And making world-readable database is increasing the chances ... I jsut do not get why Keepass shoudl create files by default with open permissons.

[Paul]

KeePass cannot guarantee where you will save / keep your files. If you use a USB stick formatted as exFAT, no permissions are available and KeePass could not set them. Rather that attempt to work out if permissions are available and set them based on the OS, KeePass creates a simple file.

Reliably saving your data is much more important than hiding files.
If you want to hide the files, do it manually.

cheers, Paul

[Martin Mokrejs]

Still, an application should create a new file safely, with permissions given only to the current user. If the underlying filesystem does not support or fullfill it, it is "expected", like on FAT filesystems, but that is a different story. In general this will work correctly.

The application should open the file and try make it accessible only by the currently running user. It will work on most operating systems and filesystems.

https://www.cvedetails.com/vulnerability-list.php?vendor_id=12214

It used to be a good practice to create a new file with a random name, check it is not a a symlink to a crafted target, rename the file to the name you intend to have, set perms, append data to it.