Fixing security issues with MIME handler registration in the Desktop Entry spec

--Sig_/Rdf2CcVSmg6ZFLoYq3YN1AD
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

A little over a week ago, I sent an email to
[email protected] titled "On the issue of MIME handlers
that execute arbitrary code (e.g. Wine)". [1] I won't replicate all of
it here, but the tl;dr is that some applications register MIME
handlers that will pass executable code directly to an interpreter or
code loader. Wine, for instance, registers a handler for EXE, MSI, and
BAT files, and triggering that handler will result in the opened file
being executed immediately. This is a problem, because both Flatpak and
Snap trust the XDG desktop portal system to allow sandboxed apps to open
files outside of the app's sandbox, and xdg-desktop-portal-gtk assumes
that MIME handlers don't execute arbitrary code. You can therefore
escape a Flatpak sandbox on a system with Wine installed by dropping an
EXE file on the disk and opening it with the OpenURI portal. There are
edge cases where this doesn't work (for instance, if you have an
archiver application installed that also registers itself as a handler
for EXE files, thus causing xdg-desktop-portal-gtk to ask you which
program to use to open the file), but it can and does work in many
instances. Historically, Mono had a similar issue in Debian [2], and I
have a vuln report for another issue currently under embargo.

Originally, I decided this was a vulnerability in the applications
registering MIME handlers, because the xdg-mime manpage explictly says
to not register MIME handlers that register arbitrary code, so I
proceeded to file a report against Wine. [3] After getting some
pushback, I argued that anything that needs to register an executable
file handler should be using Linux's binfmt-misc system, whereupon
someone mentioned the fact that portability is a concern. Wine supports
several flavors of BSD too, and to my awareness the BSDs often don't
have a binfmt-misc-like mechanism. Furthermore, the warning in the
xdg-mime manpage was appareontly only added in 2023, whereas Wine has
been shipping this MIME handler since 2004, thus there wasn't any good
way for Wine to know that this was a bad idea (and probably back in
2004 it wasn't a bad idea since Flatpak and Snap didn't exist yet).

Removing the MIME handler isn't really an option for Wine, since users
expect to be able to download Windows applications, double-click them,
and have them install and run. Without the MIME handler, a user will
install Wine, download their app of choice, double-click it, and either
get a generic "Open With" dialog, an "Open With" dialog that doesn't
even let the user get to Wine, or an archiver window that shows a bunch
of details about the internal structure of the file. All of those are
frustrating, and a generic "Open With" dialog will probably let the
user say "Always open EXE files with Wine from now on", which recreates
the vulnerability.

I think this illustrates that the desktop entry spec's MimeType key is
insufficient for secure file handler registration nowadays.
Applications *have* to be able to register code loaders and
interpreters with the system, but they *can't* do that without enabling
sandbox escapes. A couple of suggestions from people in the Wine bug
report thread were:

> Having some way to tell XDG that a handler is not an 'opener' but a
> 'runner', and enforcing the policy by excluding runners from being
> selected by default, is a valid feature request to direct at
> Freedesktop. If they offered such a feature, Wine would use it.

And:

> It be nice if a mechanism could added instead. An extra property that
> specifies whether the handler is a runner or an opener and a way to
> request either or both.

So now I'm here, suggesting that we add a new mechanism to un-mess this
mess :) Adding a new key for registering "executable MIME types" sounds
like a straightforward solution to me, but there are a couple of
caveats I can think of (and there are probably more I'm missing):

* An application might theoretically be both an opener and a runner for
  a specific file type. For instance, a Scratch [4] user might want to
  open a .sb3 file to modify the game it contains, or they might want
  to just play the game. (I don't know if Scratch has any kind of "just
  run it" feature, I don't use it, it's just an example.) If a program
  is able to be both an editor and a launcher, it will probably have
  different command line arguments for each function, in which case
  there may need to be *two* "Exec" lines, one for "open" and one for
  "run".
* We can't just add a new "LaunchMimeType" key or similar, because then
  any applications in the wild that register themselves as a standard
  MIME handler for files they intend to execute will still act as
  sandbox escape vectors. In theory, there might be applications that
  are either no longer developed, or that are developed by some
  company that does the bare minimum needed to support Linux and
  doesn't bother to update anything if they don't have to, both of
  which could be problematic. The "MimeType" key would probably have to
  be completely ignored going forward, and we would then need two keys,
  like "OpenMimeType" and "LaunchMimeType", to replace it.

Any thoughts or feedback before I try to make a more formal spec change
proposal?

--
Aaron

[1] https://www.openwall.com/lists/oss-security/2026/05/19/1
[2] https://www.openwall.com/lists/oss-security/2023/01/05/1
[3] https://bugs.winehq.org/show_bug.cgi?id=3D59767
[4] https://en.wikipedia.org/wiki/Scratch_(programming_language)

--Sig_/Rdf2CcVSmg6ZFLoYq3YN1AD
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQS8QsiCjFi4DcDBX+Q5rdye4jrrCAUCahe8dQAKCRA5rdye4jrr
CN8RAQDyx61T3cIpqYAjXTiqqS9IQgJ3NxvDZk8pzi/R/AhTywEAhSC8AqXV4cwX
MrUc/W1UZX+VGCE9KY5erZd8hWdN2Q8=
=DSMo
-----END PGP SIGNATURE-----

--Sig_/Rdf2CcVSmg6ZFLoYq3YN1AD--