Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Nov 2017 14:49:00 -0500
From: Michael Orlitzky <>
Subject: Re: [CVE-2017-14604] .desktop vulnerability again

On 10/05/2017 04:37 PM, Yves-Alexis Perez wrote:
> Hi list,
> I'm currently in the process of uploading a nautilus package fixing CVE-2017-
> 14604 which is again a vulnerability in the handling of desktop file. As I
> don't think it's been discussed here, it might be a good idea to do a wrap-up, 
> and maybe start a discussion if people are interested and have good ideas.

> Scanning through the various bugs, not everyone agree on how to fix this:
> - Nautilus doesn't use the executable bit anymore but store a trusted
> attribute in a gio/gvfs metadata, which is stored on the filesystem in
> XDG_DATA_DIR/.gvfs-metada (usually ~/.local/share/gvfs-metadata) which I guess
> should not be reachable from a tarball unless the extraction process has a
> directory traversal vulnerability

Using the executable bit was wrong (in my opinion) for one main reason:
the .desktop files aren't actually executable. By marking them +x, you
screw up programs (like bash) that care about the executable bit. There
is now also the issue that you've reported, where the executable bit is
preserved by tar -- we have to assume that the GUI will do something
stupid like hide the file extension.

The last time I thought about this, I came up with something that sounds
spiritually similar to what Nautilus has done. Using Thunar as my file
manager -- suppose I download a file called /home/mjo/malware.desktop
that contains (from your bug report),

  [Desktop Entry]
  Exec=sh -c 'touch ./MALWARE_WAS_HERE'

I don't want to rely on the executable bit, and I don't want to use any
gvfs magic. Instead, when I click on malware.desktop, Thunar should
check for the existence of

  /home/mjo/.local/share/Thunar/home/mjo/malware.desktop           (1)

and then handle two cases,

  i) if the file does exist, and if it's executable, execute it.

  ii) otherwise, prompt me for whether or not I want to run the thing

      ii.a) if I say "no", then do nothing

      ii.b) if I say yes, then create the file at (1) containing

              sh -c 'touch ./MALWARE_WAS_HERE'

            and mark it executable before running it.

That way, the only thing that gets +x is *actually* executable. The
"metadata" is still associated with the file path, but needs no magic
beyond the ability to execute a shell script.

This idea is probably full of holes, but nobody who's qualified to fix
this clicks on pictures to run programs =P

Obvious caveats:

  1) The file manager would have to substitute "%f" and friends into the
     shell script and get the quoting right.

  2) The path in (1) doesn't change when the file's contents do; a real
     implementation would want to include a hash or something, like


     The Nautilus implementation might be vulnerable to swapping the
     contents of the file.. the gvfs metadata is supposedly path-based,
     but I know nothing about it.

  3) This will prompt every user the first time he runs a system
     executable that has a .desktop entry. That should be easy to
     solve, though, by using a system location such as
     /var/lib/Thunar/<path>/<sha512> and by having the file manager look
     there first. Distros would simply install the shell script and mark
     it executable.

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.