.desktop files, serious security hole, virus-friendliness

Sam Watkins sam at nipl.net
Tue Apr 4 06:57:09 EEST 2006


I'll go over this again and describe what I consider to be the solution
in detail.


  .desktop files contain executable code (shell script) but are not
  presently required to be marked executable (to differentiate them from

small rant :p

  This is a design fault, a classic "trojans please come and destroy my
  computer" sort of situation.  MS Windows does not differentiate
  documents and executables in any sensible way.  This is the main
  reason why MS Windows is so incredibly plagued with malware.
  Let's not do the same thing to *NIX.

  In my opinion the only reason why we don't have any .desktop trojans
  happening already with *NIX is because Gnome and KDE aren't yet very
  popular, compared to Windows, and no one is trying to write malware to
  attack *NIX desktops.  This does not mean we should ignore the problem!

example scenario:

  1. user clicks some link in firefox, expecting to be downloading
  something he/she wants.  Firefox says "do you want to download or view
  it" user says yes without really checking what's going on.  Firefox
  downloads it automatically onto the user's desktop.

  2. this trojan .desktop file masquerades as some sort of document or
  existing common icon (this is a minor problem in itself)

  3. the user clicks the trojan .desktop file's icon.  The trojan .desktop
  file does evil stuff to the user and perhaps even propogates itself.

suggested remedy:

1. changes to gnome, kde, etc.:

  a. A .desktop file may be executed directly, ONLY if it has the "x"
     bit set, or it is owned by root (i.e. probably part of an installed
     application).  This latter is a low-risk exception, I recommend
     this to avoid breaking existing packages, and to avoid having to
     harass 10^6 package maintainers and developers.

  b. Otherwise, a .desktop file is regarded to be "unsafe", and must
     never be executed directly without user confirmation.

     If you click an unsafe .desktop file, a dialog pops up explaining
     the risk of malware, showing the "Exec=" code (and any other
     executable fields, maybe the whole file in a textarea).

     The dialog offers to make the .desktop file executable for you.
     Perhaps with "trust" and "don't trust" buttons.  "don't trust"
     should be focussed by default.  Other wording might be better.

     I feel that there should not be an option to disable this dialog.
     Even experts have been known to get in trouble when accidentally
     clicking the wrong thing or pressing enter at the wrong time.

  d. If the user chooses to make a .desktop file executable,
     we should prepend an appropriate #! line, e.g.

       #!/usr/bin/env run-desktop

     This is so a .desktop file will do the right thing if invoked
     from the command-line or otherwise exec'd.  Without this #! line
     the .desktop file would be sent to the shell and the shell gives
     a whole lot of error messages and potentially do something
     harmful.  Some Python scripts use this thing with "env" to avoid
     specifying either /usr/bin/python or /usr/local/bin/python.
     Ideally we'd have symlinks to all interpreters in /lang.

     Now the GUI can continue and execute the .desktop file's Exec
     script in the normal way (it need not use run-desktop).

  e. If we exec an (executable) .desktop file without an #! line, it
     would be sent to the shell.  Apparently the first line of all
     .desktop files is "[Desktop Entry]".  We might include a program
     called "[Desktop" in the path, which sends SIGHUP to its parent
     process (the rogue shell).

     If for some reason my recommendation to add #! lines to .desktop
     files when marking them executable is not possible,
     installing a program called "[Desktop" in the PATH is an
     alternative (but hacky!).  I can't think of a portable way to make
     it actually execute the .desktop file's Exec= script.

  f. I think a .desktop file without the "x" bit set should be displayed
     with it's preferred name, and icon, so long as the pop-up dialog is
     sufficiently frightening and provides all the information, and the
     "don't trust" button is focused by default.

     Alternatively an unsafe .desktop file might be given a special
     "untrusted" icon or something like that, or even .

2. the run-desktop script

  a. This is only so that the .desktop files can be run from the
     command-line.  If they're marked "+x", they should do the right
     thing when exec'd in the normal unix way.

By the way I think that to use digital signatures to protect the user
against bogus .desktop files would be overkill.  I don't see the need
for anything that complicated.


Sam Watkins

More information about the xdg mailing list