Hello,

Slackware 12.2 comes with a /etc/mailcap file, which forwards some mime-types to xdg-open.

The /etc/mailcap file is used by Firefox and other Mozilla-based software, to detect the default application, for viewing this kind of file.

xdg-open is made to detect the default viewing application, based on the settings in the window manager.

By spoofing the mime-type of a "dangerous" file, this makes it easy for an attacker to get this file executed. Firefox gets told by the webserver, that a PDF file has to be viewed and offers to open it with xdg-open. If the user clicks "OK" (and many users won't have a closer look at the filename of the document!), then xdg-open now detects the real content-type and executes the .desktop file.

It would be even possible to deliver and open a "real" PDF file in a second stage, so the user never knows that he got fooled.

I've written a demonstration page for the case "application/pdf used for .desktop file". Other combinations would be possible!

http://prefbar.mozdev.org/testxdgopen.html

Recommended workaround: Delete /etc/mailcap and get sure it stays deleted. It gets recreated with any reinstall or update of the xdg-utils package, so maybe it would be a good idea to uninstall this package!

For people, which have their own custom mailcap file: Have a look at your /etc/mailcap file! The xdg-utils package adds the probably dangerous items without telling the user about the change!

I already sent a short mail to security(at)slackware.com, three days ago, in hope this will be fixed.

I would rather recommend not installing xdg-utils.
The mailcap file is far more important than it.

The mailcap file is created by the xdg-utils package, in slackware 12.2, and it only contains the items, pointing some types to xdg-open. If someone has a self-created mailcap file, then he should have a look at it, after updating to Slackware 12.2! The xdg-utils package adds the probably dangerous items to this file, without telling the user about this change. Those people, who never touched "/etc/mailcap", may delete it or move it to mailcap.off.

Thanks for the heads-up Mreimer. Today was the first time I'd ever looked at the xdg-utils stuff after being curious about statguy's Thunderbird topic. My gut reaction was to dislike the entire xdg/mime setup completely, but I hadn't considered the security implications. I think I'll just yank the whole thing out of my box, see what it breaks and take it from there.

Oh that would explain why i aint got one. Thanks.

Is this the same year old vulnerability that applies to xfg-utils-1.0.2-r1?

http://seclists.org/fulldisclosure/2008/Jan/0591.html

Slackware 12.2 uses xdg-utils-1.0.2 which appears to be a later release.

And anyone still thinks Manuel Reimer has a love for Slackware? If you find out a potential vulnerability you mention this to the party responsible for fixing it (in this case Pat V. of Slackware, Inc.) and make sure the hole gets patched before running around yelling "FIRE FIRE". See this external bug tracker, ##slackware IRC channel and now on this public forum. Full disclosure is the disgrace of the person revealing the issue without giving the distro or the software developer a chance to do something about it.

Eric

I think so, others may have a different opinion.

I'm no professional security researcher! So far, I only read advisories, but didn't know how they are created.

The first thing of all, I did, was to mail Patrick, but I also wanted to tell the freedesktop.org-Team about the hole, as I was unsure how many distributions really use xdg-open in their mailcap file. I hoped they could publish a security advisory and so to inform all relevant distributions. That was the reason for the bug report.

It definetly was a bad idea to post to this forum. The post resulted from the fact, that freedesktop.org publishes bugs, even when marked with "security". And so the exploit was out in the wild. So my next thought was: Try to tell as much users as possible about the issue, so they can fix their systems. Yes, a silly idea.

I vote for immediately deleting this topic as soon as possible. I already mailed the forum webmaster, but if someone else is able to lock this thread, please do so.

Nobody should delete anything. I object to deleting relevant information.

I'm still grateful to Manuel for making me aware of the issue. Whatever your opinion of the pros and cons of full disclosure, the simple fact is that my system is now secure thanks to Manuel making me aware of the problem, allowing me to take remedial steps until an official update comes out.

Now, if there was no way to mitigate the issue, then that would be an entirely different thing and needs to be handled more carefully.

Reading Manuel's original post, he did say that he reported the problem to security@slackware.com three days ago. If the team wished him to keep it quiet in order to give them time to work on it, it would appear that they've had a couple of days in which to ask him to do so. It really doesn't seem fair to portray him as the devil here. Looks more like a failure to communicate than anything else.

That might be true except for the fact that I'm not sure he even gave Pat and the Slackware Security Team 24 hours between Saturday and Sunday to respond before going public.

If, as you say, he reported it three days ago, that would have been Saturday, January 3. It seems Manuel posted about this issue on a.o.l.s[1] and in some random forum[2] on Sunday, January 4.

Not even giving Pat and the Slackware Security Team 24 hours to respond, much less over a weekend, before publicly posting all over the internet seems to be jumping the gun a bit.



[1] http://groups.google.com/group/alt.o...76d36498e88a6#

[2] http://www.jlaforums.com/viewtopic.php?t=6396497

I still have mixed feelings on the issue of disclosure, I can see both sides of the argument, but yes, if he didn't give the team a chance to respond at all then that's different.

You might want to get an idea from ye aulde RFP Labs Full Disclosure Policy (RFPolicy) v2.0?


No it isn't. Apart from debatable timing issues anyone disagreeing could do worse than zazen with Schneier's Full Disclosure of Security Vulnerabilities a 'Damned Good Idea': "I much prefer a world where I have all the information I need to assess and protect my own security." Full Disclosure just requires following a guideline. All it means is you promise to tell everybody (no exceptions) everything (no exceptions) for the benefit of all (no exceptions). But it's a guideline. So it's all voluntary.


Unless content adversely affects the good LQ atmosphere or violates the LQ Rules I see no reason to close this thread.

Thanks for the notice about this. It really isn't smart to have xdg-open used in a mailcap file. It doesn't just affect mozilla apps; It affects double clicking on files in file managers (such as dolphin) as well. You don't need to remove /etc/mailcap, however; Just comment out or delete the xdg-open entries.

Granted, I think it is foolish to assume that a file is a what file extension says it is (if there is one). Even if it is a .gif file, it could have a zip file or mp3 embedded in it and so on. But at least if your mailcap file specifies a good app for a mime type, then that app can just crash and burn when it discovers that the file you are trying to load isn't really what it extension says it is. Of course, depending on how it crashes you could have another security hole (specific to the application). The important thing for people to do is to first have some good sense on who/where they download files from and how they check if they are good. Overall layered System security is always a must as well.

Perhaps a good approach for Slackware would be to ship good mailcap file with everything commented out. What I mean by "good mailcap file" is to include mimetype handlers for most common extensions with programs to handle them that are included in Slackware. The admin can then just uncomment the ones they like/change them. This would probably be easier for people than creating the file from a blank slate, yet it still keeps Slackware "vanilla" fresh from the install.