Last Comment Bug 583077 - (CVE-2010-3179) Buffer overflow due to uniscribe failure on long text runs
(CVE-2010-3179)
: Buffer overflow due to uniscribe failure on long text runs
Status: RESOLVED FIXED
[sg:critical?] trunk fixed by 553963 ...
:
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Windows XP
: P5 critical with 1 vote (vote)
: ---
Assigned To: Jonathan Kew (:jfkthame)
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 553963
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-29 14:05 PDT by Alex Miller
Modified: 2016-09-19 01:01 PDT (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.11+
.11-fixed
.14+
.14-fixed


Attachments
41414141 is written to the call stack. (47.88 KB, image/png)
2010-07-29 14:08 PDT, Alex Miller
no flags Details
Testcase (consumes lots of memory; crashes vulnerable versions of Firefox) (593 bytes, text/html)
2010-07-29 14:10 PDT, Alex Miller
no flags Details
patch, v1 - avoid uniscribe failure on long text runs (5.61 KB, patch)
2010-08-26 03:11 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
dveditz: approval1.9.2.11+
dveditz: approval1.9.1.14+
Details | Diff | Splinter Review

Description Alex Miller 2010-07-29 14:05:02 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

When giving document.write() a MASSIVE message, a buffer overflow occurs and writes data to the Call Stack, eventually causing the EIP to be manipulated by Javascript.

Reproducible: Always

Steps to Reproduce:
1. Open a debugger (I used Debuggy)
2. Visit the web page
3. In the debugger, check the call stack a couple of times
Actual Results:  
I found that 41414141 was written to the call stack, meaning that after normal  browser operations, the EIP becomes 41414141 and that obviously leads to code execution, if you change the EIP to point to your shellcode.

Expected Results:  
The browser should have frozen or crashed.

This was ONLY tested against windows 7 on an x86 single core processor, results may vary.
Comment 1 Alex Miller 2010-07-29 14:08:10 PDT
Created attachment 461337 [details]
41414141 is written to the call stack.
Comment 2 Alex Miller 2010-07-29 14:10:53 PDT
Created attachment 461339 [details]
Testcase (consumes lots of memory; crashes vulnerable versions of Firefox)
Comment 3 Damon Sicore (:damons) 2010-08-03 13:12:43 PDT
Smaug, can you take a look?
Comment 4 chris hofmann 2010-08-03 18:07:51 PDT
crash report from a windows vm using the test case in comment 2.

http://crash-stats.mozilla.com/report/index/bp-4f69071c-65f6-4e1f-8ed4-2b6362100803

0  	xul.dll  	TextRunWordCache::FinishTextRun  	 gfx/thebes/gfxTextRunWordCache.cpp:456
1 	xul.dll 	TextRunWordCache::MakeTextRun 	gfx/thebes/gfxTextRunWordCache.cpp:695
2 	xul.dll 	MakeTextRun 	layout/generic/nsTextFrameThebes.cpp:446
3 	xul.dll 	BuildTextRunsScanner::BuildTextRunForFrames 	layout/generic/nsTextFrameThebes.cpp:1807
4 	xul.dll 	BuildTextRunsScanner::FlushFrames 	layout/generic/nsTextFrameThebes.cpp:1238
5 	xul.dll 	BuildTextRuns 	layout/generic/nsTextFrameThebes.cpp:1172
6 	xul.dll 	nsTextFrame::EnsureTextRun 	layout/generic/nsTextFrameThebes.cpp:2040
7 	xul.dll 	nsTextFrame::Reflow 	layout/generic/nsTextFrameThebes.cpp:6293
8 	xul.dll 	nsLineLayout::ReflowFrame 	layout/generic/nsLineLayout.cpp:853
9 	xul.dll 	nsBlockFrame::ReflowInlineFrame 	layout/generic/nsBlockFrame.cpp:3722
10 	xul.dll 	nsBlockFrame::DoReflowInlineFrames 	layout/generic/nsBlockFrame.cpp:3517
11 	xul.dll 	nsBlockFrame::ReflowInlineFrames 	layout/generic/nsBlockFrame.cpp:3371
12 	xul.dll 	nsBlockFrame::ReflowLine 	layout/generic/nsBlockFrame.cpp:2467
13 	xul.dll 	nsBlockFrame::ReflowDirtyLines 	layout/generic/nsBlockFrame.cpp:1907
14 	xul.dll 	nsBlockFrame::Reflow 	layout/generic/nsBlockFrame.cpp:1009
15 	xul.dll 	nsBlockReflowContext::ReflowBlock 	layout/generic/nsBlockReflowContext.cpp:310
16 	xul.dll 	nsBlockFrame::ReflowBlockFrame 	layout/generic/nsBlockFrame.cpp:3090
17 	xul.dll 	nsBlockFrame::ReflowLine 	layout/generic/nsBlockFrame.cpp:2412
18 	xul.dll 	nsBlockFrame::ReflowDirtyLines 	layout/generic/nsBlockFrame.cpp:1907
19 	xul.dll 	nsBlockFrame::Reflow 	layout/generic/nsBlockFrame.cpp:1009
20 	xul.dll 	nsContainerFrame::ReflowChild 	layout/generic/nsContainerFrame.cpp:738
21 	xul.dll 	nsCanvasFrame::Reflow 	layout/generic/nsCanvasFrame.cpp:487
22 		@0xad2c3f
Comment 5 chris hofmann 2010-08-03 18:25:11 PDT
need to look deeper to figure out if the crash results in a consistent stack trace, but looks like we see the signature TextRunWordCache::FinishTextRun in the wild between 10-28 times a day over the last month, and with possible increased frequency in 4.0b

checking --- TextRunWordCache::FinishTextRun 20100722-crashdata.csv
found in: 4.0b1 3.6.7 3.7a5 3.6.6 3.5.11 3.5.10
release total-crashes
              TextRunWordCache::FinishTextRun crashes
                         pct.
all     677113  28      4.1352e-05
4.0b1   21327   15      0.000703334
3.6.7   493844  9       1.82244e-05
3.7a5   583     1       0.00171527
3.6.6   64993   1       1.53863e-05
3.5.11  30481   1       3.28073e-05
3.5.10  6388    1       0.000156544

os breakdown
TextRunWordCache::FinishTextRunTotal 28
Win5.1  0.32
Win6.0  0.07
Win6.1  0.54
Mac10.4 0.04
Mac10.5 0.04
Mac10.6 0.00
Lin2.4  0.00

domains of sites
   5 //
   3 http://www.youtube.com

   1 http://www.youtube.com/watch?v=lP9VBAISXT8&feature=related
   1 http://www.youtube.com/watch?v=W-WKYIgGBbU&feature=popular
   1 http://www.youtube.com/watch?v=KY4Pxg07SIY&feature=related
 
   1 http://www.youjizz.com
   1 http://www.shqiperia.com
   1 http://www.kaskus.us
   1 http://www.google.com.eg
   1 http://www.google.com
   1 http://www.facebook.com
   1 http://www.ensa-agadir.ac.ma
   1 http://www.eenadu.net
   1 http://www.4shared.com
   1 http://vozforums.com
   1 http://vnexpress.net
   1 http://vkontakte.ru
   1 http://uvatoolkit.com
   1 http://static.ak.facebook.com
   1 http://new.el-ahly.com
   1 http://microhardware.org
   1 http://mail.canhtoan.com:3000
   1 http://consumersupport.lenovo.com

   1 http://consumersupport.lenovo.com/vn/en/driversdownloads/drivers_list.aspx?categoryid=358677


   1 http://9downsoft.com:2082

   1 http://9downsoft.com:2082/frontend/x3/backup/dosqlupload.html
Comment 6 Olli Pettay [:smaug] 2010-08-04 06:22:07 PDT
(In reply to comment #3)
> Smaug, can you take a look?

How strange, I didn't get *any* email about this bug.
I wasn't CC'ed to this, but usually I get email about all sg:* bugs.
Comment 7 Olli Pettay [:smaug] 2010-08-23 05:13:52 PDT
It would be great if someone at least vaguely familiar with textruns would look
at this.
My current guess is that TextRunWordCache::LookupWord somehow puts a "word"
with invalid textrun to deferredwords, but I could be wrong.

Btw, on linux glib seems to abort in this case
GLib-ERROR **: gmem.c:176: failed to allocate 1342177280 bytes
aborting...
Comment 8 Alex Miller 2010-08-23 16:53:50 PDT
(In reply to comment #7)
> It would be great if someone at least vaguely familiar with textruns would look
> at this.
> My current guess is that TextRunWordCache::LookupWord somehow puts a "word"
> with invalid textrun to deferredwords, but I could be wrong.
> 
> Btw, on linux glib seems to abort in this case
> GLib-ERROR **: gmem.c:176: failed to allocate 1342177280 bytes
> aborting...

Well, this was only tested against windows...
Comment 9 Jonathan Kew (:jfkthame) 2010-08-26 03:11:23 PDT
Created attachment 469403 [details] [diff] [review]
patch, v1 - avoid uniscribe failure on long text runs

This is the 1.9.2 equivalent of patch 1 in bug 553963 on trunk. The basic issue is that CopyItemSplitOversize does not handle large items correctly; it calls Uniscribe's ScriptBreak() function with a huge text buffer (42 million chars, in the testcase here), which fails. In a debug build, several assertions get triggered, but in a release build we end up with a textRun in an inconsistent state, leading to invalid array accesses, etc.

On trunk, we're able to avoid the use of ScriptBreak here because the font & text restructuring we've done means that we have cluster information already available at this point, but on 1.9.2 that's not the case. So to fix this in a minimally-disruptive way, I have modified CopyItemSplitOversize to use a "sliding window" onto the entire buffer, analyzing a portion at a time so as to avoid the uniscribe limitation.

With this patch, I can no longer reproduce the crash with this testcase, although the browser does become unresponsive for an extended time while creating the huge string, building the textRun, reflowing, etc. However, with sufficient patience (10 minutes or so on my fast desktop) it successfully displays the entire test page of 42 million chinese characters.

On a memory-constrained system, it's still possible that this kind of test would die with an out-of-memory exception, but that should be a "safe" crash.
Comment 10 Jonathan Kew (:jfkthame) 2010-08-26 03:51:51 PDT
Confirmed that the same patch applies and fixes the equivalent crash on 1.9.1 as well.
Comment 11 John Daggett (:jtd) 2010-08-27 03:43:53 PDT
Comment on attachment 469403 [details] [diff] [review]
patch, v1 - avoid uniscribe failure on long text runs

Looks OK.  The logic in itemizer loop is a tad hairy, I *think* it looks okay but proving that is not a simple exercise.
Comment 12 Jonathan Kew (:jfkthame) 2010-08-29 10:32:12 PDT
We've fixed this issue on trunk in bug 553963, but the earlier branches remain vulnerable; requesting blocking1.9.2 and 1.9.1 as it seems possible this might be exploitable (see initial comments).
Comment 13 Alex Miller 2010-08-29 11:41:22 PDT
(In reply to comment #12)
> We've fixed this issue on trunk in bug 553963, but the earlier branches remain
> vulnerable; requesting blocking1.9.2 and 1.9.1 as it seems possible this might
> be exploitable (see initial comments).

Are new releases running on the patched trunk? I found evidence of memory corruption on Windows 7 running 3.6.8...
Comment 14 Daniel Veditz [:dveditz] 2010-08-30 10:33:21 PDT
No, "trunk" is Firefox 4 nightlies. For the moment, anyway -- we will create a release branch in the near future and "trunk" will then be ongoing development for whatever comes after "Firefox 4"
Comment 15 Jonathan Kew (:jfkthame) 2010-08-31 04:05:22 PDT
Comment on attachment 469403 [details] [diff] [review]
patch, v1 - avoid uniscribe failure on long text runs

Requesting approval to land on 1.9.2 and 1.9.1.

This patch prevents us calling Uniscribe with excessively large buffers, such that it fails and we are left with inconsistent text-runs, leading to invalid memory access and potential memory/stack corruption.

The patch resolves the failure and gives correct, safe behavior with the testcase (effectively a stress-test) here. Automated testing to verify this is difficult as the error condition involves huge strings and textruns, and even when handled correctly we're going to experience an apparent "hang" for several minutes, and could experience an out-of-memory exception + crash. (This is the correct result in the event of an allocation failure inside the Uniscribe calls, for example.)
Comment 16 Daniel Veditz [:dveditz] 2010-08-31 13:30:18 PDT
Calling this one "fixed" for trunk (by bug 553963). Branch fixes are tracked by the custom fields.
Comment 17 Daniel Veditz [:dveditz] 2010-08-31 13:37:02 PDT
Comment on attachment 469403 [details] [diff] [review]
patch, v1 - avoid uniscribe failure on long text runs

Approved for 1.9.2.10 and 1.9.1.13, a=dveditz

Please check this into 'default' on both branches (beware: 'tip' often points at relbranches) and update the status1.9.x fields to the appropriate <version>-fixed status.
Comment 19 Justin Dolske [:Dolske] 2010-09-01 20:24:05 PDT
Is this testable/fuzzable?

Throwing large strings at the browser to see what happens seems to be a common attack, ISTR someone filing a bug on this kind of thing nearly monthly. Usually it's just a harmless OOM/DOS. So it seems a bit surprising this was different and not noticed before, but I'd assume people will continue to probe for problems like this.
Comment 20 Martijn Wargers [:mwargers] (not working for Mozilla) 2010-09-02 00:04:54 PDT
Yes, fuzzing with large strings is crashing all the time for me.
Comment 21 Jesse Ruderman 2010-09-02 00:15:08 PDT
Martijn, any bug reports of yours that we should focus on fixing? ;)
Comment 22 Alex Miller 2010-09-08 18:21:03 PDT
Is this fixed in the 3.6.9 release?
Comment 23 John Daggett (:jtd) 2010-09-08 18:38:32 PDT
(In reply to comment #22)
> Is this fixed in the 3.6.9 release?

"Approved for 1.9.2.10" means it will end up in 3.6.10.
Comment 24 Alex Miller 2010-09-08 18:59:14 PDT
(In reply to comment #23)
> (In reply to comment #22)
> > Is this fixed in the 3.6.9 release?
> 
> "Approved for 1.9.2.10" means it will end up in 3.6.10.

(In reply to comment #23)
> (In reply to comment #22)
> > Is this fixed in the 3.6.9 release?
> 
> "Approved for 1.9.2.10" means it will end up in 3.6.10.

Okay :)
I'm 12, I'm relatively new to the development process of large-scale projects.
Comment 25 Johnathan Nightingale [:johnath] 2010-09-09 07:22:47 PDT
(In reply to comment #24)
> Okay :)
> I'm 12, I'm relatively new to the development process of large-scale projects.

Hey Alex - I meant to say this earlier when you submitted your bug reports - but it's great to have you helping out. Quit apologizing for your age - you're doing just fine.

Has someone introduced you to our IRC network? You might find it interesting/helpful to hang out there, watch the project go by - it's where we coordinate most things.

I'm abusing bugzilla a little by using it as a chat forum here - if you have any questions or need help with anything, please feel free to email me:

johnath at mozilla dot com
Comment 26 Al Billings [:abillings] 2010-09-20 17:48:40 PDT
(In reply to comment #5)
> need to look deeper to figure out if the crash results in a consistent stack
> trace, but looks like we see the signature TextRunWordCache::FinishTextRun in
> the wild between 10-28 times a day over the last month, and with possible
> increased frequency in 4.0b


Is this getting a consistent stack trace? Consistent enough for us to know if we've fixed this running the giant scary attached web page? :-)
Comment 27 Daniel Veditz [:dveditz] 2010-09-28 13:26:07 PDT
This was fixed on trunk in bug 553963
Comment 28 Mike Beltzner [:beltzner, not reading bugmail] 2010-10-23 09:15:16 PDT
Any reason why we haven't opened this up yet?
Comment 30 Jesse Ruderman 2010-10-23 14:26:17 PDT
Given bug 606714, maybe we shouldn't disclose this yet.
Comment 32 Alexandra (retired) 2010-11-21 07:51:10 PST
Hate to break bad news. I think Mozilla is on the right track by giving kids 3K (Mozilla should be doing that each month imho) But this "bug" is a duplicate from unicode stack overflow: Bug 504342. Found by Andrew Haynes & Simon Berry-Byrne in 2009. I say duplicate, but actually it's copied pasted since it's exactly the same.
Comment 33 Alex Miller 2010-11-21 09:40:40 PST
(In reply to comment #32)
> Hate to break bad news. I think Mozilla is on the right track by giving kids 3K
> (Mozilla should be doing that each month imho) But this "bug" is a duplicate
> from unicode stack overflow: Bug 504342. Found by Andrew Haynes & Simon
> Berry-Byrne in 2009. I say duplicate, but actually it's copied pasted since
> it's exactly the same.

What? I actually wrote the testcase myself... Also, doesn't this count as a separate vulnerability because it exploits a different part of Firefox?

Also, according to http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ bug 504342 isn't exploitable.
Comment 34 Alexandra (retired) 2010-11-21 16:39:50 PST
Don't listen to Mike Shaver. Just kidding. No seriously, don't listen to him. Joking. Maybe. Shaver's theorem goes like; We've seen no exploits, so it isn't exploitable. A joke, of course. But he wrote it. Well, lot are exploitable. Not easily, but requires a lot of work.

No it's not a different vulnerability, people just weren't paying attention.

One simply writes a string beyond an array bound, off into stack space where one can control it. So it basically is an out of bounds error on the looks of it: 

mItems[aIndex+1];

// out of bounds possibility.
Comment 35 Hiep Le 2016-09-19 01:01:14 PDT
need to look deeper to figure out if the crash results in a consistent stack trace, but looks like we see the signature TextRunWordCache::FinishTextRun in the wild between 10-28 times a day over the last month, and with possible increased frequency in 4.0b

checking --- TextRunWordCache::FinishTextRun 20100722-crashdata.csv
found in: 4.0b1 3.6.7 3.7a5 3.6.6 3.5.11 3.5.10
release total-crashes
              TextRunWordCache::FinishTextRun crashes
                         pct.
all     677113  28      4.1352e-05
4.0b1   21327   15      0.000703334
3.6.7   493844  9       1.82244e-05
3.7a5   583     1       0.00171527
3.6.6   64993   1       1.53863e-05
3.5.11  30481   1       3.28073e-05
3.5.10  6388    1       0.000156544

os breakdown
TextRunWordCache::FinishTextRunTotal 28
Win5.1  0.32
Win6.0  0.07
Win6.1  0.54
Mac10.4 0.04
Mac10.5 0.04
Mac10.6 0.00
Lin2.4  0.00

domains of sites
   5 //
   3 http://www.youtube.com

   1 http://www.youtube.com/watch?v=lP9VBAISXT8&feature=related
   1 http://www.youtube.com/watch?v=W-WKYIgGBbU&feature=popular
   1 http://www.youtube.com/watch?v=KY4Pxg07SIY&feature=related
 
   1 http://www.youjizz.com
   1 http://www.shqiperia.com
   1 http://www.kaskus.us
   1 http://www.google.com.eg
   1 http://www.google.com
   1 http://www.facebook.com
   1 http://www.ensa-agadir.ac.ma
   1 http://www.eenadu.net
   1 http://namchamvinhcuuhn.com/
   1 http://thibanglaixevn.com/
   1 http://nhakhoavietduc.com.vn/
   1 http://vkontakte.ru
   1 http://uvatoolkit.com
   1 http://static.ak.facebook.com
   1 http://new.el-ahly.com
   1 http://microhardware.org
   1 http://mail.canhtoan.com:3000
   1 http://consumersupport.lenovo.com

   1 http://consumersupport.lenovo.com/vn/en/driversdownloads/drivers_list.aspx?categoryid=358677


   1 http://9downsoft.com:2082

   1 http://9downsoft.com:2082/frontend/x3/backup/dosqlupload.html

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