634430 - Out of memory control use, when the window contains 100 frames, then they refresh themselves.

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Brandon Sterne (:bsterne)]

Attachment: testcase (crashes Firefox)

Marc Schoenefeld reported the following to [e-mail]:

(I tried the PoC on OSX and didn't get the crash, only the "Stop Script" case he describes below.)


Hi,

with Ffx 3.6.13, there is a suspicious looking crash with navigator.registerProtocolHandler(a,b,c);

It crashes on Mac OSX and Win XP / SP3, automatic crash analysis claims it is exploitable on Windows. Ffx/Linux (only tested Fedora 14/x86_64) doesn't seem to crash, but doesn't react to pressing "Stop Script", so it's DoS here too.

To reproduce:

sh runit.sh
firefox http://127.0.0.1:9000/regframe.html

The files:

regframe loads the exploit page 100 times into an iframe.
register2.html performs the registerProtocolHandler

The analysis:

Windows XP/SP3

(c9c.a14): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004
edi=00000005
eip=7c90120e esp=0587ffcc ebp=0587fff4 iopl=0         nv up ei pl zr na
pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
efl=00000246
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:019> g
(c9c.588): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=07ea0072 ebx=00010000 ecx=0012e6d8 edx=0012e708 esi=07d74928
edi=0012e6d0
eip=003074d7 esp=0012e528 ebp=0012e6d8 iopl=0         nv up ei pl nz ac
pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000
efl=00210216
js3250+0x74d7:
003074d7 6689040e        mov     word ptr [esi+ecx],ax
ds:0023:07ea3000=????

0:000> !MSEC.exploitable
*** ERROR: Module load completed but symbols could not be loaded for
C:\Program Files\Mozilla Firefox\js3250.dll
*** ERROR: Module load completed but symbols could not be loaded for
C:\Program Files\Mozilla Firefox\xul.dll
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at
js3250+0x00000000000074d7 (Hash=0x3f104c57.0x277d1b19)

User mode write access violations that are not near NULL are exploitable.

OSX

firefox-bin(16416,0xa01c1540) malloc: *** mmap(size=143491072) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
firefox-bin(16416,0xa01c1540) malloc: *** mmap(size=286982144) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
firefox-bin(16416,0xa01c1540) malloc: *** mmap(size=239149056) failed
(error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Abort trap

Cheers
Marc

Comment 1

[Brandon Sterne (:bsterne)]

Attachment: iframe content for testcase

Comment 2

[Brandon Sterne (:bsterne)]

Attachment: runit.sh (runs local webserver)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Brandon, this is branch-only?  I don't seem to hit this on Mac trunk...

Comment 4

[Brandon Sterne (:bsterne)]

I'm not sure.  I didn't hit it at all on either 1.9.2 or trunk, but Marc saw the crashes on 1.9.2 so that's how I filed the bug.

Comment 5

[Marc Schoenefeld]

Still dies on OSX , Windows XP SP3 and on some Linux installations (saw reboot with Ffx on Fedora 14). Looks like this bug is missing flags for the other platforms. 

Fwiw, SeaMonkey OSX dies too:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x93e5a156 __kill + 10
1   libSystem.B.dylib             	0x93e5a148 kill$UNIX2003 + 32
2   libSystem.B.dylib             	0x93eec899 raise + 26
3   libSystem.B.dylib             	0x93f029b8 abort + 93
4   libstdc++.6.dylib             	0x96c93fda __gnu_cxx::__verbose_terminate_handler() + 433
5   libstdc++.6.dylib             	0x96c9217a __cxxabiv1::__terminate(void (*)()) + 10
6   libstdc++.6.dylib             	0x96c921ba __cxxabiv1::__unexpected(void (*)()) + 0
7   libstdc++.6.dylib             	0x96c922b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
8   libstdc++.6.dylib             	0x96c92658 operator new(unsigned long) + 101
9   org.mozilla.seamonkey         	0x0019df67 std::vector<unsigned short, std::allocator<unsigned short> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned long, unsigned short const&) + 1541975
10  libsuite.dylib                	0x01765fcf NSGetModule + 63311
11  org.mozilla.seamonkey         	0x005448cc non-virtual thunk to nsPrintSession::Release() + 2888268
12  org.mozilla.seamonkey         	0x00545b0c non-virtual thunk to nsPrintSession::Release() + 2892940
13  org.mozilla.seamonkey         	0x002980ad non-virtual thunk to nsPrintSession::Release() + 84525
14  org.mozilla.seamonkey         	0x002982ca non-virtual thunk to nsPrintSession::Release() + 85066
15  org.mozilla.seamonkey         	0x007fd249 non-virtual thunk to nsPrintSession::Release() + 5741513
16  org.mozilla.seamonkey         	0x00800804 non-virtual thunk to nsPrintSession::Release() + 5755268
17  org.mozilla.seamonkey         	0x0080daf3 non-virtual thunk to nsPrintSession::Release() + 5809267
18  org.mozilla.seamonkey         	0x008120d8 non-virtual thunk to nsPrintSession::Release() + 5827160
19  org.mozilla.seamonkey         	0x00812433 non-virtual thunk to nsPrintSession::Release() + 5828019
20  org.mozilla.seamonkey         	0x00812d9e non-virtual thunk to nsPrintSession::Release() + 5830430
21  org.mozilla.seamonkey         	0x000d1338 std::vector<unsigned short, std::allocator<unsigned short> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned long, unsigned short const&) + 703272
22  org.mozilla.seamonkey         	0x000d5d12 std::vector<unsigned short, std::allocator<unsigned short> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned long, unsigned short const&) + 722178
23  org.mozilla.seamonkey         	0x000596bc std::vector<unsigned short, std::allocator<unsigned short> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned long, unsigned short const&) + 212652
24  org.mozilla.seamonkey         	0x00059a08 std::vector<unsigned short, std::allocator<unsigned short> >::_M_fill_insert(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned long, unsigned short const&) + 213496
25  libxpcom_core.dylib           	0x0109c81d NS_AsyncCopy(nsIInputStream*, nsIOutputStream*, nsIEventTarget*, nsAsyncCopyMode, unsigned int, void (*)(void*, unsigned int), void*) + 1165
26  libxpcom_core.dylib           	0x010b9f3a NS_SetGlobalThreadObserver(nsIThreadObserver*) + 2202
27  libxpcom_core.dylib           	0x0107a4b7 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) + 71
28  org.mozilla.seamonkey         	0x00278041 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) + 467153
29  org.mozilla.seamonkey         	0x0024641d void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) + 263341
30  com.apple.CoreFoundation      	0x97bef4cb __CFRunLoopDoSources0 + 1563
31  com.apple.CoreFoundation      	0x97becf8f __CFRunLoopRun + 1071
32  com.apple.CoreFoundation      	0x97bec464 CFRunLoopRunSpecific + 452
33  com.apple.CoreFoundation      	0x97bec291 CFRunLoopRunInMode + 97
34  com.apple.HIToolbox           	0x9919ee04 RunCurrentEventLoopInMode + 392
35  com.apple.HIToolbox           	0x9919ebb9 ReceiveNextEventCommon + 354
36  com.apple.HIToolbox           	0x9919ea3e BlockUntilNextEventMatchingListInMode + 81
37  com.apple.AppKit              	0x90ab678d _DPSNextEvent + 847
38  com.apple.AppKit              	0x90ab5fce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
39  com.apple.AppKit              	0x90a78247 -[NSApplication run] + 821
40  org.mozilla.seamonkey         	0x00245b48 void std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)) + 261080
41  org.mozilla.seamonkey         	0x008e2cb7 JNIEnv_::CallStaticObjectMethod(_jclass*, _jmethodID*, ...) + 450519
42  org.mozilla.seamonkey         	0x000081f8 XRE_main + 9432
43  org.mozilla.seamonkey         	0x00003ca3 start + 2131
44  org.mozilla.seamonkey         	0x00003552 start + 258
45  org.mozilla.seamonkey         	0x00003479 start + 41

