.desktop files, serious security hole, virus-friendliness
Sam Watkins
sam at nipl.net
Tue Apr 4 06:57:09 EEST 2006
hi,
I'll go over this again and describe what I consider to be the solution
in detail.
problem:
.desktop files contain executable code (shell script) but are not
presently required to be marked executable (to differentiate them from
documents).
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.
peace,
Sam Watkins
More information about the xdg
mailing list