xpra icon
Bug tracker and wiki

Opened 7 years ago

Last modified 3 months ago

#273 assigned enhancement

handle more clipboard formats, converting them on the fly

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 4.1
Component: clipboard Version:
Keywords: security Cc:


At the moment, we simply drop these types of clipboard data:

    debug("skipping clipboard data of type: %s, format=%s, len(data)=%s", dtype, dformat, len(data))
    return None, None

We could try to handle some of those, and provide them in multiple formats since we generally have PIL available for converting between formats.

From a security POV, it probably makes sense to always convert formats so that we can "guarantee" that the data we send over the wire is not malicious?
Think: an application providing a JPEG based buffer overflow via the clipboard: worst case scenario is that the xpra server crashes parsing it or maybe it gets compromised, but the client machine will not receive the malicious content directly.
But then again, if you can exploit the server, you can then inject the bad content in there.. I guess it's still a first line of defense.

Change History (7)

comment:1 Changed 7 years ago by Antoine Martin

Milestone: 0.91.0
Status: newaccepted

comment:2 Changed 7 years ago by Antoine Martin

Now that both OSX and win32 are using synchronous clipboard code (pretty much) and OSX is using at least some native call (see #318 for details)
It probably makes sense to use native libraries directly for accessing rich formats:

comment:6 Changed 3 years ago by Antoine Martin

Milestone: 1.03.0

comment:7 Changed 13 months ago by Antoine Martin

See also #2289

comment:8 Changed 8 months ago by Antoine Martin

Milestone: 3.04.0
Status: acceptednew

comment:9 Changed 3 months ago by Antoine Martin

Component: coreclipboard
Keywords: clipboard removed
Milestone: 4.04.1
Status: newassigned

For win32: #2619

Note: See TracTickets for help on using tickets.