1043787 - (CVE-2014-1589) Chrome level XBL bindings can be triggered from content

Status: VERIFIED FIXED

(Core :: XBL, defect)

Description

[Cody Crews]

Attachment: loadChromeBindings-testcase-new.html

To see this work and begin to understand this issue, when viewing the testcase press the print button.  This could have been very serious if most everything involving anonymous content wasn't already undergoing massive change that we're just fortunate enough to be seeing in the most recent release.

I marked this major, please feel free to correct me if I'm wrong on that, but I don't think I am.  This shouldn't be confused with a previous bug of mine about triggering chrome level bindings because this requires no access to any anonymous content, and is simply due to the complexity of the mozilla source code base.  I could have filed this almost 2 weeks ago, but after testing in the newer nightly builds I could see that a lot of the real danger here is already being mitigated thanks to all the previous XBL torture.  The base issue is actually very simple, There's chrome accessible css sheets that are perfectly fine to be included in content as long as people were always careful to make sure that they declared the XUL namespace as the primary namespace in them, which hasn't been entirely consistent.  Before the most recent update these xul elements were completely accessible from content and that was really worrisome to me.  In the current release and up and it's much safer IMO.  What is happening here is because of the lack of the namespace definition in these files its possible to load include them and use generic elements with the right tag name and class/id definitions to trigger chrome level bindings in content.  I've clearly shown here that its still very possible to manipulate XBL through the WindowProperties Object.  By naming a window that is the window of a sub-document, XBL code in this instance can find the "PrintUtils" object that its looking for because the sandbox that XBL code executes in currently inherits the window that contains the bindings as a prototype.  Clearly it's very lucky that this lines up and that the window has a print function and there's no danger with that at all, but I haven't felt very eager to dig through all the XBL code to look for places where this could be much more serious.  I'm already up way too late for tonight and very tired so Ill leave it at that, just look over the testcase carefully.  Now for tomorrow, I've saved CSRF that's very easy to do and could easily lead to full blown XSS, so until then!

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

cody: so each team uses the "importance" section differently, your likely looking to say this should be sec-high or sec-critical (keywords that the security group uses to classify security bugs). So for now I've set the importance back to default.

Comment 2

[Cody Crews]

Thanks, I understand what you mean.  Priority should definitely be elsewhere for now seeing as this is mostly crippled compared to how bad it could have been.  I was glad to see that apparently the fix part for here is already mostly in place, and with the namespaces not being declared I could probably even have the patch ready for that so yeah I wasn't thinking about it like that last night.  I probably shouldn't have put this together as tired as I was last night, but it was kind starting to feel like a now or never type situation(I'm just tired of XBL.)

Comment 3

[Andrew McCreight [:mccr8]]

Bobby, could you look at this or suggest somebody else to look at it?  Thanks.

Comment 4

[Bobby Holley (:bholley)]

It is on my list.

Comment 5

[Bobby Holley (:bholley)]

Flagging sec-moderate until we have a more dire testcase. Regardless though, I think we should nip this issue in the bud. I've filed bug 1050049, which I think we can do in the open.

Comment 6

[Bobby Holley (:bholley)]

This was fixed by bug 1050049. \o/

Comment 7

[Al Billings [:abillings - ex-MoCo]]

How far back did this issue go?

Comment 8

[Bobby Holley (:bholley)]

(In reply to Al Billings [:abillings] from comment #7)
> How far back did this issue go?

Far.

Comment 9

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed in Fx33, fixed in Fx34 2014-11-19. The chrome print controls no longer load in the iframe.

Comment 10

[Cody Crews]

I just wanted to say I appreciate the support I received from mozilla in the past few months.  I appreciate the payout on this sec-moderate especially.  I'm finally getting most of my life balanced again right now, and I should be able to be a lot more active and attacking the mozilla code base again.  I know this it's off topic to say this here, but I don't have any new bugs to file and I know this is the way where the people who have shown me the most support will see this.

Thanks a lot guys, without your support I wouldn't be even close to getting back into the swing of things.  I really can't stress that enough, I'm going to try to repay your support by bringing things at least as good as I have in the past.

:-)

Comment 11

[Al Billings [:abillings - ex-MoCo]]

You're very welcome! Thanks for your hard work on finding issues.