User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130910160258 Steps to reproduce: I combined an old testcase showing access to anonymous content with a new technique to trigger chrome level XBL bindings from xul.css. Actual results: Since any XULElement with the proper class attribute from xul.css will trigger the corresponding binding, its possible to gain access to additional types of XULElements through the existing boxObject API. This testcase gets a menupopup element and then has the XBL code QueryInterface its existing boxObject giving access to a popupBoxObject and all of its methods and properties. It's worth noting that for the sake of time I used document.getAnonymousNodes which I know wont be available much longer. The only other option involved the observe function from the XMLPrettyPrint.xml#prettyprint binding, and that isn't available in the newest nightly so yeah no real choice about that. It's possible to get boxObjects QI'ed into other types than popupBoxObject, I have already had a scrollBoxObject as well. I really have no idea where I was going with this in the end, I was just playing around with some different ideas but theres definitely some concerns here. It also may be possible to fool chrome level code into working with or accessing properties on an object that it expects to be safe. This is because most things handed back by the boxObject API aren't the content level wrappedJSObject. Even if you were to access something like 'document.wrappedJSObject.firstChild.boxObject.element' you would actually still need to unwrap that reference even though it was obtained from a wrappedJSObject. Please forgive any errors and correct me where I'm wrong, because I am very tired right now and was barely able to get the time to get this in tonight. Expected results: These bindings shouldn't be triggered at content level just by having access to a XULElement. I believe most of these issues will be taken care of very soon so I think that will be the case.

Thought I should point out when talking about the wrappedJSObject part, I said that kind of in reverse but I think the point makes sense, I could definitely see some confusion arising from chrome code accessing something it thinks its already unwrapped.

Ok - I'm pretty sure that bug 914618, bug 911864, and bug 912322 should collectively be enough to avoid this kind of thing. Do you agree, Cody? Or are there other measures you think we should put in place?

I think that should take care of it, just to be sure Ill be doing some more extensive testing over the next few days. You can obtain the anonymous label element of <input type="file"> just like the anonymous scale, but with the changes from those bugs, I hope that wont be an issue anymore. I did try similar methods to get the menupopup element here in the newest nightly with no success, so its looking much more locked down.

Ill be waiting for as many patches as possible to show up in nightly before going over this again later this evening, I believe there may be a route to a menupopup that doesn't involve getAnonymous* and I'm aiming to trigger the editor bindings too, but thats dreaming ;-)

Marking sec-moderate based on related bugs, change if you think that's not correct.

This shows boxObject escalation working in the newest nightly, and using an anonymous label just for some variety.

Ill still be playing and waiting on all patches from these bugs to take shape before hitting this any harder. I know there's a lot going on with all of this, so Ill be trying so new ideas probably and unless something catches my eye. Let me know if you need any info from me on any of this.

Yeah i have to quit doing these testcases after long days before I crash, that's a mess. Ill be here.

Same thing here as bug 817922 since I can see no possible way to manipulate anonymous content, do we really need to leave this bug open? I'm just trying to clean up everything so far that I have done that is left hanging because it either lead into something else or was cleaned up in a patch elsewhere.

Cody, would you say that this bug is a duplicate of bug 817922? Or just that it isn't valid anymore and/or is being covered by other changes?

This bug is not a duplicate of that at all(though definitely related), its a much more developed possible attack vector that came from the base work of that bug. The issue here is that if you can gain access to any XUL element, and freely have the ability to add that XUL element as the root element of a document, all you have to do is match the class definitions and such as defined in xul.css and it then triggers chrome level bindings that should never even be seen in content. I dropped the follow up work on it because with work from bholley who has been taking care of all the XBL security holes, and bz who initially tried to guide me on taking on a patch which we all knew was over my head(thanks again for the clean up on that guys), it seems to me that gaining access to a XUL element is going to be a very tricky thing. I can usually find multiple ways to actually fully access these elements, not just gain references to them and I have literally ran through the book recently after the work they have put in and I haven't so much as had a hint of any of it being worth even the time spent. I consider this one done now because of their hard work. At the time this was hanging open I knew I could have elevated this to a high security rating at least but that would have just been me being greedy because I knew that when the work that was already being discussed was completed that this *should* no longer be an issue. I'm going to leave the call up to bholley unless someone tells me a reason not to, because hes probably more aware of any other remaining XBL issues and overall that's been his focus point. Most of the changes that made this nothing to worry about have come directly from him and/or bz. I'm sure they can explain if there's any reason that keeping this new and active would be beneficial. If there's nothing overly important I would just as well prefer to bury these kinds of bugs even if they never get properly published because anything in them could possibly guide someone who might know something I don't right back to here but maybe having something that would rate either high/critical. The bottom line is I consider my work here well spent already because this did all spawn from things that started with bug 817922. I had my fun, and it really was a very enjoyable thing but XBL is feeling quite secure lately. There's some ways that I can interfere with running XBL code and such but none of them give an opportunity to actually access any anonymous content(or even references of) as of now. I almost forgot that it may actually be possible to get a reference to some anonymous html div elements, but again without having a xul element there's nothing to worry about.

Yeah, I think we're in good shape here. Once bug 986730, bug 825392, and bug 990290 (all on FF31) make it release/ESR, I think we can open up all of these XBL bugs (assuming cody agrees, which it sounds like he does).

Yeah sounds good, Ill drop you a mail about something that I've discovered but I can't actually see it being an issue in the end. Actually just check out bug 999034 and I'll make a comment about it there.

Give that bug 986730, bug 825392, and bug 990290 are all FIXED. Does that mean that this one is too?

(In reply to Jonas Sicking (:sicking) from comment #14) > Give that bug 986730, bug 825392, and bug 990290 are all FIXED. Does that > mean that this one is too? I think so, yeah.