! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Hiding filename/extention for .desktop files with execute permission.


Description Mathias Svanbäck 2017-02-02 19:21:26 CET
Created attachment 6980 
Screenshot of malicious .desktop file displayed in Thunar

Hiding the filename/extention may be used to trick users to execute arbitrary code.

How to reproduce:

1. Create a file called malware.desktop 

2. Add the following content to it:

[Desktop Entry]
Exec=sh -c 'touch ./MALWARE_WAS_HERE'

3. Make it executable

Thunar 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.

How to fix it:

Maybe by don't hiding the filename for .desktop files at all.

/u/wander_homer brought it up

For reference, this bug also applies to other file managers:
Comment 1 Mathias Svanbäck 2017-02-02 19:54:38 CET
Created attachment 6981 
Could maybe append the .desktop extention to the display_name while in the filebrowser.

Just to indicate the filetype to the user of what kind of extention it actually is.
Comment 2 Mathias Svanbäck 2017-02-07 11:43:20 CET
Hosting the suggested patch on my github

Comment 3 Yves-Alexis Perez editbugs 2017-10-05 22:13:08 CEST
The same kind of issue has been assigned CVE-2017-14604 in Nautilus. See also 

https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/ and 

The executable bit protection can be somehow bypassed by for example shipping a tarball which would be extracted by an user. For Nautilus it's even worse because apparently if the .desktop file is called foo.desktop.pdf it'll be displayed as a PDF icon but handled as a .desktop file.

Nautilus fixed it by storing the “executable” / “trusted” information in a metadata, which is apparently a gio/gvfs stuff, stored on the filesystem in XDG_DATA_DIR/gvfs-metadata (usually .local/share/gvfs-metadata), which is supposingly not reachable when extracting a tarball (unless there's a directory traversal vulnerability in the extraction process).

I'm not sure if something like that applies to Thunar, but it'd be nice to have additional hardening.
Comment 4 alexxcons editbugs 2019-05-01 23:52:23 CEST
Created attachment 8471 
Show real filename for .desktop files

As a first step, I would prefer to just display the real filename, instead of "Startername".desktop, which possibly will add more confusion.  (That's what Nautilus and as well Dolphin do )
Could be pushed soon, so that's available directly in xfce 4.14
Would that be fine for you ? (Please test the attached patch if you have time)

Regarding the second step, internally saving the executable bit:
Since gvfs is optional for thunar, I dont think we should follow the nautilus aproach of storing the exec bit in gvfs.

Instead we possibly could store a whitelist of all .desktop files allowed to be executed in xfconf  (full path) instead of relying on the executable bit. Both, thunar and xfdesktop should use the list to check execution permission.
A drawback: Renaming a .desktop file would require a second confirmation .. though I think this would be tolerable. 
Any arguments against the proposal ?
Comment 5 Git Bot editbugs 2020-05-26 23:29:25 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/156.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #13329

Reported by:
Mathias Svanbäck
Reported on: 2017-02-02
Last modified on: 2020-05-26


Xfce Bug Triage
CC List:
7 users




Additional information