Thursday, December 18, 2008

Opera, SVGs and Java applets

Opera 9.63 was just released with some security fixes. I reported one of these issues, but neither myself nor Tarquin (a super friendly and knowledgeable Opera security guy) could do anything significant with it, despite feeling uneasy about the feature.

The issue is this: when an SVG image is included via an <img> tag, it is standard practice to disable running of JavaScript in that context. However, I noted that you could run a Java applet (and Flash presumably) in this context via the SVG tags such as <html:applet>.

A demo is here:

Every attack we came up with is catered for. We discussed some very in-depth attacks (which I don't want to go into just yet) but Opera has some nice tweaks such as respecting Content-Disposition: attachment for SVG images referred to via the <img> tag. The Opera guys even checked that the unusual context of executing due to an <img> tag gets the domain correct (that of the img resource, not the hosting page). By the time I inquired about this, they had already checked.

I continue to be impressed with Opera; the bug was fixed lightning fast even though no severe impact is known. And a few little Opera defensive measures turned out useful. This follows on from Opera being immune to my image theft via SVG attack.

Not many browsers support this advanced feature. Aside from Opera, both Safari and Chrome support this. But they do not render Java applets in SVGs in the <img> tag context.

If you can think of a scenario where these embedded applets could cause more trouble that I've realized, please leave a comment or mail me :)

Wednesday, December 17, 2008

Firefox cross-domain text theft....

... and a reappearance of the "302 redirect trick".

Here's the second bug from my PacSec presentation, and it's another Firefox one; kudos to the Firefox security team for their responsiveness. It's fixed in the recent and 3.0.5 releases.

It involves, yes, a cross-domain <script src="blah"> tag. These remain a horrible wart in web app security; you have to make sure that any authenticated resource on your domain either does not have any side effects when parsed / executed as JavaScript, or is CSRF protected.

This particular bug involves Firefox's window.onerror handler, which reports on JavaScript parse and execution errors. This handler has previously been used by Jeremiah Grossman to determine login status via script errors, see here! (Whereas this hole can be closed, it's not clear my similar attack via CSS can be).

The new attack notes that certain JavaScript error messages leak real content from remote domains, for certain constructs of data. More in-depth technical detail is here:

One cute twist is that Firefox 3 already had this fixed (thanks to Filipe Almeida; see credit below), but the "302 redirect trick" bypassed that fix. This trick is becoming quite fruitful; see previous Firefox image theft bug.

Credit to Filipe Almeida for being awesome. He was playing with this stuff long before anyone else.