Created attachment 21642 [details] The mailcap file, as it gets delivered with Slackware 12.2 Hello, i've attached the /etc/mailcap, Slackware 12.2 ships, by default, below. Firefox uses mailcap to detect the default application. With the mailcap file, used in Slackware, Firefox uses xdg-open as default application for several "secure" mime types like audio files and PDF files. As xdg-open, itself, detects the "real" mime type (or better asks the desktop manager to detect it) it's possible to execute dangerous files by delivering them with a faked mime-type. I've created a test page to demonstrate the problem (see URL above). Steps to test: - Create a new user for the test (to be sure we are on default settings everywhere and to be secure the demonstration program doesn't kill something ;-)). - Log into a KDE session with this user. - Copy the attached mailcap to $HOME/.mailcap - Start firefox - Visit the above URL (you have to add a security exception, as the certificate belongs to mozdev.org), click the link and just hit "OK" to accept the default, selected by firefox. Result: You'll see a small demonstration program, nested into the .desktop file. I don't know why the Slackware developers got the idea to use xdg-open in mailcap, but you should add a note somewhere into your documentation (maybe the README file in your source) which warns to not use xdg-open too careless, as it may also execute potentially dangerous files. You should also add a note that xdg-open should not be used in mailcap files, as this may cause security problems if applications expect trusted "viewing applications", there (example: Firefox).
Created attachment 21643 [details] [review] Example for a "SECURITY" section in the README file. Just a template, as my english isn't very good. Someone should fix my grammar ;-) Maybe this could also be added to a separate file "SECURITY".
I'm afraid I'm responsible for suggesting this change to Fedora's mailcap file without doing enough homework, and unfortunately it passed others' eyes as well. My sincere apologies. But then again, I think there's something pretty disturbing in this picture, running xdg-utils-1.0.2-5.20081121cvs.fc10.noarch on Fedora 10, with KDE 4.2.1: $ echo -e '#!/bin/sh\necho hello' > foo.sh $ chmod +x foo.sh $ xdg-mime query filetype foo.sh application/x-shellscript $ xdg-mime query default application/x-shellscript kwrite.desktop $ xdg-open foo.sh hello xdg-open is documented to open "a file or URL in the user's preferred application". In the above case it didn't, it caused foo.sh to be executed. And xdg-mime got it wrong as well; my preference order for application/x-shellscript files in KDE file associations is XEmacs, Emacs, then KWrite. If I remove the executable bits from foo.sh, xdg-open opens it with XEmacs, which is expected. xdg-mime still shows application/x-shellscript. FWIW, if I repeat the above otherwise exactly except using foo.png as the filename instead of foo.sh, xdg-open opens it with my configured PNG viewer (gwenview), and xdg-mime says it's image/png and the default is gwenview, no matter whether foo.png is executable or not. My conclusion of the above is that xdg-open has some "internal" security issues as well (it executed the script despite my preferred app settings), at least in my current setup. And xdg-mime appears to be confused too in some scenarios (why did it pick kwrite.desktop despite my app preference order?). Some ideas how to gradually improve things, don't know about feasibility: 1) Fix "xdg-mime query default" or the things it invokes to really return the default app for a file type. Hmm, I don't know if "default" and "preferred" can be used interchangeably here - but in my case it didn't return the "preferred" app. If this is expected behavior, it would be good to have it documented. 2) Make xdg-open use the default/preferred app returned by xdg-mime for opening the file. 3) Add e.g. a --check-mimetype="mime/type" option to xdg-open that first verifies whether the thing opened really looks like the given "mime/type" before proceeding with the open, and if not, display a failure message (possibly in a GUI dialog) or asking confirmation whether to proceed (preferably also displaying what app it is about to use for opening the file). I realize some of these might not really be issues in xdg-{open,mime} per se but the other executables it invokes, but perhaps there's a way to do something about it in xdg-*.
See also https://bugzilla.redhat.com/show_bug.cgi?id=479010, e.g. comment 6.
With kde-4.3 landing, it includes additional restrictions on .desktop file handlind too, which (I believe) covers the original 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?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/27.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.