oss-security - Re: On the issue of MIME handlers that execute arbitrary code (e.g. Wine)

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260521193019.4XguG2B_@steffen%sdaoden.eu>
Date: Thu, 21 May 2026 21:30:19 +0200
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: On the issue of MIME handlers that
 execute arbitrary code (e.g. Wine)

Gabriel Corona wrote in
 <7758b7f4-a71a-48a6-b4a9-516700650a7e@...e.fr>:
 |> Sandboxes should only allow allowlist of file types and make everything
 |> else fall back to a safe default.  This could be a simple text editor
 |> (no IDE support!) for text files, and a hex editor (or an error) for
 |> binary files.
 |
 |That sounds extremely inconvenient. Running an email client in a 
 |sandbox? It can't open a PDF or a JPEG (or worse, you'll get an 
 |hex-editor) ...

Actually, i think what is missing is some intermediate step.  This
includes more control commands for RFC 1524 Mailcap files, which
i am all for, and hope certain new things in the IETF (structured
email, SML, to name it) do not loose it.  'Maybe even extend it.

For example, my MUA (but do not look) introduced certain new
control commands (x-mailx-async, x-mailx-last-resort,
x-mailx-ignore, too name some) , but none that fits here
specifically -- however, mailcap (and other supported approaches
of starting programs for data formats) are by default only used in
"copiousoutput" mode, you need a special `mimeview' command to
invoke other things.  Long story, this results in chains like

  application/pdf;\
          mupdf %s;\
          test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\
          nametemplate = %s.pdf; x-mailx-ignore
  application/pdf;\
          infile=%s\;\
                  trap "rm -f \"$infile\"" EXIT\;\
                  trap "exit 75" INT QUIT TERM\;\
                  mupdf "$infile";\
          test = [ -n "$DISPLAY" ] >/dev/null 2>&1;\
          nametemplate = %s.pdf; x-mailx-async; x-mailx-test-once
  application/pdf;\
          pdfinfo %s\; pdftotext -layout %s -;\
          test = command -v pdfinfo >/dev/null 2>&1;\
          copiousoutput; nametemplate=%s.pdf; x-mailx-test-once

or

  image/*;\
          display %s;\
          test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\
          x-mailx-ignore
  image/*;\
          infile=%s\;\
                  trap "rm -f \"$infile\"" EXIT\;\
                  trap 'exit 75' INT QUIT TERM\;\
                  display "$infile";\
          test = { [ -n "$DISPLAY" ] && command -v display\; } >/dev/null 2>&1;\
          x-mailx-async; x-mailx-test-once
  image/*;\
          identify %s;\
          test = command -v identify >/dev/null 2>&1;\
          copiousoutput; x-mailx-noquote; x-mailx-test-once

and the second ones are used for `mimeview', the third it is when
normally viewing emails.  (pdftotext not initially -- but i am
lazy, .. like you say.)

Short story: neither, i think, pdfinfo(1) nor pdftotext(1) (nor
identify(1)) actually execute integrated *Script, at least.
But it is still not truly nice.

Best would surely be some viewer who has a "stepped approach",
showing only some infos first, asking for confirmation or the
action to be applied, before displaying an image or whatever.
And then going into some safe mode when truly going "in full" on
the data as such.
Of course implementing such a thing in that very way is an
extensive effort, and not always doable.

But maybe it is time -- instead of simply rewriting the same mess
in Rust (gdk-pixbuf) -- to create "priviledge-separated" media
viewers, where the image/data format specific stuff is in
a completely separated "process", and only readily prepared data
in a common type (X11 bitmap or what) is then send via IPC / made
available in some shared mapping for some display/player.
(It could be such things already exist, i live only in dwm / st
/ tmux, and have only fewest graphical things beside that.)

 |If the sandboxed application is badly integrated and can't open files 
 |and URIs, the user (me included) will prefer using the non-sandboxed 
 |version in order to get things done (or will prefer using a more 
 |user-friendly OS). This would defeat the purpose of having sandboxed 
 |applications.

Over a decade ago an Irish forwarded a message from Trinity
College Dublin; it is astounding "how rich" emails can get in real
life.  One does not want to use the above approach (what was,
actually, shown).  But priviledge-separated multimedia viewer,
which maybe "goes in full" (video, audio .. play) only on explicit
request, instead of simply linking/loading in more and more
formats through shallow ad-hoc format converters that use format
dedicated libraries, i think that is a problem.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
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.