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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