439735 - (CVE-2008-2811) exploitable crash at nsBlockFrame::DrainOverflowLines

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: iSight Partners PoC

This was reported to Mozilla today by iSight Partners.  I can confirm that the PoC page (which I'll attach shortly) crashes Firefox 2.0.0.14 on all three platforms.  On Mac, I crash with the stack pasted below.  Note that address space that we crash on is identical to that mentioned in the advisory.  The full report is attached.

Process:         firefox-bin [28540]
Path:            /Applications/Firefox 2.app/Contents/MacOS/firefox-bin
Identifier:      org.mozilla.firefox
Version:         2.0.0.14 (2.0.0.14)
Code Type:       X86 (Native)
Parent Process:  launchd [1]

Date/Time:       2008-06-17 15:03:57.922 -0700
OS Version:      Mac OS X 10.5.3 (9D34)
Report Version:  6

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   ???                           	0x02020202 0 + 33686018
1   org.mozilla.firefox           	0x005f2769 nsBlockFrame::DrainOverflowLines(nsBlockReflowState&) + 959
2   org.mozilla.firefox           	0x005f6b48 nsBlockFrame::ComputeFinalSize(nsHTMLReflowState const&, nsBlockReflowState&, nsHTMLReflowMetrics&) + 2498
3   org.mozilla.firefox           	0x0042afbc nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&) + 94
4   org.mozilla.firefox           	0x0061ecf4 CanvasFrame::GetType() const + 1358
5   org.mozilla.firefox           	0x0042afbc nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&) + 94

Comment 1

[Brandon Sterne (:bsterne)]

Attachment: This CRASHES BRANCH!

Comment 2

[Daniel Veditz [:dveditz]]

un-privatizing the PoC for now: it's unnecessary while the bug itself is private and prevents us from including people (via CC:) to help with the bug who aren't already on the security-group.

The advisory date was May 10, but this was just received by the security alias when Brandon filed the bug. If we'd received it then we might have been able to get a fix into the all-but-shipped 2.0.0.15 release.

Didn't crash in Minefield but hung, possibly because I was out of memory. Need to investigate trunk further. If it is fixed on trunk would be nice to find a "fix" range (and hope it wasn't the reflow-branch landing).

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase2

This is without the memory-filling code, which is really annoying if you want to find a regression range for the crash. This still crashes branch, but not trunk.

Comment 4

[Martijn Wargers (dead)]

On trunk the fix range seems to be between 2007-02-06 and 2007-02-07:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+04&maxdate=2007-02-07+07&cvsroot=%2Fcvsroot
Somehow fixed by bug 177805, I guess.

Comment 5

[Daniel Veditz [:dveditz]]

bug 177805 is a big change, hopefully there's a simpler band-aid we can take.

Damon: please assign to the appropriate person on your team.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I suspect being "fixed" bug bug 177805 means the bug would probably still show up after bug 177805 with a different number in the border attribute.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It might be useful to:
 * find a different number for border that would still crash the 2007-02-07 build
 * see if that testcase still crashes trunk
   + if so, it's useful for testing
   + if not, find a new fix date

Note that bug 177805 changed our internal units from being 20 per point (which, at 96dpi, means 15 per pixel) to being 60 per pixel.  If the range of values causing the crash is very specific, you may also need to adjust the body margins and/or the image size.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd note that to get attachment 325557 [details] to crash for me on Linux on a 2007-02-06-04-trunk build, I need to set the layout.css.dpi pref to 96 (which is effectively what it will default to for most Windows users and all Mac users, I think).

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For what it's worth 35791400 pixels, at 15 twips per pixel (96dpi), is 0x20000058.  That's just above nscoord_MAX.

I tried a testcase with 8947850 in the 2007-02-07-04-trunk build and that didn't crash for me, though.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In 2007-02-06-04-trunk, 96dpi, on Linux, I see white with values 35791337 and less, see black with 35791338, and crash with 35791339 and higher (I couldn't find an upper limit).

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase that crashes after units landing

This crashes 2007-02-07-04-trunk on Linux.  The crash turned to a hang (still haven't isolated that change), and then the hang turned into loading fine between 2008-03-07-04-trunk and 2008-03-08-04-trunk.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The hang on attachment 325683 [details] started between 2007-07-01-04-trunk and 2007-07-02-04-trunk, but the crash was actually fixed (so there was an interval between when it worked fine) between 2007-06-01-04-trunk and 2007-06-02-04-trunk, which may be the range where we really want to look for a fix.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, that 06-01 to 06-02 crash fix was a fix for crashing on startup, not crashing on this testcase, so it's the wrong range.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 325683 [details]
testcase that crashes after units landing

OK, when I said this crashes after the units landing, I must have been testing the wrong build.  It doesn't crash for me anymore, so I have nothing useful.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, it does crash after the units landing if I create a fresh profile with the build in question, and the crash went away between 2007-03-11-04-trunk and 2007-03-12-04-trunk.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd guess it was probably fixed by attachment 257911 [details] [diff] [review] on bug 372237.  Could somebody with a branch tree handy try that?

Comment 17

[Martijn Wargers (dead)]

Attachment: branch patch

Yeah, the patch from bug 372237 seems to fix this.
I had to alter the patch for branch into this, otherwise it wouldn't compile.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks ok to me, but you probably want to ask roc to review the merged version.

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 325743 [details] [diff] [review]
branch patch

Approved for 1.8.1.15 and 1.8.1.16, a=dveditz for release-drivers

Please land on both the MOZILLA_1_8_BRANCH and the GECKO181_20080612_RELBRANCH, and give it both fixed1.8.1.15 and fixed1.8.1.16 keywords.

Comment 20

[Martijn Wargers (dead)]

Checking in nsIFrame.h;
/cvsroot/mozilla/layout/generic/nsIFrame.h,v  <--  nsIFrame.h
new revision: 3.291.6.4; previous revision: 3.291.6.3
done

Checked into the MOZILLA_1_8_BRANCH tree.

Checking in nsIFrame.h;
/cvsroot/mozilla/layout/generic/nsIFrame.h,v  <--  nsIFrame.h
new revision: 3.291.6.3.28.1; previous revision: 3.291.6.3
done

Checked into the GECKO181_20080612_RELBRANCH tree.

Comment 21

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

Verified crash in Firefox 2.0.0.14. Using build 3 of 2.0.0.15, there is no crash.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15) Gecko/2008062305 Firefox/2.0.0.15

Comment 22

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

Verified in 2.0.0.16 as well: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.16) Gecko/2008070205 Firefox/2.0.0.16.

Comment 23

[Alexander Sack]

Comment on attachment 325743 [details] [diff] [review]
branch patch

a=asac for 1.8.0