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] Name=CV.pdf Exec=sh -c 'touch ./MALWARE_WAS_HERE' Terminal=false Icon=x-office-document Type=Application Categories=Office 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 https://www.reddit.com/r/linux/comments/5r6va0/how_to_easily_trick_file_manager_users_to_execute/ 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
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.
Hosting the suggested patch on my github https://github.com/MatteO-Matic/thunar/tree/Matte_ShowDesktopExtention_20170201_070840
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 https://bugzilla.gnome.org/show_bug.cgi?id=777991 https://github.com/GNOME/nautilus/commit/1630f53481f445ada0a455e9979236d31a8d3bb0 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.
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 ?
-- 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