Date: Wed, 8 Nov 2017 14:49:00 -0500 From: Michael Orlitzky <michael@...itzky.com> To: oss-security@...ts.openwall.com 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] 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.
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.