Multiple vulnerabilities in the Xpra client

By default, the Xpra client enables a number of server→client features that significantly broaden the attack surface reachable by a malicious server. The shipped configuration (/etc/xpra/conf.d/) sets, among others:

# /etc/xpra/conf.d/05_features.conf
clipboard = yes
clipboard-direction = both
remote-logging = both

# /etc/xpra/conf.d/15_file_transfers.conf
file-transfer = auto
open-url = auto
open-files = auto

The features identified as security-sensitive, because they let the server reach a code-execution or data-exfiltration sink, are:

clipboard        # the server can spy on and overwrite the client's clipboard
remote-logging   # the server can pull almost all of the client's logs
webcam           # local capture device reachable by the server
file-transfer    # the server can push files onto the client
open-files       # the server can have the client open received files
open-url         # the server can have the client open URLs with the default handler
encodings        # the server can reach the installed decoders (see finding 7)

Xpra installs a desktop URL-scheme handler (/share/applications/xpra.desktop) that registers itself for many xpra* URL schemes and runs the clicked URL directly through xpra attach:

# /share/applications/xpra.desktop
Exec=xpra attach %u
MimeType=x-scheme-handler/xpra;x-scheme-handler/xpras;x-scheme-handler/xpra+tcp;
        x-scheme-handler/xpra+ssh;x-scheme-handler/xpra+ws;x-scheme-handler/xpra+wss; ...

A link such as xpra+ssh://… on any web page, email or chat message therefore becomes, xpra attach <attacker-controlled-URL>.

The URL handler parses the URL query string and applies every valid-typed parameter onto the client options, with no allow-list:

# xpra/scripts/parsing.py:1781
address, params = parse_URL(url)                       # parse ?k=v
for k, v in validate_config(params).items():
    setattr(options, k.replace("-", "_"), v)           # apply to opts (no allow-list!)
args[1] = address                                      # query stripped from address

validate_config() only keeps keys that are real Xpra options, but some of those options are command or exec sinks. At least two are both URL-settable and reachable from the attach mode the handler invokes:

• ssh, for an xpra+ssh:// target, the value of opts.ssh is shell-split and executed locally to establish the connection, so a query parameter can change the ssh binary to any command line such as bash -c 'echo "$(id) at $(date --rfc-3339=seconds)" >> /tmp/xpra_code_exec.log' --.
• open-command, the program used to open received files/URLs (default /usr/bin/xdg-open) is URL-settable, so a link can set ?open-command=<attacker command>.

A pushed file is normally gated behind a user-confirmation dialogue. However, when the client has itself previously requested a file, the server may return it and have it accepted without any prompt:

# xpra/net/file_transfer.py:828 function do_process_send_data_request
rf = options.tupleget("request-file")
if rf and len(rf)>=2:
    argf, openit = rf[:2]
    openit = self.files_requested.pop(bytestostr(argf), None)
    if openit is not None:
        self.files_accepted[send_id] = openit     # auto-accept, no dialog
        cb_answer(True)
        return

files_requested is meant to be populated only when the client itself calls send_request_file(). The flaw is that this client-side action is server-reachable: the control packet handler is registered unconditionally (xpra/client/gui/ui_client_base.py, add_packet_handlers({... "control": ...})), and its show_bug_report command makes the client request a file:

# xpra/client/gtk3/gtk_client_base.py:598
def download_server_log(self, callback=None):
    filename = "${XPRA_SERVER_LOG}"
    if callback:
        self.file_request_callback[filename] = callback
    self.send_request_file(filename, self.open_files)   # files_requested["${XPRA_SERVER_LOG}"] = open_files

A rogue server can thus send control show_bug_report to seed files_requested, then satisfy the auto-accept above, completely bypassing the file-transfer consent dialogue that normally protects the client. The accepted file is written to the download directory with a fully server-controlled name and content, and no digest, signature or type check is performed.

The file-transfer authorization routine accept_data() places the file-transfer authorization check in an elif branch that is skipped whenever the printit flag is set:

# xpra/net/file_transfer.py:455
def accept_data(self, send_id:str, dtype, basefilename:str, printit:bool, openit:bool) -> Tuple[bool,bool]:
    req = self.files_accepted.pop(send_id, None)
    if req is not None:
        return (False, req)
    if printit:
        if not self.printing or self.printing_ask:
            printit = False          # printing off -> silently downgrade to a save
    elif not self.file_transfer or self.file_transfer_ask:
        return None                  # <-- SKIPPED whenever printit is True
    if openit and (not self.open_files or self.open_files_ask):
        openit = False
    return (printit, openit)

