One of the slackware developers approached me about a security issue that was reported in their mailcap. They did so because they copied our mailcap. Here is the original ticket they received: https://bugs.freedesktop.org/show_bug.cgi?id=19377 I have not personally explored this bug - just acting as a relay - the slackware contact is Robbie Workman - I have cced him on this ticket, but for the record his email address is: rworkman I am adding some additional discussion from within the slackware community: 14:19 <rworkman> Hey :) 14:20 <ke4qqq> what can I do for you? 14:20 <rworkman> What do you make of this: https://bugs.freedesktop.org/show_bug.cgi?id=19377 14:20 <rworkman> You guys have the exact same /etc/mailcap -- we "borrowed" it from you :) 14:21 <ke4qqq> that is supposed to be the idea. 14:21 <rworkman> Unofficially, we think it's a load of crap. There's no way to prevent users from doing somethign stupid. 14:23 <ke4qqq> interesting - so you want me to report this upstream to Fedora? 14:23 <rworkman> Well, I guess so. I'd like to see what the relevant maintainer's take on this is before we do anything. 14:24 <rworkman> If you don't mind, please CC me <rworkman> on it if you mail it 14:24 <ke4qqq> ok, I'll do so shortly 14:24 <rworkman> Thanks 14:28 <rworkman> Just some discussion we're having: 14:28 <rworkman> 19:27 < volkerdi> rworkman: Possibly someone else maintains the Fedora mailcap package (yes, they have a whole RPM for just the mailcap). Maybe they ought to be in the loop, too. 14:28 <rworkman> 19:28 < amrit> so basically if the server specifies, say, a jpg mime type for a .sh, xdg-open will execute it anyway? 14:28 <rworkman> 19:28 < alienBOB> The problem with xdg-open is in fact not xdg-open itself. It passes the URL to a DE-specific tool, for KDE that is kfmclient. IMO kfmclient should not accept .desktop files if they are not located on the local fs 14:33 <ke4qqq> sorry - /me is a bit distracted - in two meetings at once....I'll be back to this shortly. 14:33 <rworkman> No problem - it's not urgent IMO :)
*** 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.