— MARKDOWN —
– We found and reported 1-click code execution vulnerabilities in popular software including **Telegram**, **Nextcloud**, **VLC**, **Libre-/OpenOffice**, **Bitcoin/Dogecoin Wallets**, **Wireshark** and **Mumble**
– Desktop applications which pass user supplied URLs to be opened by the operating system are frequently vulnerable to **code execution with user interaction**
– Code execution can be achieved either when a URL pointing to a malicious executable (`.desktop`, `.jar`, `.exe`, …) hosted on an internet-accessible file share (`nfs`, `webdav`, `smb`, …) is opened, or an additional vulnerability in the opened application’s URI handler is exploited
– Vulnerabilities following this pattern have already been found in other software, with more expected to be revealed going forward

# Introduction

In this post, we show code execution vulnerabilities in numerous desktop applications, all with the same root cause: insufficient validation of user input that is later treated as a URL and opened with the help of the operating system. The required user interaction and exploitation strategy depends on the desktop environment and whether the application was hardened, for instance, with a URI-scheme allow/block list. As an example, here is what exploitation of this issue in Nextcloud (< 3.1.3) on Xubuntu 20.04 looks like:

After explaining the root cause, vulnerable patterns and oddities of different OS’s and desktop environments, we’ll explore how this vulnerability type can be exploited in various popular desktop applications.

### Table of Contents

