Last Comment Bug 439735 - (CVE-2008-2811) exploitable crash at nsBlockFrame::DrainOverflowLines
(CVE-2008-2811)
: exploitable crash at nsBlockFrame::DrainOverflowLines
Status: VERIFIED FIXED
[sg:critical] trunk fixed by 372237
: crash, verified1.8.1.15, verified1.8.1.16
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 1.8 Branch
: All All
: -- critical (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
:
Mentors:
Depends on: 372237
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-17 15:26 PDT by Brandon Sterne (:bsterne)
Modified: 2009-01-05 12:05 PST (History)
9 users (show)
dveditz: blocking1.8.1.15+
dveditz: wanted1.8.1.x+
asac: blocking1.8.0.next+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase2 (655 bytes, text/html)
2008-06-18 06:38 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
testcase that crashes after units landing (655 bytes, text/html)
2008-06-18 18:34 PDT, David Baron :dbaron: ⌚️UTC-7 (busy September 14-25)
no flags Details
branch patch (1.33 KB, patch)
2008-06-19 05:51 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
roc: review+
roc: superreview+
dveditz: approval1.8.1.15+
dveditz: approval1.8.1.16+
asac: approval1.8.0.next+
Details | Diff | Splinter Review

Description Brandon Sterne (:bsterne) 2008-06-17 15:26:03 PDT
Created attachment 325456 [details]
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) 2008-06-17 15:33:01 PDT
Created attachment 325458 [details]
This CRASHES BRANCH!
Comment 2 Daniel Veditz [:dveditz] 2008-06-18 01:09:28 PDT
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 [:mwargers] (not working for Mozilla) 2008-06-18 06:38:33 PDT
Created attachment 325557 [details]
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 [:mwargers] (not working for Mozilla) 2008-06-18 06:53:26 PDT
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] 2008-06-18 17:05:48 PDT
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-7 (busy September 14-25) 2008-06-18 17:56:48 PDT
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-7 (busy September 14-25) 2008-06-18 18:01:08 PDT
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-7 (busy September 14-25) 2008-06-18 18:11:09 PDT
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-7 (busy September 14-25) 2008-06-18 18:15:33 PDT
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-7 (busy September 14-25) 2008-06-18 18:27:37 PDT
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-7 (busy September 14-25) 2008-06-18 18:34:56 PDT
Created attachment 325683 [details]
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-7 (busy September 14-25) 2008-06-18 18:41:45 PDT
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-7 (busy September 14-25) 2008-06-18 18:45:56 PDT
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-7 (busy September 14-25) 2008-06-18 18:49:00 PDT
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-7 (busy September 14-25) 2008-06-18 18:58:02 PDT
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-7 (busy September 14-25) 2008-06-18 18:59:52 PDT
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 [:mwargers] (not working for Mozilla) 2008-06-19 05:51:14 PDT
Created attachment 325743 [details] [diff] [review]
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-7 (busy September 14-25) 2008-06-19 09:25:08 PDT
Looks ok to me, but you probably want to ask roc to review the merged version.
Comment 19 Daniel Veditz [:dveditz] 2008-06-20 11:11:03 PDT
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 [:mwargers] (not working for Mozilla) 2008-06-20 12:52:46 PDT
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] 2008-06-23 11:44:04 PDT
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] 2008-07-07 16:53:35 PDT
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 2009-01-05 12:05:08 PST
Comment on attachment 325743 [details] [diff] [review]
branch patch

a=asac for 1.8.0

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