Security considerations of type 1 desktop files
Desktop files are textual configuration files
that are used by file managers and window managers.
As noted above, their format is
specified by a FreeDesktop standard:
Both the KDE and GNOME desktop environments have adopted a similar format for
"desktop entries", or configuration files describing how a particular program
is to be launched, how it appears in menus, etc. It is to the larger
community's benefit that a unified standard be agreed upon by all parties
such that interoperation between the two environments, and indeed any
additional environments that implement the specification, becomes simpler.
The current FreeDesktop specification
lists three different kinds of desktop entries:
This specification defines 3 types of desktop entries: Application (type
1), Link (type 2) and Directory (type 3). To allow the addition of new
types in the future, implementations should ignore desktop entries with an
unknown type.
The security implications of Application (type 1) desktop files
have been discussed at length multiple times on the FreeDesktop mailing list:
I noticed quite a while ago that .desktop files as specified by
freedesktop.org open a window into GNU/Linux for a whole range of
viruses and trojans. I think that this has been discussed
before. I see that the issue has not been resolved so I'd like to
suggest a way to resolve it.
Conventionally files downloaded from the Internet cannot simply be
"clicked" to run them under unix/GNU/Linux, the execute permission must
be granted (or an installer used or archive extracted).
--- Sam Watkins,
".desktop files, serious security hole, virus-friendliness",
April 2006
(LWN summary)
In the event that the launch would have been forbidden based on the preceding
restrictions, the user is given the option of automatically making the service
executable and then launching. Although this part makes me a bit queasy I
think it's the best option to easily allow existing Desktop icons, panel
launchers, etc. to continue to work.
--- Michael Pyne,
".desktop file security",
February 2009
To the best of my knowledge,
there is only one CVE associated with desktop files:
CVE-2017-14604.
GNOME Nautilus before 3.23.90 allows attackers to spoof a file type by using
the .desktop file extension, as demonstrated by an attack in which a .desktop
file's Name field ends in .pdf but this file's Exec field launches a
malicious "sh -c" command. In other words, Nautilus provides no UI indication
that a file actually has the potentially unsafe .desktop extension; instead,
the UI only shows the .pdf extension. One (slightly) mitigating factor is
that an attack requires the .desktop file to have execute permission. The
solution is to ask the user to confirm that the file is supposed to be
treated as a .desktop file, and then remember the user's answer in the
metadata::trusted field.
There's more background here if you're curious:
nautilus: CVE-2017-14604: .desktop files can hide malware in Nautilus
There is a bug in Nautilus that makes it possible to disguise a
malicious script as an innocent document, like a PDF or ODT, that gets
executed when the user opens it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268
The exploit I created is a file called sgos_handbook.pdf.desktop (though I
could have named it malware.desktop and it would have looked the same in
Nautilus). Here’s what’s inside of it. Note that the name is set to
sgos_handbook.pdf, and the icon is gnome-mime-application-pdf which is
the default icon for PDFs in Subgraph — these two things make it so you can’t
tell that this isn’t a PDF when viewing it in Nautilus.
https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/
Here's a simplified version of the proof-of-concept malicious desktop file:
[Desktop Entry]
Name=my-file.pdf
Exec=sh -c "xeyes"
Type=Application
Icon=gnome-mime-application-pdf
The icon looks like a PDF file,
but rather than opening a PDF file,
it runs a shell script that runs xeyes.
Of course, xeyes could just as easily be rm -rf $HOME
or something similarly malicious.
This has since been fixed
by requiring the user to actively trust the desktop file
before the file manager displays the custom icon and name.
Other purposes of desktop files.
However, desktop files are used for more than
associating mimetypes and launching applications.
Let's start with type 3,
which are desktop entries
but are .directory files,
not exactly .desktop files.
Directory files (type 3)
Directory files (type 3) are mainly used for creating categories
in hierarchical menus; that's what the Categories
key is for in type 1 desktop files.
For example, consider this example
from /usr/share/desktop-directories/Utility.directory:
[Desktop Entry]
Name=Accessories
Comment=Desktop accessories
Icon=applications-utilities
Type=Directory
X-Ubuntu-Gettext-Domain=gnome-menus-3.0
So if a desktop file has "Utility" in its Categories key,
it will show up in the Utility menu subdirectory.
The Dolphin file manager also uses directory files
to e.g. enable/disable thumbnail previews of images.
As far as I know,
there is no reason for .directory files to be executable.
Link-type desktop files (type 2)
Link-type desktop files can point to arbitrary URLs.
This makes it easy to store
relevant links or URL in a given directory.
Currently, most file managers require link-type desktop files to be executable
before opening the URL.
This makes sense,
because although opening a URL is not equivalent to running arbitrary code,
file:// URLs can point to executables,
and URLs in general can be malicious.
file URLs
For example, in Ubuntu the example-content package
adds a type 2 desktop file
similar to this in the home directory:
[Desktop Entry]
Type=Link
Name=Examples
Comment=Example content for Ubuntu
URL=file:///usr/share/example-content/
Icon=folder
Double-clicking on this desktop file in a file manager
will navigate to the /usr/share/example-content/ folder.
Link-type desktop files can also point to files.
For example, here's one that opens the manual for the LaTeX hyperref package:
[Desktop Entry]
Type=Link
Name=hyperref manual
URL=file:///usr/share/doc/texlive-doc/latex/hyperref/manual.pdf
http/https URLs
Link-type desktop files can also be used to open HTTP URLs in the browser.
For example, here is a desktop file linking to this page:
[Desktop Entry]
Name=What is the advantage of .desktop files without executable bit set?
Type=Link
URL=https://unix.stackexchange.com/questions/373239/what-is-the-advantage-of-desktop-files-without-executable-bit-set
This isn't the most cross-platform option,
but it is
widely
used.
other URLs
Link-type desktop files can contain arbitrary URLs;
as long as there is a handler registered for the URI scheme,
they will work.
For example, a desktop file could contain a mailto: URL:
[Desktop Entry]
Name=Email Linus Torvalds
Type=Link
URL=mailto:torvalds@transmeta.com
or an smb:// URL:
[Desktop Entry]
Name=My Samba share
Type=Link
URL=smb://username@server/my-samba-share
or a special file-manager URL like this:
[Desktop Entry]
Name=Trash
Type=Link
Icon=user-trash-full
EmptyIcon=user-trash
URL=trash:///
or this:
[Desktop Entry]
Name=Recent documents
Type=Link
Icon=document-open-recent
URL=recent:///
Related links.
$XDG_DATA_DIRS/applicationsonly to local files placed in$XDG_DATA_HOME/applications– don_crissti Jun 25 '17 at 13:16