[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ag2EONSuspJdhYfd@definition.pseudorandom.co.uk>
Date: Wed, 20 May 2026 10:51:52 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: arraybolt3@...eup.net
Subject: Re: On the issue of MIME handlers that execute
arbitrary code (e.g. Wine)
On Tue, 19 May 2026 at 19:30:42 -0400, Aaron Rainbolt wrote:
>I wonder if it would be worth proposing a change to whatever system
>component handles opening files (probably something in Glib, or
>xdg-utils, haven't researched that deeply yet)
It's a general-purpose specification that is designed to be implemented
by an unlimited number of packages, some of them desktop-specific:
* GLib, and via that, gio(1), xdg-desktop-portal and flatpak-xdg-utils'
xdg-open(1) reimplementation
* some Qt/KDE library (I'm less familiar with the KDE world, so I don't
know whether this is done in the Qt layer or somewhere in kdelibs)
* xdg-utils' xdg-open(1) (the reference implementation of that name)
* Debian's mailcap package, which translates fd.o MIME handlers into
traditional mailcap(5) handlers
* web browsers like Firefox and Chromium might reimplement it? not sure
* ...
so any change to how the spec is to be implemented would have to be
fd.o consensus and spread across all of those.
(xdg-utils' implementation of xdg-open(1) sometimes calls helper
utilities from GNOME, KDE, XFCE, etc., like GLib's gio(1), or sometimes
implements a sufficiently large subset of the .desktop spec itself in
shell script, depending how and where it's invoked - this is not great
from a maintainability or predictability point of view, but it does mean
that it can continue to take into account desktop-environment-specific
behaviours that pre-date the de facto standardization of MIME type
handlers and the URI scheme pseudo-MIME-types like
x-scheme-handler/http.)
>so that handlers cannot
>be registered for certain "dangerous" file types (i.e. ELF/PE/Mach-O
>executables, scripts in various languages, etc.)? The only real
>downside I can see to that is the inability to text editors to
>register themselves as handlers for script MIME types, and in those
>instances, the editor can register itself as the handler for another
>applicable, more generic MIME type (i.e. text/plain), then change its
>behavior based on the more detailed MIME type of the file after it
>opens it.
I think the ability to double-click on a script (shell, Python, etc.)
and have it open in a programmers' text editor would probably be
considered to be a requirement by desktop environments, although
associating a text editor with text/plain partially covers that.
If it's no longer possible to associate an action with a script MIME
type specifically, then that would make it impossible to configure
text/plain to open in a quick/simple Notepad-like editor like
gnome-text-editor or KWrite, while having text/x-python3 open in a more
complicated IDE like GNOME Builder or Emacs, or a Python-specific
environment like IDLE. That seems like an unwelcome loss of
functionality, and perhaps too much - I don't think it's common to
associate these script file-types with something that will immediately
run them?
I'm not sure whether it still does, but GNOME's file-roller (primarily a
handler for zip, tar etc. archives) used to register a MIME handler for
PE DLLs and executables that would show the PE object's various sections
(data, executable code, resources) as pseudo-files that can be read and
extracted. I'm not sure whether that was ever practically useful or just
demo/"because we can" functionality, but in the past it has accidentally
mitigated the dangerous handlers discussed in this thread by being a
higher-priority handler for PE executables for GNOME users than the
dangerous one! Not allowing handlers for PE executables would have the
collateral damage of breaking its ability to have this file-type
association, which is relatively safe because it's treating the
executable as data in a specific format rather than executing anything.
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
