Security Issue of .desktop files
Daniel Ruoso
Last week, an old security issue in desktop environments went through a
widely public discussion (including on slashdot)[1][2]. As I said, this
issue is not new[3], but there seem to be no action on the upstream to
fix it.
After taking an extensive look in all the history of this discussion,
I've oppened a new bug report in nautilus upstream[4], in addition to
the two bug reports that were already openned in Debian[5][6].
As I made myself very clear in the bug reports, I don't think there is
any good excuse to execute '.desktop' files without them having the x
bit set. For those who didn't follow the discussion, this can make a
fishing attack very much easy in both Gnome and KDE, since iceweasel
downloads files directly to the user Desktop.
The only really sane solution is behave like any *nix like Operating
System and consider .desktop files to be executables, and thus require
the x bit to execute them. Since .desktop is really the desktop variant
for a .sh.
In order to do that, a few other things would be required:
1) An "interpreter" for .desktop files, that can be used in the shbang
of that files. [This is already done, look below]
2) Modify the packages providing .desktop files in order to both add
the shbang and deploy the files with the x bit set. [This is the next
step]
3) Modify nautilus so that .desktop files are not handled specially.
They would be executed if they were executables or be shown in some way
(properties dialog) if not.
4) Modify nautilus DnD code so that permissions should be preserved
when dragging local .desktop files in mount points listed in /etc/fstab
and owned by root or the user himself. Otherwise, umask must be
enforced, meaning "strict by default, relax where needed".
5) Provide a "one-shot" migration process at the first time the user
runs the new nautilus, so the user can review any file owned by himself
in his Desktop or menu. This would only happen once, so this wouldn't
become a "standard procedure" to the user.
6) Do the same in KDE and other Desktop Environments that
interpret .desktop files.
As I consider this issue to be very much important, I already took the
time to work item 1[7]. The xdg-utils package already contains the
"xdg-launch" utility in its git repo and should be uploaded soon, which
leads us to the step 2, and once that is completed all the other items
can happen, but item 2 is a blocker for everything else.
I considered mass-filling bugs about this issue, and maybe I will at
some point, but for start, I thought it would be nice to get this issue
discussed here.
P.S.: It has been used as an excuse the fact that extracting an archive
file could result in .desktop files with the +x bit in the user home
directory. I think that is a separated issue, and have filed a bug in
file-roller upstream to make "preserve permissions" off by default.[8]
daniel
[1] http://www.geekzone.co.nz/foobar/6229
[2] http://www.geekzone.co.nz/foobar/6236
[3] http://lwn.net/Articles/178409/
[4] http://bugzilla.gnome.org/show_bug.cgi?id=572203
[5] http://bugs.debian.org/515104
[6] http://bugs.debian.org/515106
[7] http://bugs.debian.org/516352
[8] http://bugzilla.gnome.org/show_bug.cgi?id=572318
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
> Last week, an old security issue in desktop environments went through a
> widely public discussion (including on slashdot)[1][2]. As I said, this
> issue is not new[3], but there seem to be no action on the upstream to
> fix it.
On the contrary, there is action upstream to fix it, and Nautilus 2.26
will only launch “safe” .desktop files.
Once it is ready, I’ll have a look whether it is possible to backport
the changes to lenny, but it will probably be non-trivial.
--
.''`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`- me that if you don't install Lenny, he'd melt your brain.
Daniel Ruoso
> Le mardi 24 février 2009 à 15:21 -0300, Daniel Ruoso a écrit :
> > Last week, an old security issue in desktop environments went through a
> > widely public discussion (including on slashdot)[1][2]. As I said, this
> > issue is not new[3], but there seem to be no action on the upstream to
> > fix it.
> On the contrary, there is action upstream to fix it, and Nautilus 2.26
> will only launch “safe” .desktop files.
and what are "safe" .desktop files?
daniel
Yves-Alexis Perez
> Last week, an old security issue in desktop environments went through a
> widely public discussion (including on slashdot)[1][2]. As I said, this
> issue is not new[3], but there seem to be no action on the upstream to
> fix it.
In Xfce this discussion arised at some time, and Thunar/xfdesktop will
refuse to run “unsafe” .desktop files and present them with the mimetype
x-thunar/suspected-malware.
For the record, this as already been said, for example on
http://article.gmane.org/gmane.comp.freedesktop.xdg/8199
Cheers,
--
Yves-Alexis
Daniel Ruoso
> On mar, 2009-02-24 at 15:21 -0300, Daniel Ruoso wrote:
> > Last week, an old security issue in desktop environments went through a
> > widely public discussion (including on slashdot)[1][2]. As I said, this
> > issue is not new[3], but there seem to be no action on the upstream to
> > fix it.
> In Xfce this discussion arised at some time, and Thunar/xfdesktop will
> refuse to run “unsafe” .desktop files and present them with the mimetype
> x-thunar/suspected-malware.
I'm sorry, but that only address one half of the problem, which nautilus
in Debian also address. But it doesn't prevent desktop files that look
just right to be invoked directly after they are downloaded from a web
browser.
The issue here is about recognizing that .desktop files are executables,
and, as such, must have the x bit set in order to be executed. Consider
the user downloading a file from iceweasel, that sends it directly to
the Desktop. In a single step, the file is available with whatever
appearence it desires to and being able to execute whatever it wants to.
daniel
Yves-Alexis Perez
> The issue here is about recognizing that .desktop files are executables,
> and, as such, must have the x bit set in order to be executed.
Depending who executes its. On Xfce, a suspected malicious file won't be
executed.
> Consider
> the user downloading a file from iceweasel, that sends it directly to
> the Desktop. In a single step, the file is available with whatever
> appearence it desires to and being able to execute whatever it wants to.
By who? The Browser? Fix the browser?
Cheers,
--
Yves-Alexis
Emilio Pozuelo Monfort
> Em Ter, 2009-02-24 às 19:35 +0100, Josselin Mouette escreveu:
>> Le mardi 24 février 2009 à 15:21 -0300, Daniel Ruoso a écrit :
>>> Last week, an old security issue in desktop environments went through a
>>> widely public discussion (including on slashdot)[1][2]. As I said, this
>>> issue is not new[3], but there seem to be no action on the upstream to
>>> fix it.
>> On the contrary, there is action upstream to fix it, and Nautilus 2.26
>> will only launch “safe” .desktop files.
>
> and what are "safe" .desktop files?
See this mail and its followups:
http://mail.gnome.org/archives/desktop-devel-list/2009-February/msg00132.html
Cheers,
Emilio
Daniel Ruoso
I'm glad to see that, it's a shame I haven't found that thread. So, for
the record, *nautilus* is solving the .desktop files issue by:
1) Special casing files that are system-wide installed.
2) Requiring .desktop files to have the x bit set otherwise.
I'm pretty happy with that solution (although I would prefer not having
the "launch anyway"/"mark as trusted" box, but rather simply show the
properties dialog for a non-executable-non-system-wide .desktop file
(but I think that should go as an suggestion to upstream)).
I also would suggest that as a migration plan only, where we do turn
all .desktop files into executables in the future, so we have a
consistent environment.
Also, as "mark as trusted" is making the file executable, are you
planning to add a shbang to it?
Daniel Ruoso
> By who? The Browser? Fix the browser?
Please take a look at all the discussion in the bug reports, I don't
think we need to repeat all the argumentation here.
Josselin Mouette
> I'm pretty happy with that solution (although I would prefer not having
> the "launch anyway"/"mark as trusted" box, but rather simply show the
> properties dialog for a non-executable-non-system-wide .desktop file
> (but I think that should go as an suggestion to upstream)).
How about discussing this with upstream instead of here? I already told
them that allowing to launch it anyway is a bad idea.
> I also would suggest that as a migration plan only, where we do turn
> all .desktop files into executables in the future, so we have a
> consistent environment.
What is the purpose of having system .desktop files executable?
> Also, as "mark as trusted" is making the file executable, are you
> planning to add a shbang to it?
No.
Daniel Ruoso
> > I also would suggest that as a migration plan only, where we do turn
> > all .desktop files into executables in the future, so we have a
> > consistent environment.
> What is the purpose of having system .desktop files executable?
Allowing that in the future no special handling is needed for that, just
a single rule: "Is it an executable? execute!". No special handling for
launching .desktop files ...
Michael S. Gilbert
> > By who? The Browser? Fix the browser?
>
> Please take a look at all the discussion in the bug reports, I don't
> think we need to repeat all the argumentation here.
I think Yves is saying that the launcher issue is (and always was)
correctly handled in the XFCE desktop. This is a GNOME/KDE-specific
problem. If the browser (iceweasel, epiphany, etc) handles the
launchers via its own means, then there still may be a problem, but
that would certainly not be the fault of the desktop environment.
If there are indeed vectors for attacks via browsers, then bugs should
certainly be reported against their BTS's. But first, please determine
whether the vector exists.
Best wishes,
Mike
Daniel Ruoso
> I think Yves is saying that the launcher issue is (and always was)
> correctly handled in the XFCE desktop. This is a GNOME/KDE-specific
> problem.
So if a .desktop file appears in the user's Desktop without the x bit
set and the user clicks it, it won't get executed...
daniel
Yves-Alexis Perez
> So if a .desktop file appears in the user's Desktop without the x bit
> set and the user clicks it, it won't get executed..
Not exactly. The “safe” .desktop file was in the link I pasted on
another mail in the thread:
/* check if the file tries to look like a regular document (i.e.
* a display name of 'file.png'), maybe a virus or other malware.
*/
fake_mime_info = thunar_vfs_mime_database_get_info_for_name (_thunar_vfs_mime_database, str);
if (fake_mime_info != _thunar_vfs_mime_application_octet_stream && fake_mime_info != info->mime_info)
{
/* release the previous mime info */
thunar_vfs_mime_info_unref (info->mime_info);
/* set the MIME type of the file to 'x-thunar/suspected-malware' to indicate that
* it's not safe to trust the file content and execute it or otherwise operate on it.
*/
info->mime_info = thunar_vfs_mime_database_get_info (_thunar_vfs_mime_database, "x-thunar/suspected-malware");
/* reset the executable flag */
info->flags &= ~THUNAR_VFS_FILE_FLAGS_EXECUTABLE;
/* reset the custom icon */
g_free (info->custom_icon);
info->custom_icon = NULL;
/* reset the name str, so we display the real file name */
name = NULL;
}
Basically, when the .desktop tries to trick the user, it won't be
executed.
Cheers,
--
Yves-Alexis
Daniel Ruoso
> On mar, 2009-02-24 at 18:35 -0300, Daniel Ruoso wrote:
> > So if a .desktop file appears in the user's Desktop without the x bit
> > set and the user clicks it, it won't get executed..
> Not exactly. The “safe” .desktop file was in the link I pasted on
> another mail in the thread:
So if the launcher use a plain name like "Nude Shots", it will get
executed?
Armin Berres
> Em Ter, 2009-02-24 às 20:49 +0100, Emilio Pozuelo Monfort escreveu:
> > Daniel Ruoso wrote:
> > > Em Ter, 2009-02-24 às 19:35 +0100, Josselin Mouette escreveu:
> > >> Le mardi 24 février 2009 à 15:21 -0300, Daniel Ruoso a écrit :
> > >>> Last week, an old security issue in desktop environments went through a
> > >>> widely public discussion (including on slashdot)[1][2]. As I said, this
> > >>> issue is not new[3], but there seem to be no action on the upstream to
> > >>> fix it.
> > >> On the contrary, there is action upstream to fix it, and Nautilus 2.26
> > >> will only launch “safe” .desktop files.
> > > and what are "safe" .desktop files?
> > See this mail and its followups:
> > http://mail.gnome.org/archives/desktop-devel-list/2009-February/msg00132.html
>
> I'm glad to see that, it's a shame I haven't found that thread. So, for
> the record, *nautilus* is solving the .desktop files issue by:
>
> 1) Special casing files that are system-wide installed.
> 2) Requiring .desktop files to have the x bit set otherwise.
>
> I'm pretty happy with that solution (although I would prefer not having
> the "launch anyway"/"mark as trusted" box, but rather simply show the
> properties dialog for a non-executable-non-system-wide .desktop file
> (but I think that should go as an suggestion to upstream)).
FWIW the same has been implemented in KDE. There are some recent threads
in kde-core-devel if you are interested in further information.
Greetings,
Armin
Yves-Alexis Perez
>
> So if the launcher use a plain name like "Nude Shots", it will get
> executed?
Please provide what you think is a bad .desktop and I'll let you know.
Or you can try it yourself.
Cheers,
--
Yves-Alexis
Michael S. Gilbert
> > > So if a .desktop file appears in the user's Desktop without the x bit
> > > set and the user clicks it, it won't get executed..
> > Not exactly. The “safe” .desktop file was in the link I pasted on
> > another mail in the thread:
>
> So if the launcher use a plain name like "Nude Shots", it will get
> executed?
I think I need to retract my previous statement. It looks like the XFCE
desktop itself is fairly safe (since it never actually
executes .desktop files), but thunar isn't. For example, here is
a .desktop file that looks like it is iceweasel, but really it
downloads an essentially random file, but I could have made it do
pretty much anything.
<filename: random.desktop>
[Desktop Entry]
Version=1.0
Name=Iceweasel
Exec=wget http://people.debian.org/~joeyh/d-i/images/daily/stats.txt
Icon=/usr/share/pixmaps/iceweasel.png
The user is not warned that this may be malicious, it has the
iceweasel icon and name, and runs without prompt when clicked on in
thunar.
Mike
Yves-Alexis Perez
> here is
> a .desktop file that looks like it is iceweasel, but really it
> downloads an essentially random file, but I could have made it do
> pretty much anything.
Yes, tests may need to be narrowed. That should be part of the spec,
though.
Cheers,
--
Yves-Alexis
Michael S. Gilbert
> > here is
> > a .desktop file that looks like it is iceweasel, but really it
> > downloads an essentially random file, but I could have made it do
> > pretty much anything.
>
> Yes, tests may need to be narrowed. That should be part of the spec,
> though.
It seems like it will error-prone, troublesome, and a lot of work to
come up with enough robust test cases that can prevent all potential
attack vectors (especially if its on a deny per-application basis).
Does it even make sense for anyone to be spending time on this?
Ultimately there are going to be holes, and thats where attackers will
get through; they have a lot more time to mess around and think
about this stuff than most of us.
Requiring '+x' has got to be the best, easiest, most straightforward,
and most robust solution on the table. In order for a malicious
launcher file to work, users will have to be smart enough to be able to
use chmod, and if that's the case then they'll know something
suspicious is going if someone tells them to do it. Chmod is required
because, for example, thunar does not allow the user to modify the
executable bit and I hope nautils/dolphin behave the same)
It's going to take some effort to get this solution implemented, but
its the right thing to do, and Debian should plan to proceed forward
with that.
Regards,
Matthew Johnson
Speaking as someone with a PhD in computer security (and my PhD was in
this area) I can tell you that trying to use heuristics in order to
determine if something is 'bad' does not, and it's fairly widely
recognised cannot, work.
You are ipso facto providing an oracle to the attacker and he will craft
something that looks sufficiently plausible, passes the checks, but is
malicious.
I firmly agree with Michael that the only good solution is to require
explicit marking or .desktop files in some fashion. Owned by root is
probably fine (since you've basically already lost if that's the case)
as is setting the execute bit (but things should be cautious as always
about setting it)
Matt
--
Dr Matthew Johnson
Yves-Alexis Perez
> Speaking as someone with a PhD in computer security (and my PhD was in
> this area) I can tell you that trying to use heuristics in order to
> determine if something is 'bad' does not, and it's fairly widely
> recognised cannot, work.
Well, it depends. I'm not opposed to security (all the contrary, in
fact), but it's clearly a tradeoff and at some point it becames useless.
>
> You are ipso facto providing an oracle to the attacker and he will
> craft
> something that looks sufficiently plausible, passes the checks, but is
> malicious.
>
> I firmly agree with Michael that the only good solution is to require
> explicit marking or .desktop files in some fashion. Owned by root is
> probably fine (since you've basically already lost if that's the case)
> as is setting the execute bit (but things should be cautious as always
> about setting it)
Maybe that's what the test should be supposed to do. What I say is that
it should be part of the spec. One DE or distro shouldn't do its own
stuff privately or it'll fail.
Cheers,
--
Yves-Alexis
Josselin Mouette
> Not exactly. The “safe” .desktop file was in the link I pasted on
> another mail in the thread:
>
> /* check if the file tries to look like a regular document (i.e.
> * a display name of 'file.png'), maybe a virus or other malware.
> */
> Basically, when the .desktop tries to trick the user, it won't be
> executed.
So this amounts to approximately the same level as the patched nautilus
currently in Debian. However this is insufficient, since it is easy to
trick the user into launching a “safe” .desktop file which is actually
malware.
Harald Braumann
Matthew Johnson <mj...@debian.org> wrote:
> On Tue Feb 24 23:44, Yves-Alexis Perez wrote:
> > On mar, 2009-02-24 at 17:33 -0500, Michael S. Gilbert wrote:
> > > here is
> > > a .desktop file that looks like it is iceweasel, but really it
> > > downloads an essentially random file, but I could have made it do
> > > pretty much anything.
> >
> > Yes, tests may need to be narrowed. That should be part of the spec,
> > though.
>
> Speaking as someone with a PhD in computer security (and my PhD was in
> this area) I can tell you that trying to use heuristics in order to
> determine if something is 'bad' does not, and it's fairly widely
> recognised cannot, work.
Not only widely recognised, it's proven. People with or without a PhD
might look up the halting problem.
> I firmly agree with Michael that the only good solution is to require
> explicit marking or .desktop files in some fashion.
Isn't downloading something, putting it on the desktop and clicking on
it a strong enough indication of the user's will to execute whatever it
is? If he does all this without blinking once, he surely wouldn't have
any concerns about setting the x bit, if that gets him what he wants,
i.e. to execute the file.
As long as most people think, that embedded scripts, programmes
opening all sorts of crap automatically and .dektop files are
really a great idea, trouble won't be amiss, no matter how many warning
pop-ups, checks or blocks you put in front. I fear the day, when I can
download soft links and disguise shell scripts as pictures.
Cheers,
harry