328937 - (ZDI-CAN-026) Table Rebuilding Code Execution Vulnerability (ZDI-06-011, CVE-2006-0748 )

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Daniel Veditz [:dveditz]]

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

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

The exploit works against a release 1.5.0.2 as well -- no fix.

Comment 4

[Martijn Wargers (dead)]

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]

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]

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

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

The patch in bug 317554 has been checked in and fixes this vulnerability

Comment 9

[Dave Liebreich [:davel]]

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

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

apparently, the tested builds had not picked up the fix. returning resolution to fixed.

Comment 12

[Tracy Walker [:tracy]]

verified with Fx 1.0.8 respin on windows. waiting for Moz 1.7.x respin