Gnome-shell-extension-gsconnect: SECURITY: Clearing desktop's clipboard does not clear it on device

[HenrikBengtsson]

Describe the bug

I have clipboard syncing to the device in GSConnect. This allows me to paste the current content of my desktop's clipboard on my Android device - awesome. However, clearing the desktop's clipboard (e.g. xsel --clipboard --clear), does not clear the clipboard on the Android device.

Not synchronizing the clearing of the clipboard can be a security issue in cases when you populate the clipboard with sensitive content. More specifically, password managers such as KeePass allows you to add your username or password to the clipboard for 10 seconds after which it will clear the clipboard. However, with the current behavior of the GSConnect Clipboard Sync, this password will remain on the Android device's clipboard.

Steps To Reproduce:

1. Go to 'GSConnect', click ''Clipboard Sync' and enable [x] 'To Device'
2. Copy MY_SECRET_PWD to desktop's clipboard
3. Call xsel --clipboard --clear to clear desktop's clipboard. Verify that with 'Paste' that it is empty on the desktop.
4. On the device, perform a 'Paste'. This will still paste MY_SECRET_PWD despite it being cleared on the desktop.

Expected behavior

1. On the device, perform a 'Paste'. This should paste an empty, zero-length string (or nothing).

Screenshots

N/A

Support Log

N/A

System Details (please complete the following information):

• GSConnect version: 26
  
  
  
  • Installed from: Ubuntu Software (client)
  
  
• GNOME/Shell version: 3.28.2
• Distro/Release: Ubuntu 18.04.3 LTS (up to date)

GSConnect environment (if applicable):

• Paired Device(s): Moto X4 (Android 9)
• KDE Connect app version: 1.12.93 (installed from FDroid)
• Plugin(s): clipboard

Additional Notes:

Related to https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/151#issuecomment-401631885

A manual workaround is to remember to copy random content to the clipboard after having used password managers such as KeePass.

I can also imagine reaching out to all password managers and similar software and have them change from { copy pwd -> clear clipboard } to { copy pwd -> copy single SPACE -> clear clipboard }. However, even if one can convince lots of them, there will always be some tool where this is not known. Also, this would basically mean we need to convince various windows managers to do the same, including the xsel tool etc. So, not really a solid solution.

PS. I'm a first time user. This is great tool. Thanks for all your work on this.

[ferdnyc]

Seems reasonable. I can certainly see the security implications if the clipboard data is allowed to persist _indefinitely_ on the far end, even after the local clipboard has been cleared.

TBH I'm not even sure whether to label this as a bug or an enhancement. :laughing:

I can also imagine reaching out to all password managers and similar software and have them change from { copy pwd -> clear clipboard } to { copy pwd -> copy single SPACE -> clear clipboard }.

Enh, that wouldn't be a particularly robust solution anyway. Doing it that way, you'd probably end up having to insert a delay between the second and third clipboard updates, to ensure that the single-space-character copy doesn't go by so fast that any listeners might miss it. (In particular, the ones that will ignore the subsequent clearing of the clipboard.)

Plus, if we're being _really_ security-conscious, instead of a space character you'd want to copy a random string that's at least as long as the previous clipboard contents, to ensure that the sensitive contents are completely overwritten even in any code that stores all clipboard data it receives in the same chunk of buffer memory.

Easier to just propagate all clipboard updates, if possible, even when that update is to an empty clipboard. That appears to be what kde-connect does, broadly. In their clipboard handler the contents of a clipboard update are only subject to a single test: whether the new value is the same as the stored previous value. If that's not the case (the clipboard actually changed), any and all changes are propagated.

[andyholmes]

I think this is related to #509 and #500. We currently ignore the clipboard being emptied on purpose, to close #500.

We'll have to decide what to do, or if there's a better solution.

[ferdnyc]

@andyholmes

It's interesting, because #500 was about clipboard updates to non-textual content (screenshot images) being propagated as the literal _string_ null... maybe the right disposition, instead of ignoring them, is to treat those updates _the same_ as the clipboard being cleared. So, maybe:

// Instead of...
 if (this._localBuffer === null)
        return;

// We do...
if (this._localBuffer === null)
        this._remoteBuffer = "";

