Closed Bug 648065 (CVE-2011-2378) Opened 11 years ago Closed 11 years ago
Child DOM Tree Inconsistency Remote Code Execution Vulnerability (ZDI-CAN-1141)
This could be a dup of bug 646662
provisionally critical, based on reputation and potential dupe.
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
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.
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.
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:220.127.116.11pre) Gecko/20110607 Namoroka/3.6.18pre (.NET CLR 3.5.30729)
Confirming since it's not a dupe
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 18.104.22.168pre build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) 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 126.96.36.199pre (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 188.8.131.52 -- 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*) ]
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: approval184.108.40.206?
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 220.127.116.11, a=dveditz
Attachment #547546 - Flags: approval18.104.22.168? → approval22.214.171.124+
Checked in to 1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/97b5edc11e01 Thanks for the quick review and approvals!
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
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: approval126.96.36.199?
Comment on attachment 547873 [details] [diff] [review] Followup fix Approved for 188.8.131.52, a=dveditz
Attachment #547873 - Flags: approval184.108.40.206? → approval220.127.116.11+
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:18.104.22.168) Gecko/20110803 Firefox/3.6.20). The PoC easily crashes 22.214.171.124 on XP (http://crash-stats.mozilla.com/report/index/bp-3f668e43-f1c8-4244-953b-0c2802110808) and does not crash post-fix.
You need to log in before you can comment on or make changes to this bug.