A malicious server sets printit=True on its send-file. Printing is disabled by default, so printit is downgraded to False, but the return None rejection guarded by file_transfer_ask lives in the skipped elif, so it never runs. accept_data() therefore returns a tuple and the transfer is accepted with no user consent prompt. In other words, declaring a transfer a "print job" skips the file-transfer authorization entirely, and a disabled printer silently turns the print job back into a normal file save.

The download directory used for received files falls back to the user's $HOME when ~/Downloads does not exist:

# xpra/platform/paths.py:115
def do_get_download_dir() -> str:
    d = "~/Downloads"
    if not os.path.exists(os.path.expanduser(d)):
        return "~"            # writes land directly in $HOME
    return d

On minimal, freshly-created accounts, or on hosts that are not installed in English, there is frequently no ~/Downloads directory, so any received file lands directly in $HOME. safe_open_download_file() (file_transfer.py:70) uses basename(), which blocks path traversal on Linux, and O_EXCL, which prevents overwriting an existing file. However, neither prevents the creation of a login dotfile that does not yet exist, such as ~/.bash_profile, ~/.profile, ~/.xprofile or ~/.bash_aliases. These files are then evaluated when the user opens a shell.

The opening of a server-supplied URL is supposed to be gated by the open-url / open-url-ask policy. The authorization routine accept_data(), however, decides without ever considering the kind (dtype) of the requested object (file or URL) which produces two object kind confusions.

Confusion 1: a URL open is gated by the file-transfer flags. More specifically, _process_open_url calls accept_data() with dtype="url":

# xpra/net/file_transfer.py:729
def _process_open_url(self, packet):
    send_id = net_utf8(packet[2]); url = net_utf8(packet[1])
    if not self.open_url:
        return
    if not self.open_url_ask or self.accept_data(send_id, "url", url, False, True):
        self._open_url(url)

But accept_data() never looks at dtype; for printit=False it decides purely on the file-transfer flags:

# xpra/net/file_transfer.py:455
req = self.files_accepted.pop(send_id, None)
if req is not None:
    return (False, req)            # <-- Confusion 2: type-agnostic token
if printit:
    ...
elif not self.file_transfer or self.file_transfer_ask:   # FILE flags, used for a URL
    return None
if openit and (not self.open_files or self.open_files_ask):
    openit = False
return (printit, openit)

So a URL open is authorized by file_transfer/open_files, not by the open_url* policy intended to gate it.

Confusion 2: the auto-accept token is type-agnostic. accept_data() returns the files_accepted[send_id] token before any flag or type check. That token is granted in the context of a file request (do_process_send_data_request matching request-file, file_transfer.py:828), but it is honoured for a URL open as well, meaning a token issued for a file authorizes an arbitrary URL.

A remote-display client must decode the pixels the server sends, and the draw packet lets the server choose the codec and supply the entire bitstream. draw_region() dispatches the server-chosen coding straight to a decoder, and the choice depends only on which decoder modules are loaded, never on the encodings the client actually advertised in the encodings and video-decoders configuration options:

# xpra/client/gui/window_backing_base.py:898
def draw_region(self, x, y, width, height, coding, img_data, rowstride, options, callbacks):
    ...
    coding = bytestostr(coding)
    if coding == "mmap":
        ...
    elif coding in ("rgb24", "rgb32"):
        ...
    elif coding in VIDEO_DECODERS:
        self.paint_with_video_decoder(VIDEO_DECODERS.get(coding), coding, ...)   # openh264 / libvpx / ffmpeg
    elif self.jpeg_decoder and coding=="jpeg":
        self.paint_jpeg(...)                                                      # libjpeg-turbo
    elif self.avif_decoder and coding=="avif":
        self.paint_avif(...)                                                      # libavif
    elif coding == "webp":
        self.paint_webp(...)                                                      # libwebp
    elif self.spng_decoder and coding=="png":
        self.paint_spng(...)                                                      # libspng / libpng
    elif coding in self._PIL_encodings:
        self.paint_image(coding, ...)                                            # Pillow

The same attacker-controlled bytes also reach decoders through window-icon and cursor packets.

The dispatch never checks the server-chosen coding against the encodings the client advertised. For instance the webp branch is reached unconditionally whenever the always-present Pillow library is loaded (coding == "webp" has no self.*_decoder guard). The encodings and video-decoders lists are honoured only during capability negotiation, not when an incoming draw packet is decoded.