advanced clipboard filtering

[totaam]

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

• size check:

MAX_CLIPBOARD_PACKET_SIZE = 256*1024

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

• some data types we drop rather than trying to handle (mostly picture formats, see macos to handle more clipboard formats, converting them on the fly #273)
• some targets we refuse to handle:

discard_targets = ("SAVE_TARGETS", "COMPOUND_TEXT")

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

• a regex filter for strings (client-side interpretation of encodings can make this very tricky)
• an external filter (virus scanner, etc)
• clipboard direction: clipboard direction restrictions: client to server only, server to client only #276

[totaam]

2013-02-28 16:31:10: antoine commented

---

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
         else:
             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:

--clipboard-filter=FILENAME

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.

[totaam]

2013-03-13 17:08:10: antoine commented

---

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

--clipboard-filter-file=filename
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

• attach from a client
• type "virii" in the xterm
• select "virii" with the mouse
• try to paste in the client
• you will see this message in the server log output:

clipboard buffer contains blacklisted pattern 'virii' and has been dropped!

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.

[totaam]

2013-03-22 17:52:42: afarr commented

---

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.

2. 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?) )

[totaam]

2013-03-23 02:24:01: totaam commented

---

• we may want to notify users - though it is tricky to get the balance right between annoying users with balloon messages and not showing anything at all: applications can choose when copying their data to the clipboard and there is technically nothing stopping them from copying 10 times per second or more (and maybe this can even be done via scripting?) and this would not be a pleasant experience for the user.

• as for substrings, the filter file contains regular expressions, so you can choose what it matches and where it matches (though generally "bad" strings should be matched anywhere). For more information on specifying regular expressions see re
  I don't see much point in specifying "^virii$" to match the lone word exactly, but feel free to try it.

• as for the windows client, the "expected" issues are meant to be resolved see fix/improve MS Windows clipboard handling #272, note that we simply do not copy PRIMARY or SECONDARY to/from the server at all now, so the fact that those are not filtered is expected behaviour: the data stays on the server - xterm selection goes to PRIMARY and stays there. We are not going to be filtering that, doing so would be ridiculously difficult since we would need to monitor the clipboard when we do not own it and "force clear" it when we do not own it - not good behaviour, not one that is expected to work well or reliably.

[totaam]

2013-03-23 03:20:07: afarr commented

---

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.

[totaam]

2013-03-23 05:58:18: totaam commented

---

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:

• on a windows client: connect xpra to a server and launch an xterm inside it, then also launch gtk_view_clipboard.py from this xterm
• copy something (say CLIENTSIDE) to the client clipboard using a native windows application (any text editor will do)
• select some text in the xterm (say SERVERSIDE) - do not copy (not that there is a way with a plain xterm?)
• using the gtk_view_clipboard.py tool, verify that the selection has been copied to PRIMARY but not CLIPBOARD (using the "GetString" button for each type of clipboard)
• try to paste in the windows client, the original content (CLIENTSIDE) should be pasted and nothing else

Extra tests:

• repeat the instructions but use a text editor (or browser) on the server-side, then you can also select "COPY" from its menu and pasting on the client-side should now show the updated contents (SERVERSIDE)

[totaam]

2013-03-23 13:40:10: totaam uploaded file clipboard-no.png (1.7 KiB)

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

[totaam]

2013-03-25 20:02:53: afarr commented

---

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.