342507 - (sa19873) Memory corruption with simultaneous events (SA19873, CVE-2006-3113)

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Daniel Veditz [:dveditz]]

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 1.5.0.1, 1.5.0.2,
1.5.0.3, and 1.5.0.4 on Windows and version 1.5.0.4 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:1.8.0.4) Gecko/20060508
Firefox/1.5.0.4

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 1.5.0.4 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.

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: PoC (zip)

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[Johnny Stenback (:jst)]

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?

Comment 4

[Daniel Veditz [:dveditz]]

Same here, once I updated my 1.8 tree with the patch for bug 320982 I could no longer reproduce this. Yay!

Comment 5

[Johnny Stenback (:jst)]

Allright, marking WORKSFORME as this doesn't appear to be a problem in builds containing the fix for bug 320982.

Comment 6

[Daniel Veditz [:dveditz]]

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 ***

Comment 7

[Daniel Veditz [:dveditz]]

Actually "duplicate" will mess up tracking of security exploits, too.

Comment 8

[Daniel Veditz [:dveditz]]

I applied Olli's 1.8.0-branch patch from Bug 320982 and verified that it fixes this bug.

Comment 9

[Jay Patel [:jay]]

v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
rv:1.8.0.5) Gecko/20060626 Firefox/1.5.0.5, no crash with PoC.