Closed
Bug 648065
(CVE-2011-2378)
Opened 14 years ago
Closed 14 years ago
appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox5 | - | unaffected |
firefox6 | - | unaffected |
firefox7 | - | unaffected |
firefox8 | - | unaffected |
firefox9 | - | unaffected |
blocking1.9.2 | --- | .20+ |
status1.9.2 | --- | .20-fixed |
People
(Reporter: bsterne, Assigned: sicking)
References
()
Details
(Keywords: verified1.9.2, Whiteboard: [sg:critical][fix-range-wanted])
Crash Data
Attachments
(2 files)
1.80 KB,
patch
|
jst
:
review+
dveditz
:
approval1.9.2.20+
|
Details | Diff | Splinter Review |
1022 bytes,
patch
|
jst
:
review+
dveditz
:
approval1.9.2.20+
|
Details | Diff | Splinter Review |
ZDI-CAN-1141: Mozilla Firefox appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability
-- CVSS ----------------------------------------------------------------
9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)
-- ABSTRACT ------------------------------------------------------------
TippingPoint has identified a vulnerability affecting the following products:
Mozilla Firefox
-- VULNERABILITY DETAILS -----------------------------------------------
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Mozilla Firefox. User interaction is
required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw results when .setUserData() handlers are used with an object and .appendChild() is called within a handler. Ultimately the
import operation resulting from an .appendChild() is not guarded from mutation, and invalid DOM trees can result. Invalid DOM trees can be
navigated resulting in dereferencing invalid pointers which can be leveraged to execute arbitrary code in the context of the browser.
Version(s) tested: Mozilla Firefox 3.6.13
Platform(s) tested: Windows XP SP3
DOM method appendChild() seems flawed. Due to the way adoptNode() user data callback mechanism is implemented, user can "silently" re-adopt
node from within the handler. Hook is later re-executed, which allows attacker to build inconsistent DOM tree: with a single node being set as
a child of 2 parents at the same time. Child itself will be pointing back at one of its parents as THE parent. Somehow like on the diagram below:
root
/+ \+
// \\
+/ +\
parent1 parent2
\ /+
\ //
+ +/
child
In other words, JavaScript notation, all assertions hold:
root.childNodes.length == 2
root.childNodes[0] == parent1
root.childNodes[1] == parent2
root.parentNode == null
parent1.childNodes.length == 1
parent1.childNodes[0] == child
parent1.parentNode == root
parent2.childNodes.length == 1
parent2.childNodes[0] == child
parent2.parentNode == root
child.childNodes.length == 0
child.parentNode == parent2
This invalid DOM tree can be exploited in numerous ways, the POC illustrates one example using node iteration. The example POC results in attacker control of EIP:
(2e0.190): Access violation - code c0000005 (!!! second chance !!!)
eax=0c0c0c0c ebx=04ad2460 ecx=04ad2460 edx=109d8c34 esi=01b6a954
edi=00000000
eip=0c0c0c0c esp=0012eba8 ebp=0012ebec iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000206
<Unloaded_ta.dll>+0xc0c0c0b:
0c0c0c0c 0c0c or al,0Ch
Regarding filtering, this vulnerability can be triggered via JavaScript with many potential representations in code and as a result may be difficult if not impossible to filter.
-- CREDIT --------------------------------------------------------------
This vulnerability was discovered by:
* regenrecht
Reporter | ||
Comment 1•14 years ago
|
||
Comment 2•14 years ago
|
||
This could be a dup of bug 646662
Comment 3•14 years ago
|
||
provisionally critical, based on reputation and potential dupe.
Whiteboard: [sg:critical?]
Reporter | ||
Comment 4•14 years ago
|
||
Attaching correct PoC
Comment 5•14 years ago
|
||
This is basically the same issue as bug 639648, no?
Updated•14 years ago
|
Depends on: 639648
Whiteboard: [sg:critical?] → [sg:critical?] probably dupe of 639648
Comment 6•14 years ago
|
||
(In reply to comment #5)
> This is basically the same issue as bug 639648, no?
We should test that: qawanted
blocking1.9.2: --- → .18+
status1.9.2:
--- → wanted
status-firefox5:
--- → affected
tracking-firefox5:
--- → +
tracking-firefox6:
--- → +
Keywords: qawanted
Comment 7•14 years ago
|
||
sounds like the way to confirm is to test both mozilla-central and aurora/beta builds after may 16 to confirm. mozilla-central and aurora/beta builds took different approaches to fix.
blocking1.9.2: .18+ → ---
status1.9.2:
wanted → ---
status-firefox5:
affected → ---
tracking-firefox5:
+ → ---
tracking-firefox6:
+ → ---
Comment 8•14 years ago
|
||
The attached PoC does not crash the May 15 Aurora build on XP SP3 (Mozilla/5.0 (Windows NT 5.1; rv:5.0a2) Gecko/20110515 Firefox/5.0a2) nor the 5/17 Aurora build on the same machine.
This was with normal nightly Aurora builds.
Comment 9•14 years ago
|
||
Al's basically saying he couldn't reproduce, not that he verified that bug 639648 fixed it.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Updated•14 years ago
|
Whiteboard: [sg:critical?] probably dupe of 639648 → probably dupe of 639648
Comment 10•14 years ago
|
||
comment 7 stomped on the tracking flags, restoring. We are hoping that bug 639648 has fixed this but have been unable to verify.
blocking1.9.2: --- → .18+
status1.9.2:
--- → wanted
status-firefox5:
--- → affected
tracking-firefox5:
--- → +
Comment 11•14 years ago
|
||
We have bug 639648 on branch now. Al said he'd check to see if it happened before and was fixed after that landing.
Comment 12•14 years ago
|
||
Please investigate, get status of bug before Firefox 5 b5 builds.
Whiteboard: probably dupe of 639648 → probably dupe of 639648 [blocks-fx5b5]
Comment 13•14 years ago
|
||
Bug 639648 was fixed near 11:00 PM on 6/5. In the 6/6 build on XP SP3, the PoC attached to *this* bug still crashes immediately when loaded.
Build ID: https://bugzilla.mozilla.org/attachment.cgi?id=524284
Crash: https://crash-stats.mozilla.com/report/index/bp-82319067-33a5-4807-9cde-a637a2110606
Bug 639648 is fixed now and it crashes pre-fix with its testcase. So these appear to not be the same exact issue.
Comment 14•14 years ago
|
||
Al, can you get the changeset from about:buildconfig so we can be sure the fix was expected to be in there (so we rule out nightly automation taking an older changeset)? Thanks!
Comment 15•14 years ago
|
||
Changeset is http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d12c5c6f9c02.
Updating it to the next day's build has the same issue.
Changeset for that is http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8a583b29d673 and the build ID is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18pre) Gecko/20110607 Namoroka/3.6.18pre (.NET CLR 3.5.30729)
Comment 16•14 years ago
|
||
Confirming since it's not a dupe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Whiteboard: probably dupe of 639648 [blocks-fx5b5] → [sg:critical?] probably dupe of 639648 [blocks-fx5b5]
Comment 17•14 years ago
|
||
As asked, I checked in Firefox 5 b4 build on the same machine, XP SP3. No crash with PoC.
Weirdly, the Build ID is Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0.
Changeset is: http://hg.mozilla.org/releases/mozilla-beta/rev/19cc7d157bfa
Comment 18•14 years ago
|
||
> Weirdly, the Build ID is Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101
> Firefox/5.0.
That looks like the right build id....
Comment 19•14 years ago
|
||
I didn't realize that we build on January 1, 2010. We have a time machine!
Comment 20•14 years ago
|
||
> I didn't realize that we build on January 1, 2010
See http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/ item 6 in the list.
Comment 21•14 years ago
|
||
FWIW, on Fx5b4 I don't crash and I get this assertion in the web console:
[15:35:37.525] uncaught exception: [Exception... "Node cannot be used in a document other than the one in which it was created" code: "4" nsresult: "0x80530004 (NS_ERROR_DOM_WRONG_DOCUMENT_ERR)" location: "file:///Users/legnitto/Downloads/1141/append-tree-inconsistency_poc.html Line: 34"]
Whiteboard: [sg:critical?] probably dupe of 639648 [blocks-fx5b5] → [sg:critical?] probably dupe of 639648
Comment 22•14 years ago
|
||
assigning to Jonas since he fixed bug 639648 that is similar but didn't actually fix this one. If Olli was right in comment 2 then we should test tomorrow's build to see if bug 646662 fixes it (but I'm not hopeful).
Is it possible Firefox 5 is not actually "fixed" but simply can't reproduce with this testcase due to other changes?
Assignee: nobody → jonas
Whiteboard: [sg:critical?] probably dupe of 639648 → [sg:critical][fix-range-wanted]
Comment 23•14 years ago
|
||
I just tested this in last night's 1.9.2.18pre build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18pre) Gecko/20110609 Namoroka/3.6.18pre (.NET CLR 3.5.30729)) which was built from this changeset: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2f84a687522f.
It isn't fixed for 1.9.2. The PoC crashes 1.9.2.18pre (see https://crash-stats.mozilla.com/report/index/bp-e50f8d8a-43ae-40df-abe7-f8e672110609).
Comment 24•14 years ago
|
||
Per comment 21 this sounds like it's really fixed in 5, so marking as such.
Comment 25•14 years ago
|
||
If fx4/5 are OK then we don't need to rush a fix into the already-late 1.9.2.18 -- try it next time.
blocking1.9.2: .18+ → .19+
Updated•14 years ago
|
status-firefox6:
--- → unaffected
status-firefox7:
--- → unaffected
tracking-firefox6:
--- → -
tracking-firefox7:
--- → -
Comment 26•14 years ago
|
||
We would like some traction on this branch security bug...jonas, where is this in your queue?
Comment 27•14 years ago
|
||
Still crashes in today's 3.6.20pre
bp-9137ac48-3ba4-4839-9f7b-d2c2a2110720
bp-0f506f85-6c28-401b-9c1c-26d5e2110720
Crash Signature: [@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ]
Updated•14 years ago
|
Crash Signature: [@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ] → [@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ]
[@ nsNodeIterator::NodePointer::MoveToPrevious(nsINode*) ]
Assignee | ||
Comment 28•14 years ago
|
||
I can't compile 1.9.2 on my machine, but I *think* this should fix things. Attaching so that others can test it.
Assignee | ||
Updated•14 years ago
|
Updated•14 years ago
|
Attachment #547546 -
Flags: review+
Assignee | ||
Updated•14 years ago
|
Attachment #547546 -
Flags: approval1.9.2.20?
Assignee | ||
Comment 29•14 years ago
|
||
This fix should be fairly safe. All we do is to throw in situations that are very unlikely to arise other than in malicious cases involving either userdata handlers or mutation events.
Comment 30•14 years ago
|
||
Comment on attachment 547546 [details] [diff] [review]
Attempt 1
Approved for 1.9.2.20, a=dveditz
Attachment #547546 -
Flags: approval1.9.2.20? → approval1.9.2.20+
Assignee | ||
Comment 31•14 years ago
|
||
Checked in to 1.9.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/97b5edc11e01
Thanks for the quick review and approvals!
Assignee | ||
Comment 32•14 years ago
|
||
Ouch, the last attachment caused a pretty bad regression. I had missed the fact that doctypes need special handling. They aren't used a lot on the web, but probably enough that we don't want to ship in the current state.
Attachment #547873 -
Flags: review?(jst)
Assignee | ||
Updated•14 years ago
|
Comment 33•14 years ago
|
||
(In reply to comment #32)
> Ouch, the last attachment caused a pretty bad regression.
Is this what's causing the persistent test failure on 1.9.2?
http://tbpl.mozilla.org/?tree=Firefox3.6
Updated•13 years ago
|
Attachment #547873 -
Flags: review?(jst) → review+
Assignee | ||
Comment 34•13 years ago
|
||
Comment on attachment 547873 [details] [diff] [review]
Followup fix
Yes, this is the cause of that orange. Let me know if you want me to back out until this one gets approval.
Attachment #547873 -
Flags: approval1.9.2.20?
Comment 35•13 years ago
|
||
Comment on attachment 547873 [details] [diff] [review]
Followup fix
Approved for 1.9.2.20, a=dveditz
Attachment #547873 -
Flags: approval1.9.2.20? → approval1.9.2.20+
Comment 36•13 years ago
|
||
Updated•13 years ago
|
Alias: CVE-2011-2378
Summary: Mozilla Firefox appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141) → appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)
Comment 37•13 years ago
|
||
Verified fixed in 1.9.20 build 1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20). The PoC easily crashes 1.9.2.18 on XP (http://crash-stats.mozilla.com/report/index/bp-3f668e43-f1c8-4244-953b-0c2802110808) and does not crash post-fix.
Keywords: verified1.9.2
Updated•13 years ago
|
status-firefox8:
--- → unaffected
status-firefox9:
--- → unaffected
tracking-firefox8:
--- → -
tracking-firefox9:
--- → -
Updated•13 years ago
|
Group: core-security
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•