After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 405052 - Please workaround the dangerous shared-mime-info logic
Please workaround the dangerous shared-mime-info logic
Status: RESOLVED OBSOLETE
Product: gnome-vfs
Classification: Deprecated
Component: MIME and file/program mapping
2.14.x
Other Linux
: Normal major
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
: 405291 571307 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-02-06 17:18 UTC by Loïc Minier
Modified: 2013-07-17 11:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix for nautilus 2.16.3 (3.30 KB, patch)
2007-02-15 19:37 UTC, Josselin Mouette
none Details | Review
Better fix (4.36 KB, patch)
2007-02-18 17:19 UTC, Josselin Mouette
none Details | Review
Screenshot of MIME type handling in Thunar (Xfce) (30.37 KB, image/png)
2007-02-26 12:20 UTC, Loïc Minier
  Details
desktop_file_activation.patch (3.66 KB, patch)
2008-03-19 15:10 UTC, Sebastian Dröge (slomo)
none Details | Review

Description Loïc Minier 2007-02-06 17:18:03 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,
Comment 1 Josselin Mouette 2007-02-15 19:37:43 UTC
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.
Comment 2 Josselin Mouette 2007-02-18 17:19:47 UTC
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.
Comment 3 Loïc Minier 2007-02-26 12:20:43 UTC
Created attachment 83385 [details]
Screenshot of MIME type handling in Thunar (Xfce)
Comment 4 Richard Laager 2007-12-17 06:20:16 UTC
See also bug #405921.
Comment 5 Richard Laager 2007-12-17 06:24:03 UTC
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.
Comment 6 Richard Laager 2007-12-17 19:57:31 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2008-03-19 15:10:24 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2008-03-19 15:11:40 UTC
*** Bug 405291 has been marked as a duplicate of this bug. ***
Comment 9 Josselin Mouette 2008-03-23 16:39:41 UTC
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.
Comment 10 Sebastien Bacher 2009-02-12 09:02:10 UTC
*** Bug 571307 has been marked as a duplicate of this bug. ***
Comment 11 Chris Jones 2009-02-12 11:45:43 UTC
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.
Comment 12 Pacho Ramos 2009-02-12 12:04:35 UTC
Can anybody modify product as seems to still affect gio-based nautilus. Thanks :-)
Comment 13 Sebastian Dröge (slomo) 2013-07-17 11:46:11 UTC
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.