Use x-kde-passwordManagerHint when copying passwords to the clipboard to keep KDE's Klipper from writing it to plaintext history
Categories
(Core :: Widget: Gtk, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox142 | --- | fixed |
People
(Reporter: chris, Assigned: tschuster)
References
Details
(Keywords: reporter-external, sec-want, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Attachments
(1 file)
On Fedora 33 systems running KDE, there exists a process by which a password stored in the Firefox password manager (and third party password managers) may be written to disk in plaintext.
1.) Install Fedora 33 KDE (I used Fedora-KDE-Live-x86_64-33-1.2.iso, installed via UEFI on a Dell Latitude 7490) and go through typical new user setup steps.
2.) Launch Firefox, and save a password to any website into Firefox's built-in password manager
3.) Using Firefox's password manager, copy the password saved in step 2 to the clipboard, and immediately close Firefox
4.) Restart (or optionally shut down and turn back on) the computer using the Plasma restart menu option.
5.) Log back in and reopen any text editor, such as KWrite, and paste the contents of the clipboard using any means (C-v, Edit->Paste, etc). The password that was previously placed onto the clipboard in step 2 is pasted into the text editor.
The fact that the contents of the clipboard from step 2 (prior to the reboot) can be pasted into a text editor after a reboot is evidence that the contents of the clipboard were written to disk. On systems lacking full-disk encryption, this means that the clipboard content (ie: the password from step 2) is written to disk in plaintext.
I have reported this issue to KDE's security team directly, and their response was that this behavior was intentional. I was told that there is a metadata flag that can be applied when copying to the clipboard (https://github.com/keepassxreboot/keepassxc/blob/86278311d23b89322afddd98890385e2267c84cd/src/gui/Clipboard.cpp#L63) but to my knowledge KeePassXC is the only application on the planet that utilizes this.
Additionally, this bug was reported to Red Hat Product Security, originally on February 9, 2021, under incident INC1626643. Red Hat Product Security opted not to file a CVE on this issue, as they claim that the information cannot leak across a security boundary because the contents of the clipboard are stored in a user’s home directory, which is protected with file permissions of 0700.
While this does appear to be a bug with KDE and Klipper specifically, I am reporting this issue so that Firefox can mitigate this issue by implementing the “x-kde-passwordManagerHint” patch shown above. I have also reported the same bug to the Google Chrome team for mitigation using the same technique, as both KDE and Red Hat do not seem interested in fixing the issue upstream.
|
||
Comment 1•4 years ago
|
||
Summarizing a bit:
KDE's Klipper writes clipboard content to a history file on disk. Sounds handy, but is problematic for sensitive content like passwords. A few years back they implemented a hint password managers could use, because otherwise they have no context for what the user might consider sensitive or not. Firefox should use this hint in the about:logins copy-to-clipboard feature.
Here's where they implemented the feature
https://phabricator.kde.org/D12539
This is not a Firefox security vulnerability. This is a problem Klipper caused while implementing a feature for power users, and a hook they added that cooperating password managers could use to help Klipper protect users from the problem it caused. It could be a nasty surprise to users, though, and it should be a simple enough fix that it's worth looking into.
I can find enough written about this in public searches that keeping this bug hidden would be counter-productive -- if users know this problem exists they can take steps to protect themselves (e.g. turning off the Klipper history feature, using a different OS).
|
||
Comment 2•4 years ago
|
||
Password manager sounds like a really good use case for x-kde-passwordManagerHint. We use the nsIClipboardHelper's copyString method: https://searchfox.org/mozilla-central/source/browser/components/aboutlogins/AboutLoginsChild.jsm#124 - which AFAICT has no support for this kind of hint. Is there another service we should use or does this need to get implemented in Widget first?
|
|
||
Comment 3•4 years ago
|
||
Unfortunately this does not qualify for our bug bounty program.
|
||
Updated•1 year ago
|
|
||
Updated•11 days ago
|
Confirming that this bug still occurs on Fedora 42 KDE.
|
Assignee | |
Comment 6•5 days ago
|
||
|
||
Updated•5 days ago
|
|
|
Assignee | |
Comment 7•5 days ago
|
||
I tested this and it successfully prevents the CopyQ clipboard manager from adding the password in about:logins to the history. Of course this only works with clipboard managers that respect the x-kde-passwordManagerHint.
|
||
Comment 10•17 hours ago
|
||
Backed out for causing failures at SelectionActionDelegateTest..
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/662c31416c93f9aca2684916c63006fabb73771a
Failure log: https://treeherder.mozilla.org/logviewer?job_id=517790624&repo=autoland&lineNumber=2277
|
|
Assignee | |
Comment 11•15 hours ago
|
||
It still seems to fail after the backout: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=BrIw-aczQN-lqrWwI7ZfQQ.0
|
|
Assignee | |
Comment 12•15 hours ago
|
||
This code change is Linux/GTK only, so there really shouldn't be a way for it to cause Android tests to fail.
|
||
Comment 13•15 hours ago
|
||
|
|
||
Comment 14•15 hours ago
|
||
Relanded the push and backed out the real culprit.
Sorry for the trouble.
|
||
Comment 15•7 hours ago
|
||
| bugherder | ||
Description
•