Last Comment Bug 648065 - (CVE-2011-2378) appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)
(CVE-2011-2378)
: appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-C...
Status: VERIFIED FIXED
[sg:critical][fix-range-wanted]
: verified1.9.2
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: 1.9.2 Branch
: All All
: -- normal (vote)
: ---
Assigned To: Jonas Sicking (:sicking)
:
Mentors:
jar:https://bugzilla.mozilla.org/atta...
Depends on: 639648
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-06 11:54 PDT by Brandon Sterne (:bsterne)
Modified: 2012-04-16 17:01 PDT (History)
12 users (show)
See Also:
Crash Signature:
[@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ] [@ nsNodeIterator::NodePointer::MoveToPrevious(nsINode*) ]
QA Whiteboard:
Iteration: ---
Points: ---
-
unaffected
-
unaffected
-
unaffected
-
unaffected
-
unaffected
.20+
.20-fixed


Attachments
Attempt 1 (1.80 KB, patch)
2011-07-21 15:54 PDT, Jonas Sicking (:sicking)
jst: review+
dveditz: approval1.9.2.20+
Details | Diff | Review
Followup fix (1022 bytes, patch)
2011-07-22 18:52 PDT, Jonas Sicking (:sicking)
jst: review+
dveditz: approval1.9.2.20+
Details | Diff | Review

Summon comment box

Description Brandon Sterne (:bsterne) 2011-04-06 11:54:26 PDT
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
Comment 1 Brandon Sterne (:bsterne) 2011-04-06 11:57:03 PDT
Created attachment 524226 [details]
PoC
Comment 2 Olli Pettay [:smaug] 2011-04-06 13:13:04 PDT
This could be a dup of bug 646662
Comment 3 Daniel Veditz [:dveditz] 2011-04-06 15:11:07 PDT
provisionally critical, based on reputation and potential dupe.
Comment 4 Brandon Sterne (:bsterne) 2011-04-06 15:25:16 PDT
Created attachment 524284 [details]
correct PoC

Attaching correct PoC
Comment 5 Boris Zbarsky [:bz] 2011-04-06 21:51:45 PDT
This is basically the same issue as bug 639648, no?
Comment 6 Daniel Veditz [:dveditz] 2011-05-19 13:50:47 PDT
(In reply to comment #5)
> This is basically the same issue as bug 639648, no?

We should test that: qawanted
Comment 7 chris hofmann 2011-05-19 13:54:18 PDT
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.
Comment 8 Al Billings [:abillings] 2011-05-19 17:38:54 PDT
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 Daniel Veditz [:dveditz] 2011-05-26 13:40:55 PDT
Al's basically saying he couldn't reproduce, not that he verified that bug 639648 fixed it.
Comment 10 Daniel Veditz [:dveditz] 2011-06-03 10:38:42 PDT
comment 7 stomped on the tracking flags, restoring. We are hoping that bug 639648 has fixed this but have been unable to verify.
Comment 11 christian 2011-06-06 10:18:51 PDT
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 [:Cww] 2011-06-06 16:12:42 PDT
Please investigate, get status of bug before Firefox 5 b5 builds.
Comment 13 Al Billings [:abillings] 2011-06-06 17:22:38 PDT
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 christian 2011-06-06 18:02:49 PDT
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 Al Billings [:abillings] 2011-06-07 11:33:54 PDT
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 Daniel Veditz [:dveditz] 2011-06-07 14:30:41 PDT
Confirming since it's not a dupe
Comment 17 Al Billings [:abillings] 2011-06-07 14:51:41 PDT
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 Boris Zbarsky [:bz] 2011-06-07 15:13:41 PDT
> 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 Al Billings [:abillings] 2011-06-07 15:16:39 PDT
I didn't realize that we build on January 1, 2010. We have a time machine!
Comment 20 Boris Zbarsky [:bz] 2011-06-07 15:23:31 PDT
> 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 christian 2011-06-07 15:37:59 PDT
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"]
Comment 22 Daniel Veditz [:dveditz] 2011-06-08 22:26:28 PDT
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?
Comment 23 Al Billings [:abillings] 2011-06-09 11:16:25 PDT
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 Johnny Stenback, on vacation until 7/23/2014 (:jst, jst@mozilla.com) 2011-06-09 13:11:15 PDT
Per comment 21 this sounds like it's really fixed in 5, so marking as such.
Comment 25 Daniel Veditz [:dveditz] 2011-06-09 13:12:29 PDT
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.
Comment 26 christian 2011-07-20 10:50:47 PDT
We would like some traction on this branch security bug...jonas, where is this in your queue?
Comment 27 Daniel Veditz [:dveditz] 2011-07-20 18:53:06 PDT
Still crashes in today's 3.6.20pre
bp-9137ac48-3ba4-4839-9f7b-d2c2a2110720
bp-0f506f85-6c28-401b-9c1c-26d5e2110720
Comment 28 Jonas Sicking (:sicking) 2011-07-21 15:54:51 PDT
Created attachment 547546 [details] [diff] [review]
Attempt 1

I can't compile 1.9.2 on my machine, but I *think* this should fix things. Attaching so that others can test it.
Comment 29 Jonas Sicking (:sicking) 2011-07-21 16:22:33 PDT
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 Daniel Veditz [:dveditz] 2011-07-21 16:44:07 PDT
Comment on attachment 547546 [details] [diff] [review]
Attempt 1

Approved for 1.9.2.20, a=dveditz
Comment 31 Jonas Sicking (:sicking) 2011-07-21 17:14:55 PDT
Checked in to 1.9.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/97b5edc11e01

Thanks for the quick review and approvals!
Comment 32 Jonas Sicking (:sicking) 2011-07-22 18:52:59 PDT
Created attachment 547873 [details] [diff] [review]
Followup fix

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.
Comment 33 :Gavin Sharp [away until July 14th] 2011-07-25 17:32:39 PDT
(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
Comment 34 Jonas Sicking (:sicking) 2011-07-26 10:57:33 PDT
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.
Comment 35 Daniel Veditz [:dveditz] 2011-07-26 13:38:53 PDT
Comment on attachment 547873 [details] [diff] [review]
Followup fix

Approved for 1.9.2.20, a=dveditz
Comment 37 Al Billings [:abillings] 2011-08-08 18:06:03 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.


Privacy Policy