? I don't think it would be too objectionable if copying an image to the local clipboard _cleared_ the device's clipboard — that actually would make a lot of sense, if the image can't be synced. Setting it to the word null was the thing that pointed to incorrect behavior, seems like.

[ferdnyc]

Setting it to the word null was the thing that pointed to incorrect behavior

Ugh. No pun intended, I swear. (That would be an awful one.)

[andyholmes]

Yeah, clearly what was happening is null was being coerced to a string, but the behaviour was essentially the same. I'm pretty sure the user's gripe was about the clipboard being cleared.

To be honest I think using the clipboard to copy anything sensitive is super sketchy, but one solution is just to set keyboard shortcuts and only sync the clipboard when necessary.

[ferdnyc]

Yeah, clearly what was happening is null was being coerced to a string, but the behaviour was essentially the same. I'm pretty sure the user's gripe was about the clipboard being cleared.

Is there a (relatively easy) way to differentiate between a non-text clipboard update, and the clipboard being intentionally cleared? If _not_, then they may have to suck it up and deal with the clipboard being cleared when they copy images to it. I mean, if the image _were_ propagated, the previous contents would be lost all the same...

(And while I generally agree, re: sensitive data on the clipboard, we know people are still going to do that anyway, so failing to clear our propagated copies of those sensitive contents becomes _something_ of a security concern, arguably.)

[andyholmes]

There is gtk_clipboard_wait_is_text_available (), although I've never tried it and it's unclear exactly when it returns a positive. For example, when the clipboard has been cleared versus overwritten with some non-text content (if there's a difference).

PS, did you get my note about finding a place to talk shop?

[andyholmes]

I still haven't investigated if we can check the clipboard content type, but I'd like to figure that out and resolve this one for the next release.

[andyholmes]

Okay, so I've spent some time looking at this and the good news is we can get a list of possible formats available on the clipboard. For reference, here are some examples:

"Regular" text
TIMESTAMP,TARGETS,MULTIPLE,SAVE_TARGETS,UTF8_STRING,COMPOUND_TEXT,TEXT,STRING,text/plain;charset=utf-8,text/plain

Rich Text (rtf)
TIMESTAMP,TARGETS,MULTIPLE,SAVE_TARGETS,application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)",text/rtf,text/richtext,text/html,text/plain;charset=utf-16,application/x-openoffice-link;windows_formatname="Link",application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="8BC6B165-B1B2-4EDD-aa47-dae2ee689dd6";typename="LibreOffice 6.3 Text Document";viewaspect="1";width="16999";height="2995";posx="0";posy="0",text/plain;charset=utf-8,UTF8_STRING,STRING,application/x-libreoffice-internal-id-62060

PNG (copied from Firefox)
TIMESTAMP,TARGETS,MULTIPLE,SAVE_TARGETS,text/html,text/_moz_htmlinfo,text/_moz_htmlcontext,image/png,image/bmp,image/x-bmp,image/x-MS-bmp,image/x-icon,image/x-ico,image/x-win-bitmap,image/vnd.microsoft.icon,application/ico,image/ico,image/icon,text/ico,image/jpeg,image/tiff

URI List
TIMESTAMP,TARGETS,MULTIPLE,text/uri-list,UTF8_STRING,COMPOUND_TEXT,TEXT,STRING,text/plain;charset=utf-8,text/plain

Empty Clipboard
text/plain;charset=utf-8,TARGETS,TIMESTAMP   OR   null (actual NULL byte)

So, we can sort of tell if the clipboard is empty, although that really means something like _"the clip owner that X would query for the clipboard content no longer exists"_. Presumably the clip owner may set the content to a literal NULL byte (which I guess isn't a utf8 string but is a valid 0-length C-string) until it disappears a bit later (and we actually get the NULL byte as a return).

So I'm assuming an acceptable solution is to:

• Clear the remote clipboard if the local clipboard is actually empty
• Don't send non-text (eg. images), serialized formats (eg. RTF/HTML/etc) or URI lists (eg. files copied in Nautlius)
• Don't clear the remote clipboard if the local clipboard contains one of the above types

Sound good?

[andyholmes]

This should now be fixed in the manner described above, however it does come with some caveats as described in the commit message, and may contain some regressions I didn't encountered during testing.