GNOME Bugzilla – Bug 777991
Nautilus hides filename for .desktop files with execute permission
Last modified: 2017-10-11 02:29:53 UTC
Created attachment 344652 [details] Screenshot of malicious .desktop file displayed in Nautilus How to reproduce: 1. Create a file called malware.desktop 2. Add the following content to it: [Desktop Entry] Name=CV.pdf Exec=sh -c 'touch ~/MALWARE_WAS_HERE' Terminal=false Icon=x-office-document Type=Application Categories=Office 3. Make it executable Nautilus displays the file like that: (see attachment) Once the user opens the file the Exec entry is executed without any confirmation. By hiding the filename and therefore also the filename extension users can easily be tricked to execute arbitrary code when some ships files like that in an archive which preserves execute permissions. Especially since nowadays Nautilus even extracts archives with a simple double click. How to fix it: Maybe by don't hiding the filename for .desktop files at all.
For reference, this bug also applies to other file managers: https://github.com/lxde/pcmanfm-qt/issues/449 https://github.com/mate-desktop/caja/issues/727 https://github.com/linuxmint/nemo/issues/1404
I can reproduce the issue. This is a really, really bad security hole. .desktop files shouldn't be able to masquerade as anything else when viewed by the file manager. macOS Finder and Windows Explorer both have security measures put in place to prevent spoofing file extensions in this manner; Nautilus should, too.
The extension is just a detail (as it would putting an emblem or so) which doesn't really communicate or stop the user to run it. I tried the steps in here and I cannot reproduce, the mimetype is detected as pdf and cannot open it. But this is highly different per system/user, so not something we can rely on. The solution we came up with is to not allow desktop file activation at all if the desktop file was not created by us or acknowledged by the user via dialog of trusting it.
Created attachment 345047 [details] [review] mime-actions: use file metadata for trusting desktop files Currently we only trust desktop files that have the executable bit set, and don't replace the displayed icon or the displayed name until it's trusted, which prevents for running random programs by a malicious desktop file. However, the executable permission is preserved if the desktop file comes from a compressed file. To prevent this, add a metadata::trusted metadata to the file once the user acknowledges the file as trusted. This adds metadata to the file, which cannot be added unless it has access to the computer. Also remove the SHEBANG "trusted" content we were putting inside the desktop file, since that doesn't add more security since it can come with the file itself.
Attachment 345047 [details] pushed as 1630f53 - mime-actions: use file metadata for trusting desktop files
*** Bug 779547 has been marked as a duplicate of this bug. ***
Carlos, thank you for resolving this security issue. Is there a plan to backport this fix to the 3.22.x branch to make it available for Debian users? Debian wants to backport this patch as a security update [1]. I think that a CVE should be requested for this issue to help all distros coordinate on the deployment of the patch for this vulnerability. It is possible to trivially exploit this issue in-the-wild [1]. I'm happy to file the CVE request if you would like me too. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268 [2] https://github.com/freedomofpress/securedrop/issues/2238
(In reply to Donncha Ó Cearbhaill from comment #7) > Carlos, thank you for resolving this security issue. Is there a plan to > backport this fix to the 3.22.x branch to make it available for Debian > users? Debian wants to backport this patch as a security update [1]. > > I think that a CVE should be requested for this issue to help all distros > coordinate on the deployment of the patch for this vulnerability. It is > possible to trivially exploit this issue in-the-wild [1]. I'm happy to file > the CVE request if you would like me too. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268 > [2] https://github.com/freedomofpress/securedrop/issues/2238 Not in principle, 3.22 is not supported upstream neither any new 3.22.x releases are expected. If it's something that will be of convenience to Debian I'm fine doing a release, but someone will have to do the backport since I believe there will be conflicts. I'm fine if you want to file a CVE indeed.
Phil Wyett has provided a debdiff of the .desktop fix backported to 3.22.3. Is that patch acceptable for you? https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=860268;filename=nautilus_3.22.3-1_to_nautilus_3.22.3-1.1.debdiff;msg=19 I'll file a CVE request for the issue.
(In reply to Donncha Ó Cearbhaill from comment #9) > Phil Wyett has provided a debdiff of the .desktop fix backported to 3.22.3. > Is that patch acceptable for you? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=860268; > filename=nautilus_3.22.3-1_to_nautilus_3.22.3-1.1.debdiff;msg=19 > > I'll file a CVE request for the issue. Sorry, I just remember this has UI changes. This cannot be accepted upstream since we don't have UI changes in stable branches. Should be fine as downstream patch, and you might want to cherry-pick translations for those string changes too.
Okay, thank you. I'll follow-up with Debian about downstream backport.
Created attachment 359888 [details] [review] Backported patch containing cherry-picked translations
I've updated a backport of your patch to include translations for the "Trust and _Launch" string. It looks like .gmo file are built and included in the upstream release? I'm trying to rebuild the gmo files with the new translations during the Debian package building process. Do you know what modifications I need to make in order to force a rebuild of the gmo files? Phil Wyett opened a ticket on the Redhat bug tracker in order to get this fix backported to RHEL and Fedora too.
Cool. No I don't know off hand about gmo files, a wild guess: maybe you need to distcheck? Otherwise I'm sure someone in #gnome-hackers could help you, I know few who cherry picked translations in the past as downstream patches.
Hi, Any news on the CVE assignment ? I can request one from Red Hat if needed.
Hi, I have not been received the CVE yet. I requested the CVE from the Distributed Weakness Filing project. I don't want to cause any confusion by requesting a CVE for the same issue twice. If you think that it is not a problem, the please feel free to request one from Red Hat instead.
Turnaround time from DWF is generally upwards of four months in my experience (I've used it three times). It will come through eventually, and you will have a duplicate if you get impatient and request one somewhere else.
4 months would mean we would hit the anniversary of the discovery before getting a CVE :) I sent a request to mitre.org, stating that there may be a request on the fly already & got a quick answer with a CVE ID. This vulnerability is now known as CVE-2017-14604 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14604 Hopefully, DWF will check around here before assigning anything.
(In reply to Cedric Buissart from comment #18) > 4 months would mean we would hit the anniversary of the discovery before > getting a CVE :) > I sent a request to mitre.org, stating that there may be a request on the > fly already & got a quick answer with a CVE ID. > > This vulnerability is now known as CVE-2017-14604 : > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14604 > > Hopefully, DWF will check around here before assigning anything. Reading the CVE, it points to Nautilus in GitHub. That is not the canonical source and could be removed at any point. Use git.gnome.org instead.
Cedric, thank you for getting the CVE issued. That's much better than waiting for the anniversary :) I'm following up with Debian to try and get this issue resolved downstream.
Hey, @Carlos Soriano: I just read the patch and can't help to wonder what you actually mean by "use file metadata". What does + nautilus_file_set_metadata (parameters->file, NAUTILUS_METADATA_KEY_DESKTOP_FILE_TRUSTED, + NULL, + "yes"); actually do? Does it somehow attach a trusted flag to file itself (via xattrs?)? Or does Nautilus keep a path-based whitelist somewhere? Because that would be dangerous...
Ok, I tested this: $ nautilus --version GNOME nautilus 3.26.0 $ Let's see if the "trusted" flag is associated with the file itself or the path: $ printf '[Desktop Entry]\nName=42\nExec=gnome-terminal\nType=Application' > foo.desktop $ ls -l total 4 -rw-r--r-- 1 alexander alexander 60 Oct 8 17:57 foo.desktop $ # nautilus shows one file "foo.desktop" $ chmod +x foo.desktop $ ls -l total 4 -rwxr-xr-x 1 alexander alexander 60 Oct 8 17:57 foo.desktop $ # nautilus still shows one file "foo.desktop" $ # use nautilus to start "foo.desktop" and mark it as trusted $ # nautilus starts gnome-terminal and now displays one file "42" $ ln foo.desktop bar.desktop $ ls -li foo.desktop bar.desktop 12218402 -rwxr-xr-x 2 alexander alexander 60 Oct 8 17:57 bar.desktop 12218402 -rwxr-xr-x 2 alexander alexander 60 Oct 8 17:57 foo.desktop $ # nautilus shows two files, "42" and "bar.desktop" It appears to be path-associated, since only "foo.desktop" is displayed as "42" even though "foo.desktop" and "bar.desktop" are the same file. Let's try something: $ rm --verbose foo.desktop bar.desktop removed 'foo.desktop' removed 'bar.desktop' $ printf '[Desktop Entry]\nName=42\nExec=gnome-terminal\nType=Application' > foo.desktop $ chmod +x foo.desktop $ # nautilus displays one file "42" $ Wow, so removing the "trusted" file and then re-creating it in the same path bypasses this new "trusted" flag. All that's left is the executable bit which isn't enough as shown by the initial bug report. TL;DR: User using nautilus for some time and sometimes "trusting" .desktop files will have an ever growing (is there a way to clear it?) whitelist of paths where the executable bit is again all that's needed for pwnage. Now, combine this with XDG_DOWNLOAD_DIR and this becomes a problem...
Oh, and also this: $ printf '[Desktop Entry]\nName=42' > baz.desktop $ ls -l total 4 -rw-r--r-- 1 alexander alexander 23 Oct 8 18:08 baz.desktop $ # nautilus displays one file "42" $ So for .desktop files not containing an Exec= (or Type=Application) setting neither the executable bit nor the new "trusted flag" check seem to be active. Not yet sure if this is exploitable, but it sure seems fishy.
Yup, can at least be used for tracking: $ printf '[Desktop Entry]\nName=CV.pdf\nIcon=x-office-document\nType=Link\nURL=https://gnome.org' > baz.desktop $ ls -l baz.desktop -rw-r--r-- 1 alexander alexander 82 Oct 8 18:20 baz.desktop $ # nautilus shows a file "CV.pdf" which looks like a symbolic link $ # clicking on "CV.pdf" opens a web browser showing gnome.org So, reading the spec [0] for five minutes gave a privacy leak. oO Why exactly does nautilus even parse .desktop at all? Isn't starting applications more of Gnome Shell's domain? [0] https://developer.gnome.org/desktop-entry-spec/
Hurray for "be liberal in what you accept from others" (i.e. just ignore the spec, we don't need no "Type="!) $ cat baz.desktop [Desktop Entry] Name=CV.pdf Icon=x-office-document URL=http://gnome.org $ ls -l baz.desktop -rw-r--r-- 1 alexander alexander 72 Oct 8 18:32 baz.desktop $ # nautilus shows a file "CV.pdf" which looks like a regular PDF $ # clicking on "CV.pdf" opens a web browser showing gnome.org Nautilus 3.26. No x-bit or trusted flag. Visually indistinguishable from a regular PDF. Can open arbitrary URLs.
Another vector to the same goal, abusing legacy compatibility [0]: $ cat baz.desktop [Desktop Entry] Name=CV.pdf Icon=x-office-document Type=URL Exec=http://gnome.org $ ls -l baz.desktop -rw-r--r-- 1 alexander alexander 82 Oct 8 19:31 baz.desktop $ # nautilus shows a file "CV.pdf" which looks like a regular PDF $ # clicking on "CV.pdf" opens a web browser showing gnome.org $ [0] https://github.com/GNOME/nautilus/blob/3.26.0/src/nautilus-link.c#L383
For the record, the "trusted metadata" gets stored to (after a frankly insane function call tour through Nautilus and GLib) to a file under ~/.local/share/gvfs-metadata, so removing this directory should reset all "trusted" markings. And yeah, it's definitely path based: alexander@shepard:~/.local/share/gvfs-metadata$ hd root-8daa6d16.log 00000000 da 1a 6a 6f 75 72 01 00 8d aa 6d 16 00 00 80 00 |..jour....m.....| 00000010 00 00 00 01 00 00 00 38 c0 78 97 05 00 00 00 00 |.......8.x......| 00000020 59 da 6b 86 00 2f 68 6f 6d 65 2f 77 6f 6d 2f 62 |Y.k../home/wom/b| 00000030 61 7a 2e 64 65 73 6b 74 6f 70 00 74 72 75 73 74 |az.desktop.trust| 00000040 65 64 00 79 65 73 00 00 00 00 00 38 00 00 00 00 |ed.yes.....8....| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00008000 So, if you ever mark a launcher as trusted and then remove it, be sure to tell GVFS about it (does Nautilus at least do this?). Otherwise this specific launcher path has just gained a vulnerability for Bug 777991 / CVE-2017-14604. It's not hard to imagine an attack using this: Get the user to extract a good app in $XDG_DOWNLOAD_DIR and launch it, marking the launcher as trusted. (Much) later, get the user to extract a malicious tarball to the same directory. Boom.
Yes, that's how it works. Obviously there is an usability compromise. Otherwise I would just remove executable ability in the file manager, which is not something we have planned for now.
So all of this is "works-as-intended"? Even the link thing? Even though it enables fun like this? $ cat poc.desktop [Desktop Entry] Name=Emergency Contact.pdf Icon=x-office-document Type=URL Exec=mailto:firedepartment@example.com?subject=Fire&body=Dear%20Sir%2FMadam%2C%0A%0AFire!%20Fire!%20Help%20me!%0A%0A123%20Carrendon%20Road.%0A%0ALooking%20forward%20to%20hearing%20from%20you.%0A%0AAll%20the%20best%2C%0A%0AMaurice%20Moss $
That's how desktop files work, yes.