Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 258936 - Attack vector for Freedesktop compliant systems
Summary: Attack vector for Freedesktop compliant systems
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
URL: http://www.geekzone.co.nz/foobar/6229...
Whiteboard: A2 [upstream+]
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-14 04:23 UTC by Nick Soveiko
Modified: 2016-03-09 12:16 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Soveiko 2009-02-14 04:23:52 UTC
.desktop files for all practical purposes are shell scripts capable of doing anything that the user can do. But they do not have to be marked as executable, and they have complete control over how they are presented on the desktop. A .desktop file can show up as a document or image file, but actually be some sort of hostile script. A user, hoping only to view a file which has shown up on the desktop, may end up running something entirely different.

see
http://lwn.net/Articles/178409/
http://lwn.net/Articles/318755/
http://lwn.net/Articles/319072/
for more info

Reproducible: Sometimes

Steps to Reproduce:
http://www.geekzone.co.nz/foobar/6229




a workaround to privilege escalation can be provided in Gentoo by making ~/.local/share/applications non-writeable to user by default and giving a prominent warning about possible consequences of doing otherwise.

off the top of my head, i can't think of a workaround against compromising a user account itself :(
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2009-02-14 05:05:53 UTC
Making that directory unwritable would pose a serious decrease in usability, and not fully resolve the problem either as the Desktop would still be easiest to compromise. Do you know if this problem is being tracked upstream and whether there are statements by the freedesktop projects?
Comment 2 Nick Soveiko 2009-02-14 08:34:40 UTC
(In reply to comment #1)

> Making that directory unwritable would pose a serious decrease in usability,

it will make default behaviour to deny a user possibility of editing menus and mimetype assignments from GUI. imho, given sane defaults, it's not such a serious decrease in usability as leaving a remotely exploitable security hole gaping open.

> and not fully resolve the problem either as the Desktop would still be easiest
> to compromise.

there are actually two problems here:

1) compromising a single account via malicious .desktop file
2) privilege escalation by creating/overwriting .desktop entries in ~/.local/share/applications

as bad as (1) is, (2) is significantly worse. proposed workaround would eliminate at least that possibility in a default install.

> Do you know if this problem is being tracked upstream and
> whether there are statements by the freedesktop projects?

not that i've did exhaustive research, but a similar bug was filed against KDE back in 2004 (sic!): http://bugs.kde.org/show_bug.cgi?id=73865
it was assigned 'Severity: wishlist' and it looks like nothing was done since then.

a more comprehensive solution (still not perfect, but *a lot* better that the current situation) was proposed in 2006 (comments to http://lwn.net/Articles/178409/) -- make .desktop file proper shell executables starting with #!/usr/bin/desktop-shell
this would require changing freedesktop specs. it will almost close attack vector (1), and as a consequence, never get to stage (2). it also looks like nothing has been done there either.

i sincerely wish i'm mistaken...
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2009-02-14 13:10:12 UTC
(In reply to comment #2)
> there are actually two problems here:
> 
> 1) compromising a single account via malicious .desktop file
> 2) privilege escalation by creating/overwriting .desktop entries in
> ~/.local/share/applications
> 
> as bad as (1) is, (2) is significantly worse. proposed workaround would
> eliminate at least that possibility in a default install.

This is a bogus argument. If an attacker can entice a user to store a provided file at an attacker-chosen path, there are tons of ways to exploit that (e.g., ~/.profile). You cannot protect anyone from any attack if they do not employ a minimal amount of intelligence.
Vulnerabilities are about unexpected behaviour (either active or passive) resulting in crossing of trust boundaries: Active behaviour would be opening a link, or an image file. However, storing an attacker-provided file at a trusted configuration location (your dotfiles and dotdirs) is not behaviour where exploitation is unexpected.

> > Do you know if this problem is being tracked upstream and
> > whether there are statements by the freedesktop projects?
> 
...
> a more comprehensive solution (still not perfect, but *a lot* better that the
> current situation) was proposed in 2006 (comments to
> http://lwn.net/Articles/178409/) -- make .desktop file proper shell executables
> starting with #!/usr/bin/desktop-shell
> this would require changing freedesktop specs. it will almost close attack
> vector (1), and as a consequence, never get to stage (2). it also looks like
> nothing has been done there either.

How would it not close attacker vector (1) completely?
As pointed out above, (2) is not a valid attack vector.
Comment 4 Nick Soveiko 2009-02-14 16:18:43 UTC
(In reply to comment #3)

> > 1) compromising a single account via malicious .desktop file
> > 2) privilege escalation by creating/overwriting .desktop entries in
> > ~/.local/share/applications
> 
> This is a bogus argument. If an attacker can entice a user to store a provided
> file at an attacker-chosen path, there are tons of ways to exploit that (e.g.,
> ~/.profile). You cannot protect anyone from any attack if they do not employ a
> minimal amount of intelligence.

that's exactly is the problem -- the file does NOT have to be stored at any particular attacker-chosen path. it can be stored anywhere, even on a filesystem mounted with noexec! and the file can be easily disguised to be appearing completely innocently looking in a desktop environment. i'd like to think about myself as posessing this minimal amount of intelligence, but this can definitely trick me into trying to open it.

example:
----------------------------- paper.pdf -------------------------------
[Desktop Entry]
Exec[$e]=date > ~/.pwn3d
Icon=pdf
MimeType=
Name=revision 2, please read
Terminal=false
Type=Application
-----------------------------------------------------------------------

tested in kde 3.5.9 on gentoo x86:

1) mailed to myself using mail-client/mutt-1.5.15

2) opened mail via webmail (horde + konqueror). attachment appears as a pdf file, complete with a proper icon, etc (horde is running on a debian server).

