#856 Security vulnerability with desktop files

1.2
closed-rejected
None
5
2016-07-20
2014-03-31
Sworddragon
No

I'm not sure if this should be reported against PCManFM or the XDG specifications. If you tell me that this can't be changed because of the specifications I will forward this report. Now to the problem:

The ability that dektop files can hide their real name behind the Name key while they can always execute applications is a security problem. Here is an example desktop file that demonstrates this:

[Desktop Entry]
Exec=sh -c 'xdg-open /usr/local/share/image/hot_girl.jpg; /usr/local/bin/keylogger'
Icon=/usr/share/icons/nuoveXT2/48x48/mimetypes/image.png
Name=hot_girl.jpg
NoDisplay=true
Type=Application

The desktop file hides behind the name hot_girl.jpg to increase the chance people will open it. To make this even more realistic it uses also the image icon to look like a real image in the file manager. If executed it will open a real image so that the user doesn't get suspicious but it will also execute malware that does now log all input.

A similar problem existed/maybe still exists on Windows where at default file extensions are hidden which caused many infections in the past. But currently we are even providing a better way to infect a system with a full name and icon disguise kit.

A way to fix this could be an option that enables a safe mode for desktop files. Enabling it could do the following:

  • The Name key will always be ignored from desktop files.
  • Desktop files will only be recognized as desktop files if they have a .desktop file extension.

I think these changes should be enough to make desktop files safe but maybe further thoughts should be made about this.

Discussion

  • Lonely Stranger

    Lonely Stranger - 2014-04-19
    • status: open --> closed-rejected
    • assigned_to: Lonely Stranger
     
  • Lonely Stranger

    Lonely Stranger - 2014-04-19

    Well, if user created such file himself then who is a doctor for his/her stupidity? The same goes when user downloads some script and runs it, etc. There is no other way user may get such file to launch it. The hiding file system name behind displayable name is the main purpose of application file, the same as for any other shortcut type files. If you don't want it then don't use it, and if you create/download it then double think about what you are doing. Your 'safe_mode' can be achieved by creating app.sh file instead of app.desktop one, with appropriate contents, it will run your application still but not show any other file name.
    Thank you.

     
  • Sworddragon

    Sworddragon - 2014-04-19

    There is no other way user may get such file to launch it.

    • Compromised repository packages.
    • Zero-day-exploits.
    • etc.

    But can you tell me if you are just following strictly the XDG desktop specifications or if this is a user-defined behavior of PCManFM? I have already made a look into the XDG desktop specifications but am unsure about this.

     
  • Lonely Stranger

    Lonely Stranger - 2014-04-19

    You are wrong. Compromised package will install desktop file not onto desktop (or whatever) but into menu, and in that case menu will never show desktop-id but rather contents of Name field as stated in XDG standards for desktop menu. The XDG standard for menu desktop files requires them to have .desktop suffix, BTW, and that rule is followed by libmenu-cache.

    And your case is when user creates (or downloads) such file on the desktop (or in another folder). The way as non-menu .desktop files are shown in file manager is not defined in XDG standard AFAIK, and LibFM uses conventions which every other file manager uses (so it is de-facto standard) when file suffix isn't relevant.

     
  • Sworddragon

    Sworddragon - 2014-04-19

    Compromised package will install desktop file not onto desktop

    Repository packages can also install files on the users desktop if they want.

    The XDG standard for menu desktop files requires them to have .desktop suffix

    Unfortunately not: "When no file extension is present, the desktop system should fall back to recognition via "magic detection"."

    The way as non-menu .desktop files are shown in file manager is not defined in XDG standard AFAIK

    Thanks for the clarification.

     
  • Lonely Stranger

    Lonely Stranger - 2014-04-19

    Repository packages can also install files on the users desktop if they want.

    It is invalid behavior. Repository packages may install only system-wide things which will never touch user-wide things. Only user-driven installations (such as download files and run some install script) may install user-wide things such as files on the desktop. That is also described in Linux standards.

    Unfortunately not: "When no file extension is present, the desktop system should fall back to recognition via "magic detection"."

    You are quoting wrong text, that text has no relation to menu. XDG menu standard is http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html and there is a statement: "Only files ending in ".desktop" should be used, other files are ignored."

     
    Last edit: Lonely Stranger 2014-04-19
  • Sworddragon

    Sworddragon - 2014-04-19

    It is invalid behavior. Repository packages may install only system-wide things which will never touch user-wide things. Only user-driven installations (such as download files and run some install script) may install user-wide things such as files on the desktop. That is also described in Linux standards.

    An attacker which got successfully a compromised package into a repository doesn't care about standards.

    You are quoting wrong text, that text has no relation to menu.

    Ah, thanks, I have thought the desktop and menu are handled in the same specification.

     
    Last edit: Sworddragon 2014-04-19
  • Lonely Stranger

    Lonely Stranger - 2014-04-19

    In any case, if you are root and know nothing about users (which is the case when you install repository package by means of synaptic or whatever) it is much more safe and efficient to install system-wide menu item:
    1) details of application in menu are guaranteed hidden from any user;
    2) when system install creates something on user desktop it is very suspicious.
    Therefore compromised repository package will never try to install anything on desktop, only user-driven install would. And for such things all I told you above is still valid. Well, it is still possible to add an option to disable desktop files support but I suspect it will be never ever used at all so it will be just a disadvantage to handle option that is never used and may confuse some users.

     
  • taroyamada

    taroyamada - 2016-07-19

    I'm sorry for this kind of necrobumping, but I think Sworddragon is correct.
    The problem is a combination of three proper behaviors.

    1. Displaying the value of the Name key in place of its actual file name.
    2. Displaying the icon of the Icon key in place of its actual file type.
    3. Executing the command of the Exec key on click without any notification regardless of whether it is reliable.

    Each element is not much of a problem by itself.
    But when these three conditions are met, it induces the user's misoperation.

    The user downloads the set of wallpapers from the internet and it contains the .desktop file which camouflages as jpg image file.
    The user misidentifies that the file is jpg image file because its filename looks hot_girl.jpg and its icon looks jpg.
    Then the user clicks to open this jpg file (actually it is .desktop file.) and arbitrarily command will be executed without user's intent.

    Other FM is trying to solve this problem in a variety of ways.
    1.On the file manager, display the actual file name in place of the value of the Name key.
    (Of course, display the value of the Name key on the menu.)
    2.If the .desktop file is not on the proper path(e.g. /usr/share/applications/ ~/.local/share/applications/ ), display a confirmation dialog before executing the command of Exec key.
    3...

     
    Last edit: taroyamada 2016-07-19
  • Sworddragon

    Sworddragon - 2016-07-20

    Just to note that I have created shortly after this ticket another ticket against the related XDG specification: https://bugs.freedesktop.org/show_bug.cgi?id=77721

    I think the discussion with potential ideas should be mainly focused at the linked ticket as fixing this issue at the specification would automatically fix this issue for any filemanager that commonly intends to follow the newest specification. So maybe you want to throw in your ideas at the linked ticket again.

     

Anonymous
Anonymous

Cancel  Add attachments