Last Comment Bug 328937 - (ZDI-CAN-026) Table Rebuilding Code Execution Vulnerability (ZDI-06-011, CVE-2006-0748 )
(ZDI-CAN-026)
: Table Rebuilding Code Execution Vulnerability (ZDI-06-011, CVE-2006-0748 )
Status: VERIFIED FIXED
[sg:critical][rft-dl]
: fixed1.7.13, verified1.8.0.2, verified1.8.1
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
Mentors:
Depends on: 317554
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-28 23:15 PST by Daniel Veditz [:dveditz]
Modified: 2007-01-08 06:43 PST (History)
11 users (show)
dveditz: blocking1.7.13+
dveditz: blocking‑aviary1.0.8+
dveditz: blocking1.9a1+
dveditz: blocking1.8.1+
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Daniel Veditz [:dveditz] 2006-02-28 23:15:35 PST
From the Zero Day Initiative (http://www.zerodayinitiative.com):

ZDI-CAN-026: Mozilla Firefox Table Rebuilding Code Execution Vulnerability

-- ABSTRACT ------------------------------------------------------------

3Com has identified a vulnerability affecting the following products:

Mozilla 1.7.x and below
Mozilla Firefox 1.5.x and below

-- VULNERABILITY DETAILS -----------------------------------------------

A remotely exploitable vulnerability exists in the latest versions of 
the Firefox web browser.

The flaw is due to incorrect rebuilding of malformed table tags.  When

Firefox tries to fix a broken table an attacker can influence code 
execution to user supplied data.

The vulnerable function RebuildConsideringRows() can be found in:

layout/html/table/src/nsCellMap.cpp

RebuildConsideringRows is passed a variable named aStartRowIndex with 
the value of -1.  Later the following loop is executed.

...
1928 for (PRInt32 copyRowX = copyStartRowIndex; copyRowX <= \
          copyEndRowIndex; copyRowX++) {
1929     nsVoidArray* row = (nsVoidArray *)origRows[copyRowX];
1930     PRInt32 numCols = row > Count();
1931     for (colX = 0; colX < numCols; colX++) {
1932         // put in the original cell from the cell map
1933         CellData* data = (CellData*) row > ElementAt(colX);
1934         if (data && data>IsOrig()) {
1935             AppendCell(aMap, data>GetCellFrame(), rowX, PR_FALSE,
\
                            aDamageArea);
1936         }
1937     }
...

Where copyStartRowIndex is set to -1 from the aStartRowIndex.

When we are able to fill the memory in front of the Array with valid 
memory addresses code execution is possible.

At line 1935 AppendCell is called with a value from the data structure

"data", which should be under our control at that moment. In AppendCell

GetRowSpanForNewCell() is called with this value. 

And ultimately this line is executed:

PRInt32 rowSpan = aCellFrameToAdd.GetRowSpan();

Where aCellFrameToAdd is the value under our control. This is the place

where arbitrary code execution is possible.

Tested Versions:

Mozilla 1.7.12
Mozilla Firefox 1.5.0.1
Mozilla Firefox 1.5
Mozilla Firefox 1.0.7

Testing was done with Windows XP SP2 and Fedora Core 4.

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:

    Anonymous
Comment 2 Daniel Veditz [:dveditz] 2006-02-28 23:33:00 PST
This testcase exploit appears to be stopped sometime during 1.8.0.2 -- Fixed by by one of the StirDOM patches hopefully, though maybe they just rearranged things enough to prevent this particular exploit without solving the problem. No changes to nsCellMap itself have been made during 1.5.0.2 development.

I've confirmed that the exploit works on 1.0.7 and 1.5.0.1
Comment 3 Daniel Veditz [:dveditz] 2006-03-01 00:01:51 PST
The exploit works against a release 1.5.0.2 as well -- no fix.
Comment 4 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-03-01 04:57:47 PST
I don't see the exploit. However, it crashes when I change the code from for(x = 0; x<1024; to for(x = 0; x<10;.
In that case I get a regression range between 2005-12-15 (crashing) and 2005-12-17 (not crashing).
The fix for bug 317554 was checked in at that time (in trunk, not 1.8.0.x branch), so maybe that fix prevents the exploit?
Comment 5 Bernd 2006-03-01 10:46:51 PST
Backing out bug 317554 makes the trunk also crash. So if this needs to be fixed approving  the patch in bug 317554 would help.
Comment 6 Bernd 2006-03-01 12:41:27 PST
The testcase looks pretty much like somebody did run fuzz testing against ff and then after it crashed, reduced the testcase, and then stuffed it with the exploit code.
Comment 7 Daniel Veditz [:dveditz] 2006-03-01 17:04:27 PST
(In reply to comment #6)
> The testcase looks pretty much like somebody did run fuzz testing against ff
> and then after it crashed, reduced the testcase, and then stuffed it with the
> exploit code.

Yup, that's what they're doing; it's one reason exploits seem to be coming faster these days. There are sites that archive the exploit code that can be simply plugged into an appropriate memory abuse. See http://metasploit.com for example.
Comment 8 Daniel Veditz [:dveditz] 2006-03-01 22:13:02 PST
The patch in bug 317554 has been checked in and fixes this vulnerability
Comment 9 Dave Liebreich [:davel] 2006-03-02 09:08:14 PST
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates).  This bug and bug 317554 can most likely be verified simultaneously.
Comment 10 Tracy Walker [:tracy] 2006-03-02 10:22:39 PST
reopening.  This still occurs on Firefox 1.0.8 with installer build from 2006-03-02-04-aviary1.0.1 and Mozilla 1.7.13 stub installer build 2006-03-02-09-1.7

in both cases the calc launched as our browser was shut down.
Comment 11 Tracy Walker [:tracy] 2006-03-02 10:31:19 PST
apparently, the tested builds had not picked up the fix. returning resolution to fixed.
Comment 12 Tracy Walker [:tracy] 2006-03-02 14:05:37 PST
verified with Fx 1.0.8 respin on windows. waiting for Moz 1.7.x respin

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