oss-sec mailing list archives
Re: [CVE-2017-14604] .desktop vulnerability again
From: Michael Orlitzky <michael () orlitzky com>
Date: Wed, 8 Nov 2017 14:49:00 -0500
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]
Name=CV.pdf
Exec=sh -c 'touch ./MALWARE_WAS_HERE'
Terminal=false
Icon=x-office-document
Type=Application
Categories=Office
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
#!/bin/sh
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
/home/mjo/.local/share/Thunar/home/mjo/malware.desktop/<sha512>
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.
Current thread:
- [CVE-2017-14604] .desktop vulnerability again Yves-Alexis Perez (Oct 05)
- Re: [CVE-2017-14604] .desktop vulnerability again Michael Orlitzky (Nov 08)
- Re: [CVE-2017-14604] .desktop vulnerability again Robert Watson (Nov 09)
- Re: [CVE-2017-14604] .desktop vulnerability again Simon McVittie (Nov 09)
