Secunia Research has discovered a vulnerability in Mozilla Firefox 1.5
branch, which can be exploited by malicious people to compromise a
The vulnerability is caused due to an memory corruption error within
the handling of simultaneously happening XPCOM events. This may be
exploited to execute arbitrary code on a user's system when a malicious
website is visited.
We have confirmed the vulnerability in versions 220.127.116.11, 18.104.22.168,
22.214.171.124, and 126.96.36.199 on Windows and version 188.8.131.52 on Linux. The 1.0.x
branch does not seem affected.
I've included a PoC (Final_Crash_PoC.zip) that crashes the browser.
Unpack the files, open 1.htm, and follow the directions.
We don't know the exact location of the error(s), but I've included
some gdb output from the crash and IDA output below.
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:184.108.40.206) Gecko/20060508
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208891712 (LWP 7295)]
0x083dd558 in nsReadingIterator<unsigned short>::advance ()
#0 0x083dd558 in nsReadingIterator<unsigned short>::advance ()
#1 0x083ddda3 in nsReadingIterator<unsigned short>::advance ()
#2 0x0072e31f in nsTimerImpl::Fire () from /usr/lib/firefox/libxpcom_core.so
#3 0x0072e37a in handleTimerEvent () from /usr/lib/firefox/libxpcom_core.so
#4 0x0072ac53 in PL_HandleEvent () from /usr/lib/firefox/libxpcom_core.so
#5 0x0072aba6 in PL_ProcessPendingEvents ()
#6 0x0072c1d3 in nsEventQueueImpl::CheckForDeactivation ()
#7 0x081ef5c0 in XmlInitUnknownEncodingNS ()
#8 0x00630907 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#9 0x0060c74b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0x0060e1d2 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#11 0x0060e47f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#12 0x047b66a7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x081ef864 in XmlInitUnknownEncodingNS ()
#14 0x08639b78 in nsXPTCVariant::Init ()
#15 0x0807af44 in ?? ()
#16 0x08e73848 in ?? ()
#17 0xb7f1e2b0 in ?? ()
#18 0x00000000 in ?? ()
(gdb) i r
eax 0x696c7070 1768714352
ecx 0x47f667b3 1207330739
edx 0x745f7365 1952412517
ebx 0x415b3 267699
esp 0xbff128d8 0xbff128d8
ebp 0xbff129ac 0xbff129ac
esi 0x0 0
edi 0x3 3
eip 0x83dd558 0x83dd558
eflags 0x10293 66195
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x/i $eip
0x83dd558 <_ZN17nsReadingIteratorItE7advanceEi+733304>: mov 0x24(%edi),%edx
As mentioned in the PoC, program flow is sometimes directed to a
location in firefox.exe on Windows that allows code execution. The
following IDA output from Mozilla Firefox 220.127.116.11 shows this location:
.text:00552660 var_C = dword ptr -0Ch
.text:00552660 var_8 = dword ptr -8
.text:00552660 var_4 = dword ptr -4
.text:00552660 push ecx
.text:00552661 push ecx
.text:00552662 push ebx
.text:00552663 push ebp
.text:00552664 push esi
.text:00552665 mov ebx, ecx
.text:00552667 call sub_5445F4
.text:0055266C lea ebp, [ebx+0D8h]
.text:00552672 mov [esp+14h+var_8], eax
.text:00552676 mov esi, [ebp+0]
.text:00552679 test esi, esi
.text:0055267B jz short @exit
.text:0055267D push edi
.text:0055267E loc_55267E: ; CODE XREF: sub_552660+69j
.text:0055267E cmp [ebx+14h], esi
.text:00552681 jnz short loc_552689
.text:00552683 mov [ebx+0DCh], ebp
.text:00552689 loc_552689: ; CODE XREF: sub_552660+21j
.text:00552689 mov eax, [esi+3Ch]
.text:0055268C lea edi, [esi+0Ch] ; // EDI = ptr to user-controlled data
.text:0055268F mov [esp+18h+var_4], eax
.text:00552693 mov eax, [edi] ; // EAX = 4 user-controlled bytes (unicode)
.text:00552695 test eax, eax
.text:00552697 jz short loc_5526B4 ;
.text:00552699 mov ecx, [eax] ; // ECX = user-controlled address
.text:0055269B push eax
.text:0055269C call dword ptr [ecx+18h] ; // calling user-controlled code
.text:0055269C ; // (normally calls xpcom_core.dll 0x6033D6FB)
The Common Vulnerabilities and Exposures (CVE) project has assigned
CVE-2006-3113 for the vulnerability.
We have reserved SA19873 for the vulnerability. Please let us know when
you expect to issue an updated version and keep us updated on your
Created attachment 226776 [details]
In a debug build I crash (so far) in nsGlobalWindow::RunTimeout or nsGlobalWindow::SuspendTimeouts, in both cases iterating over mTimeouts when it hits a pointer to a deleted (0xdddddddd on windows) nsTimeout.
I can *easily* reproduce this on both Win32 and Linux in builds that do *not* have the fix for bug 320982, but in builds with that fix I have not yet been able to reproduce this yet. Dan, and others, did you see this crash with builds from later than the 16th this month when the fix for bug 320982 got checked in?
Same here, once I updated my 1.8 tree with the patch for bug 320982 I could no longer reproduce this. Yay!
Allright, marking WORKSFORME as this doesn't appear to be a problem in builds containing the fix for bug 320982.
Sorry for reopening, but I'd rather not have a critical security bug "WFM" when we know a specific patch for it.
*** This bug has been marked as a duplicate of 320982 ***
Actually "duplicate" will mess up tracking of security exploits, too.
I applied Olli's 1.8.0-branch patch from Bug 320982 and verified that it fixes this bug.
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
rv:18.104.22.168) Gecko/20060626 Firefox/22.214.171.124, no crash with PoC.