– [Introduction](#introduction)
– [Root cause: user-supplied URLs opened by the OS](#root-cause-user-supplied-urls-opened-by-the-os)
– [Finding vulnerable features is straightforward](#finding-vulnerable-features-is-straightforward)
– [Operating systems and desktop environments have different URL opening behaviors](#operating-systems-and-desktop-environments-have-different-url-opening-behaviors)
– [Windows 10 19042](#windows-10-19042)
– [Xubuntu 20.04](#xubuntu-2004-xfce)
– [Other Linux Operating Systems](#other-linux-operating-systems) + [Snap](#snap)
– [Mac (Catalina 10.15.6)](#mac-catalina-10156)
– [Vulnerabilities](#vulnerabilities)
– [Nextcloud](#nextcloud)
– [Telegram](#telegram)
– [VLC](#vlc)
– [Open-/LibreOffice](#open-libreoffice)
– [Mumble](#mumble)
– [Bitcoin/Dogecoin Wallets](#bitcoindogecoin-wallets)
– [Wireshark](#wireshark)
– [Bonus-Vulnerability: WinSCP](#bonus-vulnerability-winscp)
– [Systematic mitigation requires contributions from OS, Framework, and Application maintainers](#systematic-mitigation-requires-contributions-from-os-framework-and-application-maintainers)
– [Conclusion](#conclusion)

# Root cause: user-supplied URLs opened by the OS

A common way to open files and links from a native desktop application is by passing a URI to the operating system to handle (e.g. to open the default mail application for a `mailto:` link).

This is done via the following functions/programs:

– Windows: `ShellExecute*`
– Linux: `xdg-open` (detects desktop environment and calls `gio open`, `gvfs-open`, `gnome-open`, `mate-open`, `exo-open` or `enlightment_open`)
– Mac: `NSWorkspace#openURL()`

When a user-supplied URL is opened in this way without additional checks, this can lead to code execution:

– By exploiting OS behavior for specific URI schemes and file extensions
– By exploiting vulnerabilities in 3rd party application URL handlers (e.g. [this vulnerability in the `steam://` protocol](http://revuln.com/files/ReVuln_Steam_Browser_Protocol_Insecurity.pdf))

Browsers are aware of the potential security implications and disable `file://`-links as one of the most dangerous URI schemes, as well as at least showing a popup before navigating to other external URLs.

While these additional checks have been implemented over time by security-conscious browser developers, they are missing in many other applications.

# Finding vulnerable features is straightforward

For any given software, check all features where user-supplied values are opened as URLs (e.g. hyperlinks). If the feature, under the hood, uses the OS to handle the opening and allows arbitrary schemes without comprehensive warning messages, there is likely a way to exploit the feature on certain platforms.

We found that QT’s `QDesktopServices::openUrl()` function fulfills the first condition and checked popular QT-based open source software for instances where the function is called with insufficiently validated user input. Tools such as [searchcode allow to easily expand a search across millions of indexed open source projects](https://searchcode.com/?q=QDesktopServices%3A%3AopenUrl).

Please note that this behavior and issue is not unique to QT. As another example, Electron’s `shell.openExternal()` [has the same behavior](https://benjamin-altpeter.de/shell-openexternal-dangers/), which lead e.g. to an [RCE in the Wire Messenger](https://github.com/wireapp/wire-desktop/security/advisories/GHSA-5gpx-9976-ggpm).

# Operating systems and desktop environments have different URL opening behaviors

From our point of view, the ideal URL opening behavior for an OS includes the following characteristics:

– **Does not automatically mount** previously unmounted file shares without a comprehensive user warning as simply mounting an `smb` share can cause credential leakage
– **Displays a comprehensive user warning** before opening an executable or risky (i.e. `.docm`) file from a remote file share

The remainder of this section contains a detailed write-up of deviations from this behavior we have observed in different operating systems. If you are not interested in those specifics, you can [skip ahead to the vulnerabilities section](#vulnerabilities) where we demo the different vulnerable desktop applications.

## Windows 10 19042

* Executable `.jar` files do not trigger a warning when they are located on a mounted file share (standard JRE installation required)
* UNC paths for all compatible file share protocols cause automatic mounting without a warning:
* `smb`: `\\<hostname>\<filename>`</filename></hostname>
* `webdav`: `\\<hostname>\DavWWWRoot\<filename>`</filename></hostname>
* `webdavs`: `\\<hostname>@SSL\DavWWWRoot\<filename>`</filename></hostname>
* Many applications convert file URLs to UNC paths: `file://<hostname>/DavWWWRoot/<filename>` becomes `\\hostname\DavWWWRoot\<filename>`, allowing one to bypass client-side checks</filename></filename></hostname>
* When the UNC path points to a file in the root folder of the share, mounting and opening the file is done with a single URL open/click (otherwise, taking two clicks to first mount and then open)

## Xubuntu 20.04 (Xfce)

– Executing a `.desktop` file (and therefore running the specified command) does not trigger a warning when it’s located on a mounted file share and the file has the executable bit set
– `nfs` URLs cause automatic mounting without a warning/notification and allow for mounting and execution via a single URL open action
– `dav` and `davs` URLs pointing to the root folder of an unmounted share cause automatic mounting. If the server is modified to return a `collection` element in the response to the first PROPFIND request to `/file`, automatic mounting is also done for URLs pointing to specific files on the share
– `dav`, `davs`, `ftp`, `ftps` URLs cause automatic mounting without a warning. When the mounting is initiated by a URL pointing to an executable file, a warning message about the unknown origin of that file is shown after mounting. However, even if the execution is canceled by the user, when the same URL is opened again, with the share now already being mounted, the file is executed and no further warning is displayed
– `smb` URLs initiate a mounting process which shows a connect dialog (not a security warning) that can be confirmed with one click on the pre-selected confirm button
– `sftp` URLs initiate a mounting process which shows the host key confirmation dialog on first connect

## Other Linux Operating Systems

The exact opening behavior is dependent on the desktop environment and configuration. After quick review, xfce seems to have the most exploitable features:

– **Auto-mounting:** In Kubuntu/KDE (`kde-open5`), remote files are auto-opened but the remote share is not permanently mounted. When a remote file is opened, it is downloaded and then opened/executed with the default program (but executable-flags are not retained during this download). Ubuntu/GNOME (gio open) does not auto-mount remote shares (“The specified location is not mounted”), however the contents of already mounted shares can be referenced as local files (`file:///var/run/user/<id>/gvfs/…`)
– **File types:** .desktop files are often not parsed/executed, but rather opened in a text editor. Since this was unexpected to many, and meant that there was no on-board way to launch .desktop files from the command line, a bug was filed in 2009 [https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/378783](https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/378783) and many similar discussions can be found on the Internet. In December 2020, the bug was closed with the introduction of a new separate `gio launch` command. Users that have implemented workarounds, for example, [by associating `.desktop` files with `dex`](https://github.com/jceb/dex) are likely still vulnerable.

## Snap

Snap apps are subject to an additional URI scheme allowlist. Initially, this list only contained `http`, `https`, `mailto` and `snap`, which broke a lot of applications including Google Chrome. Recently [more URI schemes were added](https://github.com/snapcore/snapd/blob/30ef6dd52df387d359afdcd15f96210e6e0a1d71/usersession/userd/launcher.go#L56-L118).

The snap team has the explicit goal to harden `xdg-open` calls using the following criteria:
– The scheme is understood and documented in the code
– The scheme itself does not cause `xdg-open` to open files (e.g. `file://`)
– It is verified that the recipient of the url (ie, the callee of `xdg-open`) won’t process file paths or other arguments in a way that can be leveraged to break out of the sandbox (requires understanding how the url can drive the recipient application)

From a security perspective, this much appreciated. However, the initial usability decrease was high which probably drove users to overall less constrained .deb packages. Even though more URI schemes were added, many use cases are still broken. As a rather mundane example, we found that `ftp://`-links are opened (safely in the browser) from the “normal” Telegram desktop app, but nothing happens in the snap version (“user-open error: supplied URL scheme “ftp” is not allowed”)

## Mac (Catalina 10.15.6)

– `smb` URLs open a connect dialog. Confirming the the connection will mount the share and open a Finder (file explorer) view
– `smb` URLs to specific files on shares are interpreted as URLs to a share’s root folder. They trigger another connect dialog even if the real root folder has been mounted already. Confirming that connection adds an additional entry with the name of the referenced file to `/Volumes`
– Files on already mounted shares can be referenced via `file` URLs pointing to `/Volumes/<share_name>/<file_name>`</file_name></share_name>
– `file` URLs to specific files open the file with the associated application only for some file types like `.txt`, and only if the file has been opened manually before (for example by double-clicking in the Finder)
– In all other tested cases, `file` URLs pointing to specific files open up the Finder for the containing folder rather than opening the file

**Please note:** Besides these different combinations of file share URI schemes and extensions, many more dangers can be introduced with custom URL scheme handlers, independent of the OS. In this blog post, we disclose one such RCE in a 3rd party application that allows for arbitrary code execution without additional user interaction. In an upcoming blog post, we’ll explore a similar vulnerability in a Windows 10 default URI handler.