Security issue with .desktop files revisited

[Francois Gouget]

Rodney Dawes wrote:
> On Wed, 2006-04-12 at 14:46 +0200, Francois Gouget wrote:
> 
>>In order to run an executable one must have the execute permissions for 
>>that executable. Whether you like it or not .desktop files are 
>>executables and, as such, running them ('opening' them in desktop 
>>parlance) should require that you have the relevant execute permissions.
>>
>>Requiring +x on .desktop files also makes it possible to add an emblem 
>>to the icon of those that lack it, and/or to issue a warning when the 
>>user tries to run them. Thus this also protects users from .desktop 
>>files that have a misleading icon.
> 
> It doesn't prevent the .desktop file from having a misleading icon at
> all. You're not changing the semantics of what goes in the Icon field.

There is no need to change the specification of the Icon field. As I 
said the desktop environment can overlay an emblem that identifies the 
file as untrusted which makes it easy to differentiate the undtrusted 
.desktop file from whatever type of file it is trying to pass off as. If 
an emblem is not enough, the desktop environment could ignore the 
.desktop icon entirely for files that don't have the +x permission.

There are two categories of .desktop files:
  * those installed by the system, typically as part of KDE, Gnome or 
third party software. Those are trusted. They should be able to have any 
icon they want with no overlaying emblem. And they should also be able 
to run any command they want without pesky warnings.
  * and then there is those that got downloaded off the internet or come 
from other untrusted sources. Those must not be allowed to execute 
without a warning to the user. We also don't want them to be able to 
show any icon they want, or we at least want to overlay an emblem of 
some sort to avoid confusion.

The one question is: how do we distinguish .desktop files from the first 
category from .desktop files from the second category.
Four solutions have been proposed:

1) Define and use an 'Untrusted' Extended Attributes
----------------------------------------------------

Mechanism:
    Require that applications actively set this Extended Attribute to 
files coming from untrusted sources. Then the desktop environment and 
related applications would check for this attribute and treat such files 
appropriately.

Pros/Cons:
    * Requires a modification of the browser, email clients, etc to put 
this attribute on downloaded files.
    * A mount option could automatically add this extended attribute to 
all files coming from other untrusted sources like usb keys, floppy 
disks, etc.
    * Extended attributes are fragile in that tar does not preserve them 
(currently), many file systems don't support them, etc.
    * Requires further modifications to tools like tar so files 
extracted from untrusted archives 'inherit' the untrusted attribute, 
unless a special command line option is specified. Same thing for cp, 
mv, etc.
    * This is independent from the traditional permission bits and thus 
can be used for any type of file, including office documents or whatever 
presents the slightest risk.
    * Probably hard to manage.
    * Might be a long term solution but it will take years to put in place.


2) Use the +x permission bit
----------------------------

Mechanism:
    In this scheme .desktop files that are missing the +x bit are 
considered untrusted. This relies on the fact that downloaded .desktop 
files don't have the +x bit set and can thus be treated in a special way.

Pros/Cons:
    * Requires no modification of browsers, email clients, etc since 
they should already not be putting the +x permission on downloaded files.
    * Requires modifications to the desktop environments and file 
managers so they check the +x bit on .desktop files and take appropriate 
action.
    * Requires modifications to the packages shipping .desktop files so 
they have the +x execute bit. Fortunately there is no technical obstacle 
to that.
    * Mount options make it possible to decide whether material stored 
on a filesystem that does not support Unix permissions will be treated 
as trusted or not. This takes care of USB keys, floppies, Windows 
partitions, etc.
    * Makes sense independently of any security consideration because 
.desktop files are equivalent to shell scripts: they are text files 
whose primary purpose is to start applications and that can run 
arbitrary commands. As an added bonus, if they start with 
'#!/usr/bin/xdg-open' they can also be run from the command line.
    * An attacker could ship the .desktop file in an archive so that 
extracting that archive would create a .desktop file with the +x 
permission set. The same scenario can happen with shell scripts and ELF 
binaries too, except that the .desktop file would be displayed with 
whatever icon it wants. This scenario still requires an extra step 
before the user can run the .desktop file, rather than just an 
accidental click.


3) Add a cookie
---------------

Mechanism:
    Add a Cookie field to .desktop files. This field would contain a 
hard to predict value specific to the computer or user, for instance the 
hexadecimal representation of a random 128bit number. At least one 
cookie is needed. That cookie would would be generated when installing 
the OS, would be stored in /etc/xdg-cookie for instance. Only .desktop 
files containing this cookie would be trusted.
    This mechanism relies on the fact that the attacker cannot predict 
the value of the cookie so that his .desktop files would either be 
missing that field, or have the wrong value, thus identifying them as 
untrusted.
    A variant would add a secondary per-user cookie to protect the 
system's users from each other. Note that this requires that the system 
cookie be only considered valid for .desktop files that belong to root 
and that the secondary cookie only be considered valid if the .desktop 
file belongs to the user.

Pros/Cons:
    * Makes it impossible to ship prebuilt .desktop files in software 
packages such as Debian or RPM. All .desktop files would have to be 
modified at install time which is a significant change from the current 
situation. Such files would also be reported as different from the copy 
that shipped in the RPM/Debian packages. That would make tools such as 
debsums and rpm --verify much less useful.
    * Makes it impossible to put /usr/share on an NFS filesystem and 
share it for multiple systems unless those systems all use the same cookie.
    * Works on any filesystem.


4) Sign the .desktop files
--------------------------

Mechanism:
    Add a Signature field to .desktop files and use it to store a 
cryptographic signature of part or all of the other .desktop file 
fields. Since this relies on the attacker not being able to generate a 
valid signature for his .desktop file, this requires each computer to 
have a unique key.

Pros/Cons:
    * Like for cookies, this makes it impossible to ship prebuilt 
.desktop files in software packages such as Debian or RPM.
    * Like for cookies, this makes it impossible to easily put 
/usr/share on an NFS filesystem.
    * Works on any filesystem.
    * Can also detect modifications to .desktop files though this seems 
of limited value.


[...]
> Users are going to just get into the habit of always doing chmod
> +x, as we have already been doing for perl/python/etc... scripts that
> we download off the web.

So you want to tackle the problem of users chmoding scripts they 
download from the web too? Good luck!


[...]
> I don't mean to write a proposal to change the semantics of Exec. It was
> a suggestion as a method for actually solving the real problem, instead
> of just sticking our heads in the sand and pretending like the +x bit is
> going to make all the problems go away. We need to either actually fix
> the problem, or stop overreacting about it.

So you're not proposing to change the semantic of the Exec field after 
all. Good because no change to it is going to do anything to solve the 
problem.


 > A .desktop file that simply
> removes all your files is not a realistic attack these days.

You're missing the point which was that simple command can do harm and 
that determining whether a command is harmless or not requires 
intelligence and knowledge, both of which computers are lacking.


-- 
Francois Gouget
fgouget at codeweavers.com