KeePassXC does not warn about groups and entries with same UUID

[naglfar]

I seem to have managed to corrupt my database in some way or other: when I add new keys the database gets saved (new modified date in filesystem and all) but after locking and reopening the new key is gone.
When trying to open the database in keepass2android the app complains about duplicate IDs - sounds like this could be relevant. Is there anyway of fixing / debugging this other than creating a completely new database?

Debug Info

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.13.0
Debugging mode is disabled.

Operating system: Manjaro Linux
CPU architecture: x86_64
Kernel: linux 5.2.4-1-MANJARO

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.4

Enabled extensions:

• EXTENSIONS

[droidmonkey]

You can create a new database and drag and drop entries from the existing to the new.

[naglfar]

So, I think I might have identified and deleted the "corrupt" entry. I can add new entries, but - only on the root folder, and only one, meaning a newly created key will just replace the existing one after locking and reopening the database. This is also happens on a newly created database! To which I could not drag and drop, by the way.

Removing keepassxc files in ~/.config and starting fresh on a new database does not resolve the issues, so something is completely broken on my end. The only other noteworthy thing I could add is that I recently upgraded to a new pc running a Ryzen 3700x, which famously currently has RDRAND issues, but that seems kind of farfetched?

[droidmonkey]

Can you post a sample database that exhibits this phenomenon

[naglfar]

Sure, here is a new one I just created with the passphrase 'test':
testdb.zip

I added a new folder into which I added a new key 'testentry1'. After locking and reopening the folder was gone and the key showed up under the 'root' folder. Then I created 'testentry2' and 'testentry3', locking and reopening the database again in between. When I open the database on my end the only entry I see is number 3.

[droidmonkey]

The UUID that is being used for both entries and both groups is ffffffffffff4fffbfffffffffffffff which is far from being random. I am going to chalk this up to a hardware issue on your end. I created a new entry in the database that shows a UUID of 8bcbf2e1fc8a482cadf8c03970e48e8a

[Bulanowski]

I'm having the same issue currently. Every new entry / group has the same uuid, ffffffffffff4fffbfffffffffffffff

I also have a Ryzen 3rd (3600) and I'm also running Manjaro with 5.x kernel.
I've tried making new databases / editing old ones and the issue persists.

However I've tried keepass and gnome-passwordsafe on new databases, as well as the old one, and the issue doesn't occur.

Debug Info

qt5ct: using qt5ct plugin
KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.13.0
Debugging mode is disabled.

Operating system: Manjaro Linux
CPU architecture: x86_64
Kernel: linux 5.1.21-1-MANJARO

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.4

[droidmonkey]

This is clearly not KeePassXC. Likely the api that Qt is using to obtain random numbers for uuids is returning this bogus value. This is actually a pretty catastrophic bug.

[naglfar]

Currently waiting for ASUS to release a bios update with the new AGESA version which will fix the rdrand issues, I'll report back whenever that happens.
I just wanted to add that, regardless of where the bug actually originates, I think keepassxc should get a few more checks to warn the user if any kind of problem happens while adding or editing keys / saving the database (I think there has recently been a reported bug with read-only databases aswell). I didn't get hurt too badly since the only key lost was an easily recoverable website password, but since this is an application users are trusting with all of their (randomly generated) passwords, failing silently on any action is a really bad practice.

[droidmonkey]

Yes I do agree there. Technically your hidden entry is still in the database. The sub group was hidden from display.

[naglfar]

So for a quick heads-up, I just flashed the new bios and everything is back to working as intended now, so the rdrand issues were definitely at fault.

[droidmonkey]

Very interesting

[phoerious]

I hope this doesn't affect urandom as well?! Otherwise all your crypto would have been insecure, including TLS communications and your KeePassXC master seed and CBC IV.

[Takios]

I'm affected by this issue as well but interestingly enough the appimage version of keepassxc does not exhibit this behaviour while the version provided by my distro does (openSUSE Tumbleweed). Is it using a different API to get a random number?

[droidmonkey]

Could very well be. I am really disturbed that this bug impacting random number generation even was possible to exist! This is a huge issue that is going unnoticed in the tech sector.

[ghost]

I found this error too, using openSUSE Tumbleweed and a AMD CPU.

Every new entry that I created replaced the previous one. Even if the UI listed all the new entries, when closed and reopened, the database only contained the last created entry. Also, I could not drag & drop groups (folders) too (it was possible to start the drag, but the drop was ignored).

I thought it was a KeePassXC problem, but as pointed before, updating the BIOS solved the problem.

[pagdot]

I have the same problem with the same UUID on the same processor with Arch Linux. Which Bios update fixed the Problem?

The Ryzen 3000 generation seems to have problems with the random number generation.

[Takios]

@pagdot BIOS updates including the AGESA 1003ABB or later by AMD have the fix.

[phoerious]

Should we maybe use urandom for everything? As I understand, this issue affects hardware RdRand. Urandom does not use the hardware RNG by default, but Qt seems to be relying on it for simple rand operations.