648065 - (CVE-2011-2378) appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Brandon Sterne (:bsterne)]

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)]

Attachment: PoC

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

This could be a dup of bug 646662

Comment 3

[Daniel Veditz [:dveditz]]

provisionally critical, based on reputation and potential dupe.

Comment 4

[Brandon Sterne (:bsterne)]

Attachment: correct PoC

Attaching correct PoC

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is basically the same issue as bug 639648, no?

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> This is basically the same issue as bug 639648, no?

We should test that: qawanted

Comment 7

[chris hofmann]

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 - ex-MoCo]]

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]]

Al's basically saying he couldn't reproduce, not that he verified that bug 639648 fixed it.

Comment 10

[Daniel Veditz [:dveditz]]

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

[LegNeato]

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]]

Please investigate, get status of bug before Firefox 5 b5 builds.

Comment 13

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

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

[LegNeato]

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 - ex-MoCo]]

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]]

Confirming since it's not a dupe

Comment 17

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

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 [:bzbarsky]]

> 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 - ex-MoCo]]

I didn't realize that we build on January 1, 2010. We have a time machine!

Comment 20

[Boris Zbarsky [:bzbarsky]]

> 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

[LegNeato]

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]]

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 - ex-MoCo]]

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 (:jst)]

Per comment 21 this sounds like it's really fixed in 5, so marking as such.

Comment 25

[Daniel Veditz [:dveditz]]

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

[LegNeato]

We would like some traction on this branch security bug...jonas, where is this in your queue?

Comment 27

[Daniel Veditz [:dveditz]]

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) No longer reading bugmail consistently]

Attachment: 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) No longer reading bugmail consistently]

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]]

Comment on attachment 547546 [details] [diff] [review]
Attempt 1

Approved for 1.9.2.20, a=dveditz

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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) No longer reading bugmail consistently]

Attachment: 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 [email: [e-mail]]]

(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) No longer reading bugmail consistently]

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]]

Comment on attachment 547873 [details] [diff] [review]
Followup fix

Approved for 1.9.2.20, a=dveditz

Comment 36

[LegNeato]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e828fec9dc31

Comment 37

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

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.