3) click on the attachment opens a new konqueror window with the usual 'open', 'save' and 'cancel'. 'open' results in in an empty kpdf window, no warning, no error messages.

4) the next step, which seems logical to me (and with a proper enticing from the attaker, could seem quite logical to almost any user) is to save the file on a local filesystem and try to open it from there. so, click on the attachment again, choose 'save'. my default save location is ~/downloads/, but it doesn't matter.

5) file appears in konqueror file manager as a pdf file, with a proper icon. double click on it.

6) % cat .pwn3d
Sat Feb 14 09:46:21 EST 2009

bingo! we've just enticed user to run an arbitrary code with his own privileges.

> Vulnerabilities are about unexpected behaviour (either active or passive)
> resulting in crossing of trust boundaries: Active behaviour would be opening a
> link, or an image file.

above is an example of unexpected behaviour resulting from active user behaviour. *routine* desktop user behaviour.

> However, storing an attacker-provided file at a trusted
> configuration location (your dotfiles and dotdirs) is not behaviour where
> exploitation is unexpected.

the file wasn't stored at a 'trusted configuration location'.

this is attack vector (1).

now, replace 'date > ~/.pwn3d' with a shell oneliner that downloads a malicious script, installs it (let's say) in /var/tmp/.hidden/ and installs an appropriately disguised .desktop entry containing call to ksudo in ~/.local/applications, and we have attack vector (2).

example of an "appropriately disguised entry":
------------------------------ something.desktop ------------------------
[Desktop Entry]
Type=Application
Exec=kdesu 'bash -c "/bin/date > /etc/.pwn3d;konqueror --profile filemanagement"'
Icon=kfm
Name=File Manager - Super User Mode
X-KDE-SubstituteUID=true
Categories=Qt;KDE;System;X-KDE-More;
-------------------------------------------------------------------------

shows up in kde menu and apparently behaves as a standard entry, but does something completely different.

# cat /etc/.pwn3d
Sat Feb 14 11:15:37 EST 2009

> > > Do you know if this problem is being tracked upstream and
> > > whether there are statements by the freedesktop projects?
> > 
> ...
> > a more comprehensive solution (still not perfect, but *a lot* better that the
> > current situation) was proposed in 2006 (comments to
> > http://lwn.net/Articles/178409/) -- make .desktop file proper shell executables
> > starting with #!/usr/bin/desktop-shell
> > this would require changing freedesktop specs. it will almost close attack
> > vector (1), and as a consequence, never get to stage (2). it also looks like
> > nothing has been done there either.
> 
> How would it not close attacker vector (1) completely?

for example, attack through a zip file, which restores executable bit during extraction. options exist. but for now, let's not dwell on it.

> As pointed out above, (2) is not a valid attack vector.

it appears that it is.
Comment 5 Nick Soveiko 2009-02-14 20:16:45 UTC
(In reply to comment #0)

> a workaround to privilege escalation can be provided in Gentoo by making
> ~/.local/share/applications non-writeable to user by default and giving a
> prominent warning about possible consequences of doing otherwise.

meh. it's even worse: ~/.local/share/applications location can be overriden by $XDG_DATA_HOME (see http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html). on top of that, desktop implementations have their own private locations. e.g. kde puts a bunch of .desktop files under ~/.kde/share/. and making *that* read only will indeed severely reduce usability.
Comment 6 Pierre-Yves Rofes (RETIRED) gentoo-dev 2009-02-26 21:54:31 UTC
While I agree that it's a very annoying and easily exploitable bug, it's not critical severity since it needs user assistance. And we can't do much until freedesktop envs provide a real solution :/
Comment 7 Nick Soveiko 2009-02-26 23:52:09 UTC
(In reply to comment #6)

> While I agree that it's a very annoying and easily exploitable bug, it's not
> critical severity since it needs user assistance. And we can't do much until
> freedesktop envs provide a real solution :/

we can wait for freedesktop to provide for a real solution until cows come home. :-\
a bug to this effect was filed against freedesktop back in 2005:
https://bugs.freedesktop.org/show_bug.cgi?id=2714
"Resolution:   WONTFIX"

the problem surfaced again in 2006 on freedesktop mailing list http://archive.netbsd.se/?ml=xorg-xdg&a=2006-03&t=2724527
it sounds like everybody acknowledged it's indeed a problem, but failed to reach an agreement on how to eliminate it. :-\

however, it looks like a solution exists that can be implemented within gentoo.
desktop apps responsible for bringing files on the desktop from the outside world can be sandboxed in a chrooted jail. a tool was developed for this to be done seamlessly (or at least that's what it claims to do): http://plash.beasts.org/

the problem is that i couldn't find an ebuild for plash, and failed to build manually it against both gentoo glibc or vanilla glibc. either things moved too much since the days when i used to './configure && make && make install', or plash uses an unusually quirky build system.

here's my proposal for a proposal (GLEP) ;) :
- put plash in portage tree
- provide a use flag for potentially unsafe apps (see above + closed source apps with questionable security like googleearth, skype, etc.)
- enable this flag by default in desktop profile and/or write a proper hwo-to and include it with the official gentoo desktop docs

i'm volunteering to help in any way i can. i'm afraid, i'm not much use as a developer, but i can do testing and i'm not half bad technical writer (yes, i can use uppercase when i'm pressed to ;)
Comment 8 Nick Soveiko 2009-02-26 23:55:43 UTC
(In reply to comment #7)
> yes, i can use uppercase when i'm pressed to ;)

and proofreading ;)
Comment 9 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-03-09 12:16:48 UTC
This was fixed in KDE per https://bugs.kde.org/show_bug.cgi?id=73865 .  Tested locally with proper blocks occuring.  No CVE or tracking information.  To many possible test cases and this is ancient.