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)