Xpra: Ticket #274: advanced clipboard filtering

At the moment, the only restrictions we have on clipboard data transfers are:

Any clipboard zlib-compressed data larger than 256KB is simply dropped with a log warning. Maybe this limit is too low? We can raise it with #275

It would be nice if we could inject more filters, say:

Thu, 28 Feb 2013 15:26:06 GMT - Antoine Martin: status, description changed

Thu, 28 Feb 2013 16:13:59 GMT - Antoine Martin: description changed

Thu, 28 Feb 2013 16:31:09 GMT - Antoine Martin: description changed

Here is a hardcoded regular expression filter which will block any string containing the word "virii":

--- src/xpra/platform/clipboard_base.py	(revision 2850)
+++ src/xpra/platform/clipboard_base.py	(working copy)
@@ -123,6 +123,10 @@
             ints = struct.unpack(binfmt, data)
             return "integers", ints
         elif dformat == 8:
+            import re
+            if re.match("virii", data):
+                log.info("virii string blocked: %s", data)
+                return None, None
             return "bytes", data
             log.error("unhandled format %s for clipboard data type %s" % (dformat, dtype))

This is just an example, but it shows how trivial it would be to pattern match the keyboard data and discard data. It only filters on the way out, but I don't think we really care about the way in: if you connect to a malicious server, surely you have bigger problems? We'll need to check every possible (..) clipboard transfer to make sure that data isn't transferred using some other encoding which would defeat the filter. Does it work with "utf8" and "latin1", what about other encodings?

Now, I'm not sure how we can make this customizable by the user, maybe:


With a list of regular expressions stored in this file? And maybe we could ship a default file too, maybe in /etc/xpra/clipboard-filter.re

Or maybe we want to have different actions (one per file, or specified for each regex): drop (just harmless stuff that we want to ignore), alert (dangerous stuff that we want to warn about), ..

The python regular expression module is documented here and supports all standard regex constructs.

Wed, 13 Mar 2013 17:08:10 GMT - Antoine Martin:

PoC in r2957 + r2958 - as per the man page update:

Name of a file containing regular expressions, any clipboard data
that matches one of these regular expressions will be dropped.
Note: at present this only applies to copying from the machine where
this option is used, not to it.

This is only hooked for the server: copy from server is filtered, copy from client is not. It probably makes sense to do that too?

Here's how to test:

echo virii > clipboard-filter.re
xpra start :10 --start-child=xterm --clipboard-filter-file=./clipboard-filter.re

That's assuming that you have a client with good clipboard support (ie: Linux) - if testing with win32, the ongoing bugs may interfere with the testing.

I think that we also need to look at filtering clipboard targets (similar to #273) or at the very least verify that the targeted applications cannot avoid the filtering simply by transferring the text using rtf/utf16/whatever.

Wed, 20 Mar 2013 14:22:22 GMT - Antoine Martin: owner changed

Fri, 22 Mar 2013 17:52:42 GMT - alas:

With an ubuntu (12.04) client the clipboard filter seems to work, but there is an element of confusion as attempts to paste yield nothing and no message. (For a few minutes I thought the linux clipboard was broken too.) For a user without a server display handy, you can imagine the reaction.

  1. One other interesting point- copying something including the element will also result in a drop. I copied viriibn and got nothing back out. Whether this is the behavior we're hoping for should be decided.

With a windows client, aside from the "expected" clipboard issues, the filter seems to drop copies from a browser window (chrome, whatever) but doesn't seem to catch/drop anything coming in from an xterm. (More headaches. Be sure to filter data transferring from Primary as well as Clipboard. (Is there a mysterious win client clipboard mechanism that is using different procedures that need to be found when getting data from Primary?) )

Sat, 23 Mar 2013 02:24:01 GMT - Antoine Martin:

I don't see much point in specifying "^virii$" to match the lone word exactly, but feel free to try it.

Sat, 23 Mar 2013 03:20:07 GMT - alas:

With a windows client, you can paste from an xterm's primary to the client. I'm not sure if that's a copy that I or anyone should really worry about filtering (as opposed to copying from browsers). I brought it up in case anyone else could (probably) think of a reason why it should be filtered.

If no one can think of a reason, then I guess this filter is functional, and remains only for everyone to try to maintain a file of all the things they'd like to filter from clipboard use.

Sat, 23 Mar 2013 05:58:17 GMT - Antoine Martin:

If you can copy anything from PRIMARY then this is a bug that I cannot explain (and cannot reproduce) and it should go under #272 not here (this ticket is about filtering). If that's the case and filtering does work as intended, then please close this one and follow up there.

Plase follow the simple steps below to see if it still copies data from PRIMARY, and if so, post the client clipboard debug output log by running both ends with XPRA_CLIPBOARD_DEBUG=1.

Here is how I test:

Extra tests:

Sat, 23 Mar 2013 13:40:09 GMT - Antoine Martin: attachment set

icon we could use to flash the system tray when content is blocked

Mon, 25 Mar 2013 20:02:53 GMT - alas: status changed; resolution set

I can still copy from xterms to windows client. I've commented that in 272. The clipboard filter seems to work as advertised though, so I will close this as resolved.

Sat, 23 Jan 2021 04:50:16 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/274