485294 - disable XSLT in message content

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Marked as security-sensitive for now, because we don't know whether this affects Tb2 and wants to provoke a firedrill for that or not.

In investigating whether or not bug 485217 applied to Thunderbird 2, it became clear that we don't actually know whether it's possible to cause XSLT to execute in message content.  Given that XSLT is Turing-complete, I suspect executing it in message content might be as scary as executing JavaScript in message content.  I'm not totally convinced that's true, because XSLT has a fairly different execution model, but it might be.  I'd be interested to hear thoughts on that from content hackers who know more about XSLT than I.

The most urgent piece of this bug is that we need a set of test messages that attempt to cause XSLT execution in various ways, because if it _is_ possible to do, then it means that Thunderbird 2 is possibly susceptible to (at least) bug 485217 out of the box, and we may want to fire-drill a 2.0.0.x release out the door.

Despite what bug 370345 says, testing shows that Thunderbird 2 does in fact ship with Transformiix enabled, which is why Tb2 might be at risk as well.

So far, most of the testing (done by hand) has been around using an HTML message with an iframe whose source is an XML file on a remote HTTP server.  Those attempts have been blocked by nsMsgContentPolicy::ShouldLoad, but it's not at all clear from looking at the code that the blocking is intentional: the content policy code is simply failing to find an appropriate docshell and aborting.  I'll attach that test message to this bug.  

I believe dveditz and ss also tested using an HTML message with the XSLT in a data: URI and couldn't make it execute that way either; Dan, can you attach that message if you still have it?

