Closed Bug 648065 (CVE-2011-2378) Opened 10 years ago Closed 9 years ago

appendChild DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)

Categories

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

1.9.2 Branch
defect
Not set
normal

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)

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
Attached file PoC (obsolete) —
This could be a dup of bug 646662
provisionally critical, based on reputation and potential dupe.
Whiteboard: [sg:critical?]
Attached file correct PoC
Attaching correct PoC
This is basically the same issue as bug 639648, no?
Depends on: 639648
Whiteboard: [sg:critical?] → [sg:critical?] probably dupe of 639648
(In reply to comment #5)
> This is basically the same issue as bug 639648, no?

We should test that: qawanted
blocking1.9.2: --- → .18+
Keywords: qawanted
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+ → ---
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.
Al's basically saying he couldn't reproduce, not that he verified that bug 639648 fixed it.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Whiteboard: [sg:critical?] probably dupe of 639648 → probably dupe of 639648
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+
We have bug 639648 on branch now. Al said he'd check to see if it happened before and was fixed after that landing.
Please investigate, get status of bug before Firefox 5 b5 builds.
Whiteboard: probably dupe of 639648 → probably dupe of 639648 [blocks-fx5b5]
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.
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!
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)
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]
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
> 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....
I didn't realize that we build on January 1, 2010. We have a time machine!
> 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.
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
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]
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).
Per comment 21 this sounds like it's really fixed in 5, so marking as such.
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+
We would like some traction on this branch security bug...jonas, where is this in your queue?
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) ]
Crash Signature: [@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ] → [@ nsNodeIterator::NodePointer::MoveBackward(nsINode*, int) ] [@ nsNodeIterator::NodePointer::MoveToPrevious(nsINode*) ]
Attached patch Attempt 1Splinter Review
I can't compile 1.9.2 on my machine, but I *think* this should fix things. Attaching so that others can test it.
Attachment #547546 - Flags: review+
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 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+
Checked in to 1.9.2

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

Thanks for the quick review and approvals!
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Attached patch Followup fixSplinter Review
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)
(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
Attachment #547873 - Flags: review?(jst) → review+
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 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+
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)
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
Group: core-security
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.