Comment 6

[Marc Schoenefeld]

It does not die immediately, sometimes after clicking "Continue" on "Unresponsive script"

Comment 7

[Marc Schoenefeld]

Any progress here?

Comment 8

[Daniel Veditz [:dveditz]]

With Firefox 46 on Mac OS X the testcase got up to 34Gb (virtual, my machine is only 16Gb) before I killed it. Another run got up to 63Gb before the OS made me kill it. No "slow script" dialog even though Firefox was completely locked up. I do get "allocation errors" on the  a = a +a +a  line.

If I change that line to a += 'a'; then it spins up the CPU for several seconds and gets back to normal. Without the allocation failures it's getting all the way through the 1024 registerProtocolHandler calls in each frame (all unique registrations) instead of fewer than 20 loops per frame.

This is still a DoS but it doesn't need to be hidden. The DOS-yness appears to be due to the string concatenations which we have other bugs on.

Comment 9

[travis knapp-prasek]

Just chiming in here as it is possible to "crash" Firefox and Chrome based browsers using registerProtocolHandler, by repeatedly calling it in an infinite while loop.

Comment 10

[Valentin Gosu [:valentin] (he/him)]

If I replace the navigator.registerProtocolHandler with window.addEventListener("load", () => { console.log("http://127.0.0.1:9000/karl.html?%s&"+a)}) then I get the same out of control memory use.
I think the problem here is that the window contains 100 frames that each allocate a lot of memory, then they refresh themselves.

Since registerProtocolHandler isn't a critical part of the testcase - I think this is not a networking issue.

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Thanks valentin. Agreed - not networking.