Keepass logs plain text passwords in system log when clearing the clipboard
Created keepass tracking bugs for this issue: Affects: epel-all [bug 2053688] Affects: fedora-all [bug 2053691] Created keepassx tracking bugs for this issue: Affects: epel-all [bug 2053689] Affects: fedora-all [bug 2053692] Created keepassx0 tracking bugs for this issue: Affects: fedora-all [bug 2053693] Created keepassx2 tracking bugs for this issue: Affects: epel-all [bug 2053690]
Steps to Reproduce: Step 1: Run "journalctl -f" in a terminal window. Step 2: Double click a password in KeePass. Step 3: Wait for the clear timeout to trigger. Actual results: See your plain text password logged in the terminal window Expected results: Never see your plain text password logged anywhere
I am unable to reproduce this bug. I tried it on F35 with gnome (Xorg and wayland) and also Plasma (Xorg and wayland). Please clarify more detailed how to reproduce. Maybe clipit or something else is needed. As this bug is the root cause to orphan keepass from fedora, I propose to get a detailed info on how to reproduce (and therefore find ways to fix). If this bug is not 100% reproducable, we should un-orphan the package.
Created attachment 1899751 [details] POC Steps to Reproduce: Step 1: Run "journalctl -f" in a terminal window. Step 2: Double click a password in KeePass. Step 3: Wait for the clear timeout to trigger. Actual results: See your plain text password logged in the terminal window Expected results: Never see your plain text password logged anywhere
"Sorry, you are not authorized to access attachment #1899751 [details]. "
Created attachment 1899865 [details] POC
see also bug 1891592 which references https://sourceforge.net/p/keepass/discussion/329220/thread/33d6afdc/ The author of Keepass says it is written for Windows, and he does not care about Linux or Fedora. If someone finds a solution, well lets go for it. Otherwise we should get rid of keepass and use https://src.fedoraproject.org/rpms/keepassxc instead.
Thanks for all the provided information. If I am able to reproduce (currently I am not), then I will definititely create a patch to fix it and let you know here.
KeePassXC is not really an option for those of us who dual-boot and need browser integration. From what I was able to gather so far, Kee extension does not support KeePassXC. While KeePassXC has its own Firefox extension, this is probably going to be problematic if the extensions are synchronised across OSes. It would be great if this problem could be fixed. Both discussions on sourceforge [1][2] refer to Fedora specifically which is interesting to say at least. I tried running with selinux set to permissive but it did not help. [1] https://sourceforge.net/p/keepass/discussion/329220/thread/33d6afdc/ [2] https://sourceforge.net/p/keepass/discussion/329220/thread/da7546b7e1/
KeePassXC is also missing the KeePass2 feature called "Synchronize with File" which is useful in case you use more than one computer and keep passwords in one file. With KeePassXC and other alternatives you can only overwrite your *.kbdx file with a newer one which sometimes may cause data loss. In KeePass2 you can synchronize just the entries which changed in both local file and a received file (eg. on usb stick). Basically you can add some entries on computer 1 and other entries on computer 2, than open KeePass2 and synchronize those two files - changes are merged.
(In reply to Robert Bartecki from comment #22) > KeePassXC is also missing the KeePass2 feature called "Synchronize with > File" KeePassXC calls this "Merge From Database...".
> The author of Keepass says it is written for Windows, and he does not care about Linux or Fedora. That is not true. If you look into the changelogs of KeePass 2.x, you will notice that there frequently are improvements specific to Mono/Linux. My position on CVE-2022-0725 can be found here: https://keepass.info/help/kb/sec_issues.html#fdslog Best regards, Dominik (KeePass author)
I believe I could still reproduce it on F37 and F38, I will retest. Did you test with the fedora package or with the prebuilt binary? The issue might be caused by the packaging.
I can reproduce it on Fedora 38, but only when starting keepass from the packaged icon. mono /usr/lib/keepass/KeePass.exe or keepass from command line leak no information to the journal. I tried changing the Exec entry in the desktop file to either of the above (from keepass %u) but neither did help. The original reproducer seems to be with KDE whereas I am testing with gnome so DE appears not to be the culprit. I am experiencing this on both X11 and Wayland so it is not that either.
@zbyszek, do you have any idea why this might be happening? If not, whom do you think we could ask?
I have never used KeePass or its variants, but very superficially, this bug seems to be about the text "Password" and the actual password ending up in the system log. I don't think they are written there on purpose, but instead something (KeePass?) writes them to stdout, and stdout is connected to the journal. According to comment 26, this only happens when started "from the packaged icon", i.e. when the program is started as a background service. Recent versions of KDE and gnome start various services as systemd units under the user instance, and those units have stdout and stderr connected to the journal.
My guess would be that if the KeePass is started manually as in comment #26, stdout/stderr are connected to a tty, and the program doesn't write output to tty. Maybe it'd be enough to start it as 'keepass &>/tmp/log', run the steps from comment #16, and do 'cat /tmp/log'?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #29) > My guess would be that if the KeePass is started manually as in comment #26, > stdout/stderr > are connected to a tty, and the program doesn't write output to tty. Maybe > it'd be enough > to start it as 'keepass &>/tmp/log', run the steps from comment #16, and do > 'cat /tmp/log'? You are correct! Password appears in /tmp/log if I do this. Dominik, can you reproduce?
No, I cannot reproduce it. I just tried the following: 1. Install Fedora 38 (in a VM with clipboard sharing disabled) and all updates (using the 'Software' app). 2. sudo dnf install mono-devel 3. Download 'KeePass-2.53.1.zip' from https://keepass.info/download.html and extract it. 4. Open a Terminal and run 'journalctl -f'. 5. Open another Terminal tab and run 'mono KeePass.exe &>/tmp/log'. 6. Create a new database. Copy the password of the first example entry (the password is 'Password') to the clipboard and wait until KeePass clears it automatically (12 seconds). Do the same for the second example entry (password '12345'). Wait again and then close KeePass. When inspecting the journalctl output, the KeePass output (Terminal) and the '/tmp/log' file, I cannot find the passwords. The journalctl output mainly contains window manager warnings, the KeePass output (Terminal) nothing and the '/tmp/log' file only a 'Gtk not found...' message; nothing seems to be related to the clipboard. If xsel is installed, KeePass calls it for clipboard operations (transferring the data via stdin/stdout of xsel), because on some systems, Mono's clipboard methods do not work properly. On a new Fedora 38 system, xsel is not installed, thus I then installed xsel (sudo dnf install xsel) and repeated the test above, but the result is the same, i.e. I cannot find the passwords in any of the 3 locations.
Thank you for checking. Fedora package requires xsel so I have it installed. I can also reproduce the problem with the keepass binary from sourceforge and /tmp/log, the passwords appear in the said file. I will check what happens if I remove it. Do you also have xdotool installed? It is another requirement of the package: https://src.fedoraproject.org/rpms/keepass/blob/1425aa4b6f1e1f52bb9166aec3886498d57387de/f/keepass.spec#_30
I have now tested with xsel and xdotool removed. It appears that the problem is caused by xdotool. Without it only the following appears in the log: $ cat /tmp/log Gtk-Message: 17:25:53.335: Failed to load module "pk-gtk-module" with xdotool installed: $ cat /tmp/log Gtk-Message: 17:27:37.801: Failed to load module "pk-gtk-module" XGetWindowProperty[_NET_ACTIVE_WINDOW] failed (code=1) xdo_get_active_window reported an error xxxpasswordxxXGetWindowProperty[_NET_ACTIVE_WINDOW] failed (code=1) xdo_get_active_window reported an error
Interesting, thanks! With xdotool installed, I can reproduce the issue now. It is unclear to me where exactly the passwords come from, but it seems to be triggered by one of the clipboard workarounds (which involves calling xsel, xdotool and xprop in the background). Can you confirm that the issue is gone (even with xsel and xdotool installed) when running KeePass with the command line parameter "-wa-disable:1530"?
With -wa-disable:1530 the log contains no passwords: $ cat /tmp/log Could not set X locale modifiers Gtk-Message: 17:54:54.712: Failed to load module "pk-gtk-module"
The issue seems to be reproducible with xsel alone. Copy something to the clipboard and run 'xsel --clear --clipboard > /tmp/log'; the log file then contains the previous clipboard content. This doesn't happen on all systems; on Fedora 38 (GNOME/Wayland) it happens, but the log file is empty on Ubuntu 23.04 (GNOME/Wayland), Kubuntu 23.04 (KDE/X11), Mint 21 (Cinnamon/X11) and Manjaro 22 (GNOME/X11). I've looked into the source code of xsel, but don't have any idea what could be causing this, sorry. The root of the issue could also be outside of xsel. When testing xsel on the systems above, I also tested whether the clipboard workarounds in KeePass are still required. Fortunately, the methods of the Clipboard class (implemented by Mono) now work fine on the systems above. So, the workarounds probably aren't required anymore for most users. Therefore, the clipboard workarounds will be disabled by default in the next KeePass version (2.54, probably released in about 1-2 weeks). This avoids the CVE issue for KeePass. Here's the latest development snapshot, if you want to test it: https://keepass.info/filepool/KeePass_230525.zip If there are a few users who still need the clipboard workarounds, they can enable them explicitly with the command line parameter '-wa-enable:1530,1613'. In this case, the user should of course check whether the clipboard content is logged. Thanks for your help!
I am CCing xsel maintainer, maybe he can help.
From the man page and source code of xsel you can see, that this is specified behaviour: By default, this program outputs the selection without modification if both standard input and standard output are terminals (ttys). Other‐ wise, the current selection is output if standard output is not a ter‐ minal (tty), and the selection is set from standard input if standard input is not a terminal (tty). If any input or output options are given then the program behaves only in the requested mode. This means, that if stdout is not a tty, then --output is assumed and therefore clipboard is printed before doing --clear. You can see this in the source code of xsel.c /* Specify default behaviour based on input and output file types */ if (isatty(0) && isatty(1)) { /* Interactive mode: both stdin and stdout are ttys */ do_input = False; dont_input = True; do_output = False; dont_output = False; } else if (!isatty(0) && !isatty(1)) { /* Scripted: both stdin and stdout are NOT ttys */ do_input = False; dont_input = True; do_output = True; dont_output = False; } else { /* Interactive, pipelined: one of stdin or stdout is a tty */ do_input = !isatty(0); dont_input = !do_input; do_output = !isatty(1); dont_output = !do_output; } .... /* handle output modes */ if (do_output || !dont_output) { /* Get the current selection */ old_sel = get_selection_text (selection); if (old_sel) printf ("%s", old_sel); }
According to https://vergenet.net/~conrad/software/xsel/ it seems, that xsel has moved to https://github.com/kfish/xsel. There is already a xsel-1.2.1 available, which seems to have fixed that bug. The bug is, that "--clear" still does a "--output" because it stumbles over its handling with do_output and dont_output. So also updating xsel to 1.2.1 will fix this bug here.
I see; thanks!
Regarding as to why only Fedora appears to be affected: at least Ubuntu appears to ship 9bfc13d git snapshot from 2018. My educated guess is that the commit fixing the output logic is this one from 2010: https://github.com/kfish/xsel/commit/79748acf3045546a4d8ae444de99bb7a07d16eb7 Fedora, on the other hand, ships 1.2.0 with only a handful of patches: https://src.fedoraproject.org/rpms/xsel/tree/rawhide It still does not explain why on my machine both xsel and xdotool were needed to reproduce the problem. In any case, it appears that xsel is the culprit.
I can confirm that with 2.54 the issue is gone without having to disable any workarounds manually.
Great; thanks for testing it!
(In reply to Peter Oliver from comment #23) > (In reply to Robert Bartecki from comment #22) > > KeePassXC is also missing the KeePass2 feature called "Synchronize with > > File" > > KeePassXC calls this "Merge From Database...". Is it really the same functionality? KeePass2 can handle for example this scenario: https://www.reddit.com/r/KeePass/comments/uwbh1t/locally_syncing_open_keepassxc_database_between/
@mailinglists35, would you be interesting in unretiring keepass? My issue with keepassxc was insufficient cross-compatibility between the kee firefox extension and keepass2android. If not, I would submit an updated spec for review.
Hello @belegdol I have now started the unretirement ticket: https://pagure.io/releng/issue/11793 I would welcome you as maintainer or co-maintainer for keepass.
Would anyone be interesting in performing a re-review so that we can bring keepass back into Fedora?
Yes, sure! Just let me know, what to do.
If you are a packager, the steps are detailed here: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ If you are not, I am afraid you cannot help much at the moment, sorry.
keepass-2.55 has now been built in koji.
@belegdol Can you please also take care of https://bugzilla.redhat.com/show_bug.cgi?id=2053688. IMHO only a EL rebuild is needed.
I do not maintain epel branches for my packages, sorry. Please feel free to join as co-maintainer and take care of it yourself if you believe it has value.
xsel has now been updated in Fedora which means all the bugs in this dependency tree can be closed once xsel-1.2.1 hits respective Fedora/EPEL releases.
I have verified this by running: $ keepass -wa-enable:1530&>log.txt and inspecting the contents of log.txt