Secunia Research has discovered a vulnerability in Mozilla Firefox 1.5 branch, which can be exploited by malicious people to compromise a user's system. 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 22.214.171.124, 126.96.36.199, 188.8.131.52, and 184.108.40.206 on Windows and version 220.127.116.11 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. GDB output: ----------- Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:18.104.22.168) Gecko/20060508 Firefox/22.214.171.124 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208891712 (LWP 7295)] 0x083dd558 in nsReadingIterator<unsigned short>::advance () (gdb) bt #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 () from /usr/lib/firefox/libxpcom_core.so #6 0x0072c1d3 in nsEventQueueImpl::CheckForDeactivation () from /usr/lib/firefox/libxpcom_core.so #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 126.96.36.199 shows this location: .text:00552660 sub_552660 .text:00552660 var_C = dword ptr -0Ch .text:00552660 var_8 = dword ptr -8 .text:00552660 var_4 = dword ptr -4 .text:00552660 .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 .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 .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 progress.
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:188.8.131.52) Gecko/20060626 Firefox/184.108.40.206, no crash with PoC.