I can imagine a number of conceivable vectors for XSLT execution that it would be good to have test cases for.  These include sending an XML message, as well sending HTML mail and putting XML / XSLT in other MIME parts using one of multipart/{related,mixed,parallel,etc).  There may also be other MIME ways to do this, such as if Thunderbird supports message/external-body (which I kinda suspect we don't, but...).

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: iframe with remote content test

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Ludo, it would be very helpful if you could construct a set of test messages as described above.  This feels like it wants to be high priority, because it informs what we do about the immediately upcoming 2.0.0.x release.

Comment 3

[Phil Ringnalda (:philor)]

Content policy must be accidentally catching http://dev.philringnalda.com/xsl/xslcrash.rss subscribed as a feed with "show the summary instead of" unchecked, too. ("An iframe with a remote source? I don't need to do that myself, I can make Thunderbird do it for me!")

Comment 4

[Phil Ringnalda (:philor)]

Err, http://dev.philringnalda.com/xsl/xmlcrash.rss - you'd think after doing that twice subscribing, I'd learn.

Comment 5

[Ludovic Hirlimann [:Usul]]

Attachment: multipart/related

Inline xml file with related transformation

Comment 6

[Peter Van der Beken [:peterv]]

(In reply to comment #0)
> Despite what bug 370345 says, testing shows that Thunderbird 2 does in fact
> ship with Transformiix enabled, which is why Tb2 might be at risk as well.

AFAICT bug 370345 is where XSLT was enabled for Tb2, no?

> So far, most of the testing (done by hand) has been around using an HTML
> message with an iframe whose source is an XML file on a remote HTTP server. 
> Those attempts have been blocked by nsMsgContentPolicy::ShouldLoad, but it's
> not at all clear from looking at the code that the blocking is intentional: the
> content policy code is simply failing to find an appropriate docshell and
> aborting.  I'll attach that test message to this bug. 

You could block XSLT specifically in nsMsgContentPolicy::ShouldLoad by checking for contentType == nsIContentPolicy::TYPE_STYLESHEET and mimeType == "application/xml". Note that this will probably also not allow extensions to load XSLT stylesheets.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

I've just created a secret-mode IRC channel called #bug485294 with a keyword of msgContent for us to coordinate more quickly on this.

Comment 8

[Phil Ringnalda (:philor)]

Attachment: Original PoC as multipart/related

I wasn't quite sure what (if anything) we were doing with Ludovic's multipart/related, so I did the original iframe/xml/xsl as multipart/related.

Not sure how pleased to be that we fail to load it with a "Security Error: Content at mailbox:///.../XSL.eml?number=0&part=1.2&filename=xmlcrash.xml may not load or link to about:blank." - that sounds like another happy accident.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Thanks for the tests, Ludo & Phil.  That, in combination with code analysis (largely made possible by tapping directly into sicking's brain), has convinced us that thanks to another XSLT bug which I will soon file, no versions of Thunderbird will currently execute XSLT in messages.  Ergo, no firedrill necessary.

Rather than depending on various bugs to save us, however, we should indeed make the current behavior explicit by doing the thing suggested by peterv in comment 6 for both 2.0.0.next and comm-central.  dveditz pointed out there are actually several mimetypes we should be blocking for stylesheets, as per <http://mxr.mozilla.org/mozilla/source/content/xml/document/src/nsXMLContentSink.cpp#755>.

Comment 10

[Robert Sayre]

(In reply to comment #9)
> Thanks for the tests, Ludo & Phil.  That, in combination with code analysis
> (largely made possible by tapping directly into sicking's brain), has convinced
> us that thanks to another XSLT bug which I will soon file, no versions of
> Thunderbird will currently execute XSLT in messages.  Ergo, no firedrill
> necessary.

Will Thunderbird execute XSLT in the splash page?

Comment 11

[Phil Ringnalda (:philor)]

"Error loading stylesheet: An XSLT stylesheet load was blocked for security reasons" using either the XML directly or the iframing HTML as a start page, or XML claiming that the stylesheet href is "#goats" with the XSL inline with id="goats" (hey, you never know when we'll support some random thing mentioned on one W3C page...) so I suspect not.

Comment 12

[Peter Van der Beken [:peterv]]

(In reply to comment #9)
> dveditz pointed out there are
> actually several mimetypes we should be blocking for stylesheets, as per
> <http://mxr.mozilla.org/mozilla/source/content/xml/document/src/nsXMLContentSink.cpp#755>.

Nope, we only pass "application/xml" to the content policy, see:

http://hg.mozilla.org/mozilla-central/annotate/9e33f1b0a4dc/content/xslt/src/xslt/txMozillaStylesheetCompiler.cpp#l474
http://hg.mozilla.org/mozilla-central/annotate/9e33f1b0a4dc/content/xslt/src/xslt/txMozillaStylesheetCompiler.cpp#l561
http://hg.mozilla.org/mozilla-central/annotate/9e33f1b0a4dc/content/xslt/src/xslt/txMozillaStylesheetCompiler.cpp#l715

Comment 13

[Peter Van der Beken [:peterv]]

Although that changed between 1.9.0 and trunk, so dveditz is right on the 1.9.0 branch, you'll need to check the three mimetypes there.

Comment 14

[Mark Banner (:standard8)]

Taking for b3 - now we have done the other content policy changes, I think we should be able to fix this quite easily.

Do we want to disable XSLT in just message content or completely? (Completely is slightly easier, but just message content is probably possible as well).

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

I know that the bugmail extension which works with current nightlies uses XSLT.  The ideal case would be just disabling it for message content, but it depends on how much work that would be...

Comment 16

[Daniel Veditz [:dveditz]]

We've established XSLT won't currently run in message content so there's no current vulnerability here, but we do want to make sure it stays that way.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

It would be great to get this for Tb3, but if it were the last bug standing, we wouldn't hold for it.  Marking blocking-, wanted+.

Comment 18

[Magnus Melin [:mkmelin]]

Did some testing of this

- xslt in message content do not work. I think this is because libmime doesn't have a handler for application/xml
- xslt in an iframe works
  ** but JavaScript is still disabled in the generated content

I that is all as expected and in order. Not sure what more to do in this bug. Unless someone adds a handler the current status wouldn't change.

Comment 19

[Magnus Melin [:mkmelin]]

-> WFM