Closed Bug 576075 (CVE-2010-3168) Opened 9 years ago Closed 9 years ago
tree Object Removal Remote Code Execution Vulnerability (ZDI-CAN-817)
bp-1622bdfd-786f-4d9b-ad21-b97802100630 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file build/content/base/src/nsContentUtils.cpp, line 3534 ###!!! ASSERTION: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file build/layout/base/nsPresContext.h, line 1275 Crash [@ nsStyleContext::GetRuleNode] [@ nsBoxFrame::RemoveFrame]
Again, we need to prevent content script from implement nsITreeSelection. How do we do that?
In fact, why should content script *ever* be allowed to implement XPCOM interfaces via XPConnect?
In fact I thought we changed things to prevent that already...
It's required for some DOM stuff... EventListener objects, specifically. :( I would be fine with needing to explicitly flag interfaces that content script can implement, though.
OK, then let's do that.
On 3.6.x I get bp-25fbd0c4-b2ae-4e0c-bd95-ac5052100630 -- isn't that a frame-poisoned address and evidence that we've neutered this one? On 3.5.x it's bad though, looks like it's off executing at a random address: bp-47bf29d4-1c50-4fe0-b24b-4e85a2100630
I don't know of a way to specifically prevent content code from implementing a specific interface, we'd pretty much need to do what bz suggested, e.g. explicitly marking the interfaces that we do let content implement (event handlers, user data handlers, tree iterator callbacks, etc). But we could plug this hole if we simply made the tree.treeBoxObject.view object check in its selection setter that the given nsITreeSelection really is what we expect it to be (by QIing to a non-scriptable interface and making sure that QI succeeds). We do similar things in various places in the DOM code (by QI'ing to nsIContent or what not).
Yeah, we need to do both.
blocking1.9.1: ? → .12+
blocking1.9.2: ? → .8+
Whiteboard: [sg:critical?] → [sg:critical?] maybe just sg:dos in 1.9.2 and later?
Whiteboard: [sg:critical?] maybe just sg:dos in 1.9.2 and later? → [sg:critical?] maybe sg:dos in 1.9.2 and later?
Assignee: nobody → Olli.Pettay
Whiteboard: [sg:critical?] maybe sg:dos in 1.9.2 and later? → [sg:critical?] maybe sg:dos in 1.9.2 and later? [critsmash:investigating]
Sorry for the delay. I'll look into this later today or tomorrow.
The patch is on purpose very similar to Bug 326501, but had to add security check also the treebuilder. As far as I see, other SetSelection methods aren't accessible from content.
Attachment #460843 - Flags: review?
Attachment #460843 - Flags: review? → review?(enndeakin)
And because we need the patch for branches, I didn't make a generic "IsNative" interface, but took the safer approach and added a new interface for TreeSelection.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 460843 [details] [diff] [review] patch a=LegNeato for 22.214.171.124 and 126.96.36.199.
Verified for 188.8.131.52 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20100817 Namoroka/3.6.9pre ( .NET CLR 3.5.30729) using PoC. Does not crash as it does in 220.127.116.11. Verified for 18.104.22.168 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20100817 Shiretoko/3.5.12pre ( .NET CLR 3.5.30729) using same PoC. Does not crash as it does in 126.96.36.199.
You need to log in before you can comment on or make changes to this bug.