Bug 479010 (CVE-2009-0068)

*** Bug 479057 has been marked as a duplicate of this bug. ***

I am not sure about this, but it could be seen in 2 different ways

1 the server said a mime type, the browser should open it as this mimetype
2 the real document is a given mime type the application opening it should be the application corresponding with that mimetype.

Both have different security implications. 1 means that if failed the browser may fail to stop the content from being executed. 2 means that the content will be feed to the wrong application.

Maybe the right solution would be to have the brower detect the file type (for example using 
xdg-mime query filetype $file
and aborts if it is not the same than what the site said.

Something along 

image/*; /usr/bin/verify-and-open %F %s

and verify-and-open would first call  xdg-mime query filetype and verify that it matches what %F said.

My apologies for suggesting this change to Fedora's mailcap without realizing
this issue, and too bad others didn't catch it either.  See my comments in the
upstream bug; I think there are other issues besides mailcap and firefox in
xdg-open use at least in KDE setups.

Also this issue may be more widespread than in firefox, since xdg-open is used as a viewer for some types of documents. The xdg-open option you propose should be right, though.

It looks like only the kde method in xdg-open is actually executing the file, the gnome, xfce and generic methods open it in an editor, but I'm not sure if this is always the case. I'd prefer to keep xdg-open in mailcap if possible and fix it in xdg-open and/or kfmclient.

Changing the "kfmclient exec" call in xdg-open to "kfmclient openURL" seems to help, a dialog asking before execution pops up. Is that good enough?

kfmclient exec is bogus for kde4 anyway (doesn't work).

kfmclient openURL 'url' ['mimetype'] is the way to go (esp if able to provide the optional mimetype arg).

I can work to fix that part in xdg-open asap.

xdg-utils:
%changelog
* Wed Apr 08 2009 Rex Dieter <rdieter> - 1.0.2-7.20081121cvs
- xdg-open: s/kfmclient exec/kfmclient openURL/ (CVE-2009-0068, rh#472010, fdo#19377)

There are more in-depth measures to take, but this is a good first try anyway.

I suppose that's better yes, but I don't know what you meant by kfmclient exec not working in kde4 - it does work for the use cases I've tried.

kfmclient openURL is probably an improvement, but it has (non-security) issues as well, but then again these are pretty much off topic for this bug:

- running it on a *non*-executable shell script prompts a "do you really want to execute [...]" dialog, and when I click yes, it doesn't actually execute the script but opens up an empty konqueror window _and_ XEmacs containing the script for me.

- It doesn't in most cases appear to honor my file associations or embedded/separate viewer settings but tries to open everything in konqueror using an embedded editor/viewer and only sometimes opens a separate program (in addition to konqueror)

ok, not sure what I was smokin yesterday, but openURL certainly isn't an improvement, agreed.  ugh.

Assuming we want to keep xdg-open in mailcap, reassigning to xdg-utils.

As I mentioned upstream,

With kde-4.3 landing, it includes additional restrictions on .desktop file handlind too, which (I believe) covers the original (upstream) report case.

For comment #2 , take away the chmod +x, and it opens using a text editor (the same behavior as if one clicked it in kde filebrowser).

Are there other cases not yet considered?

closing->errata (as in fixed in kde-4.3).  
feel free to re-open if other unresolved cases can be found.