GNOME Bugzilla – Bug 405291
Specially crafted .desktop files can disguise as harmless files
Last modified: 2008-03-19 15:11:40 UTC
Hi, .desktop files are prettified when rendered in nautilus: the Name property is used instead of the file name, the Icon property is used to draw the icon. This permits disguising a .desktop file with arbitrary commands in a harmless file; e.g. you could display the file foo.desktop in nautilus as Name=apple.jpg with an Icon=apple-red looking like a thumbnail, but this would in fact be malware running arbitrary commands via Exec=. This is discussed in Novell #258503: https://bugzilla.novell.com/show_bug.cgi?id=238503 At freedesktop.org: http://lists.freedesktop.org/archives/xdg/2007-January/thread.html#9150 The issue is /worsened/ by the fact that the malware can use non .desktop file names, such as "foo.jpg ", and gnome-vfs will still detect this as a Desktop File. See bug 405052. It would be nice to 1) change the current rendering of .desktop files and/or 2) filter the URIs for which it is prettified. 1) For example nautilus could use "foo.desktop ($Name)" instead of "$Name" in the nautilus view, or nautilus could embed the Icon property in an icon meaning "This is an application". 2) Nautilus could prettify .desktop files only on some URIs such as local files and computer://, but disable it on http:// and under some smb:// variants, like browsers do E.g. smb://$workgroup/ would need to allow .desktop files, smb://$host/ doesn't need to allow .desktop files (but this is undistinguishable from the previous, so allow), network:// should be allowed, smb://$host/$share and anything below needs to disallow .desktop files, smb://$workgroup/$host does not need to allow .desktop files (but this is undistinguishable from the previous, so disallow). This is Debian bug http://bugs.debian.org/408556. Bye,
In nautilus 1.20.0 (I haven't checked anything else, but it's been like this for a while.), this is at least partially fixed. The desktop files (without a .desktop extension) render "prettified", but don't actually execute. Perhaps something like the patch from comment 2 of bug #405052 was applied? In any case, this inconsistency is annoying.
BTW we have been applying the patch for bug#405052 in Debian since version 2.14, and it fixes this bug as well. It also seems to be applied to Ubuntu.
Ok, marking this bug as a dupe of bug #405052 as the patch there fixes this too. The patch needs some work until it can be accepted though. *** This bug has been marked as a duplicate of 405052 ***