.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 :(
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?
(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...
(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.
(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.
(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.
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 :/
(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 ;)
(In reply to comment #7) > yes, i can use uppercase when i'm pressed to ;) and proofreading ;)
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.
