Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