.desktop files and security
There is been an ongoing level of concern over these files, most recently voiced by Sam Watkins on the XDG mailing list. The issue that that .desktop files are, for all practical purposes, shell scripts capable of doing anything that the user can do. But they do not have to be marked as executable, and they have complete control over how they are presented on the desktop. A .desktop file can show up as a document or image file, but actually be some sort of hostile script. A user, hoping only to view a file which has shown up on the desktop, may end up running something entirely different.
A number of ways of addressing the issue have been proposed. The simplest, perhaps, is to require that .desktop files have execute permission to be launched. Since setting that bit requires an explicit action on the part of the user, a hostile icon cannot be put directly onto the desktop by, for example, a file downloaded via a web browser. Some people have objected that .desktop files are not actually executables - they cannot be run from the command line. Putting a suitable #! line at the beginning of the file would fix that, however.
Another possibility would be to mark known-good .desktop files with an extended attribute. If an attempt was made to launch an unmarked file, a suitably scary dialog would be put up and confirmation required from the user. Or, .desktop files with executable content could be restricted in the set of icons they could use, so that, at least, the fact that a program would be run would be obvious. Or some sort of global system database could keep track of the trusted .desktop files.
Perhaps the most elaborate suggestion is to run all .desktop programs (and perhaps others) in a tightly-restricted sandbox with little access to the rest of the system. With some work, the desktop environment could be reworked to make most things work transparently for users. For example, selecting a file in a file-browser dialog would grant the right to access that file to the associated application. The Plash project has made progress toward the implementation of such a system.
Which of these solutions will be adopted, if any, remains to be seen. It
is not clear that everybody sees a real problem with the capabilities of
.desktop files. Experience has shown, however, that even difficult and
unlikely attack vectors will be exploited eventually. It would be a shame
if the adoption of desktop Linux were to be held back by security concerns.
Posted Apr 6, 2006 3:07 UTC (Thu)
by mrshiny (subscriber, #4266)
[Link]
Posted Apr 6, 2006 3:32 UTC (Thu)
by tetromino (subscriber, #33846)
[Link] (4 responses)
And then I realized that the program can be /usr/bin/perl. And the parameters can be -e and 'ANY_ARBITRARY_PERL_SCRIPT'
So yeah, this is quite bad. I say that making .desktop files into real #! scripts with an executable bit is the way to go.
Posted Apr 6, 2006 7:05 UTC (Thu)
by kitsilano (guest, #14833)
[Link] (2 responses)
Posted Apr 7, 2006 14:30 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (1 responses)
Yes it involves the user.. but this attack works 30% of the time from what I can tell from cleaning up windows machines.
Posted Apr 8, 2006 23:02 UTC (Sat)
by cortana (subscriber, #24596)
[Link]
Posted Apr 6, 2006 21:17 UTC (Thu)
by jmorris42 (guest, #2203)
[Link]
Plus by beating them over the head over this we just might impress on the clowns making the desktop environments that there is some value in retaining UNIX culture. This is a perfect example of the saying "Those who do not understand UNIX end up reinventing it... poorly." There are reasons for those executable bits, obviously some GNOME didn't understand that. And if it is 'executable' it should be runnable from a shell so it needs the #!. Again, the graphical folk have this religious belief that the command line is bad, and their ultimate goal is to eliminate it. We who believe in UNIX, everything is a file, yada yada have to push back hard now or admit defeat and load OpenBSD.
Posted Apr 6, 2006 4:17 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (1 responses)
And if we wait up for the congenital idiots who can't see the evil possibilities in the present situation we will calcify the present crappy situation in stone and be dealing with the consequences for a decade. If anyone wants to know what that future looks like they can boot a virgin install of Windows, connect it to a bare cable modem and wait an hour. This is an easily exploitable problem, we just have to pray it gets fixed before it gets used in the wild.
We all laughed when Microsoft thought it would be a neato idea to hide file extensions. Folks, this gets fixed or someday we are going to get the biggest comeuppance ever imagined. As currently implemented .desktop files are little suprise packages. Some versions of GNOME don't even provide an easy way to see what one is going to do before you launch em.
Security isn't something you do as an afterthought. What were they thinking? What were they smoking! Whatever moron originally implemented this mess needs to be blacklisted from contribution to a major project for at least a decade. Security by design needs to be the watch phrase.
Ok, had to get that rant out of my system...... :)
Posted Apr 6, 2006 10:32 UTC (Thu)
by Los__D (guest, #15263)
[Link]
This can't be allowed to happen much more than once, or world dominance will come with loads of desktop systems overtaken by nasty scipts and other malware (And then probably lost again just as fast, as it seems to be one of the top reasons people and companies are considering the switchover. Let's give them a chance to see the rest of the wonders before they regret, eh?)
Dennis
Posted Apr 6, 2006 12:23 UTC (Thu)
by erich (guest, #7127)
[Link]
For example, KDE apparently doesn't support .jpg files as icons, which totally sucks for album art. Which is the only case where I have used .desktop files so far, to display album art as folder icon.
Posted Apr 6, 2006 15:06 UTC (Thu)
by remijnj (guest, #5838)
[Link]
Given a choice between dancing pigs and security, users will pick dancing pigs every time.
Posted Apr 6, 2006 15:35 UTC (Thu)
by zooko (guest, #2589)
[Link] (4 responses)
Posted May 19, 2006 0:14 UTC (Fri)
by pimlott (guest, #1535)
[Link] (3 responses)
Posted May 19, 2006 3:40 UTC (Fri)
by zooko (guest, #2589)
[Link] (2 responses)
However, Plash (and Polaris) are doing something new that the Java sandbox paradigm did not do, namely dynamically extending the privileges available to the constrained code by observing what actions the user is asking the constrained code to perform.
We ought to use different terminology in order to make it clear to people that Plash and Polaris are not merely another attempt at implementing the failed Java sandbox paradigm. I've already made this suggestion in private e-mail to Mark Seaborn (of Plash). Now I'll make the same suggestion to Alan Karp.
Regards,
Zooko
Posted Aug 9, 2006 18:41 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (1 responses)
This is nonsensical... expand the limits according to what the user asks to be expanded? I.e., allow dancing pigs if asked?
Posted Aug 9, 2006 23:11 UTC (Wed)
by zooko (guest, #2589)
[Link]
See "Polaris" and "plash" for examples.
Posted Apr 7, 2006 3:41 UTC (Fri)
by th0ma7 (subscriber, #24698)
[Link] (3 responses)
I don't get coments like:
The ability for a user to use a program is to activate it in an easy manner... and this is, by far has I know, almost everytime represented by an icon on a GUI... unless we go back to a console using vim?
Posted Apr 7, 2006 15:34 UTC (Fri)
by dank (guest, #1865)
[Link]
Posted Apr 7, 2006 19:19 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (1 responses)
Humans also have horrible risk assessment skills. Many of us verge on climbing into the hole and welding it shut, and an equal many do not see the risks until after they have 'survived and gotten stronger, or didnt survive and doesnt matter'.
Trying to figure out the middle ground is the hard problem that we have to realize that people on both sides arent going to be happy with.
Posted Apr 10, 2006 19:04 UTC (Mon)
by jmorris42 (guest, #2203)
[Link]
Granted. But this one is simple to decide as soon as it is described. We have a file that can appear as anything it wishes to inside the graphical environment as both the icon and caption text being totally decided by the .desktop file itself, while the user has little or no way to discover what it will do when activated other than actually activating it or dropping to a command line and invoking less on it. But it can do absolutely anything it wants with the full execution rights of the user without requiring any privleges other than to be readable. So just what is the point of retaining the execute bit in file systems if this stands?
Posted Apr 7, 2006 19:49 UTC (Fri)
by job (guest, #670)
[Link] (2 responses)
Posted Apr 7, 2006 21:46 UTC (Fri)
by brouhaha (subscriber, #1698)
[Link] (1 responses)
The Macintosh had desktop icons since introduction in 1984, and they didn't (necessarily) have executable scripts or programs behind them.
The .desktop files only need to contain some simple metadata; it would be much more appropriate for them to be XLM, or even simple text files containing key/value pairs.
Posted Apr 11, 2006 18:54 UTC (Tue)
by droberge (guest, #10852)
[Link]
.desktop files aren't scripts; they really are only simple files with key=value pairs. The security problem comes from one of those values being an arbitrary command line and another one being an equally arbitrary image file to use as the icon. So, say, we could have one with Exec=/bin/rm -rf / and Icon=/path/to/jpeg/icon, which will look like a JPEG image but actually be a data-munching program invocation.
Posted Feb 12, 2009 8:28 UTC (Thu)
by andev (guest, #53743)
[Link]
The ability for a program to present any icon to the user IS definitely a problem; witness the spread of trojans on Windows platforms because of the default setup of Explorer (it hides file extensions). Users often click on what they think is a JPG when it is actually a program. Recent versions of Internet Explorer go to some lengths to try to inform the user that the file they've just downloaded is a program and it might be dangerous. Whether or not this feature works fully as intended, it is a step in the right direction. GNOME and KDE developers should take note of this issue, because it will affect their users as much as it has already affected Windows users..desktop files and security
At first, when I read the .desktop file spec, I didn't understand how horribly insecure these things are. I mean, the Exec parameter is just the name of a program and parameters. There is no shell syntax, no substitution. How much damage can that possibly do?.desktop files and security
I think the executable bit is a simple and unixoid way to solve the problem. You can still use all the flexibility build into the .desktop file. You could even run it from the shell. And any hostile .desktop files sent you by email has to be made executable, like any other executable sent to you. And if the Desktop Environment does not interprete a nonexecutable .desktop file and shows a scary icon, the security will be good enough..desktop files and security
Hmmm I dont think the executable bit would be the fix. The .zip attack is the way to get around that. Send the person a .zip file and they extract the stuff from it. Voila, the user pulls out the executable code with the appropriate bits/extensions in it. .desktop files and security
When extracting from an untrusted archive, tar, unzip and similar should be invoked with a sane umask that prevents the creation of executable files..desktop files and security
> So yeah, this is quite bad. I say that making .desktop files into real.desktop files and security
> #! scripts with an executable bit is the way to go.
> It is not clear that everybody sees a real problem with the capabilities.desktop files and security
> of .desktop files.
100% agreed, this is something most of us would have pointed fingers at M$ for doing..desktop files and security
they aren't as cross-platform as they should be anyway..desktop files and security
Another possibility would be to mark known-good .desktop files with an extended attribute. If an attempt was made to launch an unmarked file, a suitably scary dialog would be put up and confirmation required from the user.
.desktop files and security
Plash is showing the only hope for the way forward. Please don't confuse sandboxing (applet can't do anything that the user might regret) with capability access control (applet can't do anything that the user hasn't indicated he wants it to do).sandbox != capability access control
I agree with the first sentiment--thanks, Jon, for pointing out Plash! I think this has better potential to improve security in practice than SELinux. I'm a little confused about your second statement, because I didn't think that sandboxing had such a narrow meaning. I think I even heard Alan Karp describe Polaris (on which Plash seems to be modeled in part) as a sandbox.sandbox != capability access control
Perhaps Alan Karp did use that terminology. Indeed, the first sentence of http://plash.beasts.org says "Plash is a system for sandboxing GNU/Linux programs.".sandbox != capability access control
sandbox != capability access control
Indeed. The idea is to allow dancing pigs, without thereby also allowing theft or destruction of your data, illicit use of your network, etc.sandbox != capability access control
We have plenty of 24/7 production linux workstations at my job and let me say that casual users really only want to click on a easy to understand icon... The extension/security is something that our users really dont want to get involved with... they only want to get their job done..desktop files and security
The ability for a program to present any icon to the user IS definitely a problem;
th0ma7, the problem is that malware can easily ease of use vs. security
create or modify icons. It might not be a
problem for you now, but this is a security
issue worth looking at carefully.
In the end, there are always trade-offs between security and usability... and trying to figure out where you havent just loaded your double barrel shotgun and aimed it at your crotch can be a lot harder for people because humans have myopic vision of wanting to get stuff done. Security Risks and Human Nature
> In the end, there are always trade-offs between security and usability...Security Risks and Human Nature
Why do these files exist at all?.desktop files and security
I think there are obvious reasons why it is desirable to have a standard for files representing desktop icons. The question isn't "why do these files exist", but "why do they have to be written as scripts"?
.desktop files and security
.desktop files *are* simple metadata
.desktop files and security