GNOME Bugzilla – Bug 405052
Please workaround the dangerous shared-mime-info logic
Last modified: 2013-07-17 11:46:11 UTC
Hi, The shared-mime-info database permits mapping file extensions to MIME types and also guessing MIME types from file data ("magic"). However, shared-mime-info does not implement protection against files with dangerous MIME types disguised with an unknown extension. That is, if you rename a .desktop file to .foobar, it will still get the MIME type of a .desktop file. The same goes for any type of files for which shared-mime-info has magic. This is problematic and has security implications because one can trick an user into opening an innocently looking file (say, "file.jpg ", mark the final space), but the gnomevfs aware program might trigger some dangerous actions associated with the MIME type (instead of the expected program associated with the extension). This is discussed in Novel #258503: https://bugzilla.novell.com/show_bug.cgi?id=238503 At shared-mime-info's upstream: http://lists.freedesktop.org/archives/xdg/2007-January/thread.html#9150 And this is also Debian bug http://bugs.debian.org/408948. Warning: there are two bugs in the discussions, one is about the general handling of .desktop files in nautilus which is a bit problematic since you can show any Icon you like and any Name you like and run any command you like, which makes it easier to trick the user into dangerous stuff. The bug I am reporting here is a request to implement a protection against MIME type <-> extension mismatch. I know there's already a MIME type <-> extension's MIME type mismatch check, but it only works if the extension has an associated MIME type in freedesktop's db. I think this test should be extended to report unknown extensions as malware. On the long term this should be fixed in shared-mime-info, but this is unrealistic for the short and mid terms. The suggestion is precisely what libthunar-vfs does (the Xfce counterpart of gnome-vfs also based on shared-mime-info), from thunar-vfs/thunar-vfs-io-local.c: /* check if the file tries to look like a regular document (i.e. * a display name of 'file.png'), maybe a virus or other malware. */ fake_mime_info = thunar_vfs_mime_database_get_info_for_name (_thunar_vfs_mime_database, str); if (fake_mime_info != _thunar_vfs_mime_application_octet_stream && fake_mime_info != info->mime_info) { /* release the previous mime info */ thunar_vfs_mime_info_unref (info->mime_info); /* set the MIME type of the file to 'x-thunar/suspected-malware' to indicate that * it's not safe to trust the file content and execute it or otherwise operate on it. */ info->mime_info = thunar_vfs_mime_database_get_info (_thunar_vfs_mime_database, "x-thunar/suspected-malware"); /* reset the executable flag */ info->flags &= ~THUNAR_VFS_FILE_FLAGS_EXECUTABLE; /* reset the custom icon */ g_free (info->custom_icon); info->custom_icon = NULL; /* reset the name str, so we display the real file name */ name = NULL; } Bye,
Created attachment 82624 [details] [review] Fix for nautilus 2.16.3 Here is the patch that I have applied to the Debian packages (works for 2.14 and 2.16). After thinking much about it, I'm convinced that there is nothing wrong in gnome-vfs, and that it is up to nautilus to not do stupid things with dangerous files. The patch applies a special treatment only to "application" desktop files, the ones that can trigger any command they contain. There is nothing wrong a "link" desktop file can do, and changing anything about them could break e.g. smb:// or the link handling in the libgnomeui filechooser. The patch forbids these application files in the following cases: - remote locations (except for mounted filesystems), - locations where you mount unsafe stuff (/mnt and /media), - files belonging to other users (except root). Some small changes were also needed in fm-directory-view.c so that these files are treated like regular files when clicked on instead of spawning an unrelated insult box, without affecting other desktop files.
Created attachment 82835 [details] [review] Better fix Here is an updated patch that fixes problems with some context menus introduced by the first one, and does a better job at checking uids.
Created attachment 83385 [details] Screenshot of MIME type handling in Thunar (Xfce)
See also bug #405921.
That last comment should have said: See also bug #405291. 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 was applied? In any case, this inconsistency is annoying.
I'm using Ubuntu. Perhaps that patch is why things changed for me. I can definitely confirm that at the moment, a desktop file without the .desktop extension is rendered with the data from the file, but opens in a text editor. This is inconsistent and confusing. It should render as a text file if it is going to open as one.
Created attachment 107619 [details] [review] desktop_file_activation.patch Patch for nautilus 2.22. It would be better to show the user a dialog if the starter might be dangerous instead of silently doing nothing. This patch doesn't do that but after that is added it might be ready for committing.
*** Bug 405291 has been marked as a duplicate of this bug. ***
With the patch, the file is opened in the text editor, not silently ignored. I agree that it would be better to bring a specific dialog instead, though.
*** Bug 571307 has been marked as a duplicate of this bug. ***
I suggested in Bug 571307 that it be a requirement for a .desktop file to have +x for it to be handled as a launcher. The reasoning being that without +x you can download a .desktop file and it will immediately be treated as an executable, and can run whatever commands it wants. The risk this poses far outweighs the limited use-cases for downloading .desktop files directly, imho.
Can anybody modify product as seems to still affect gio-based nautilus. Thanks :-)
Pacho, can you just clone this bug and put it to nautilus if it still is a problem? Closing this one here as obsolete as gnomevfs is exactly that... obsolete.