[Webkit-unassigned] [Bug 21245] New: windows.open()+windows.close() memory corruption

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21245

           Summary: windows.open()+windows.close() memory corruption
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://skypher.com/SkyLined/Repro/Chrome/open+close%20me
                    mory%20corruption/Nightly.html
        OS/Version: Windows Vista
            Status: NEW
          Severity: Critical
          Priority: P1
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: skylined at chromium.org


Opening and immediately closing windows in quick succession seems to be an easy
way to make Google Chrome and Apple Safari create large amounts of USER and GDI
objects and eventually causes memory corruption. The end result varies every
time I run the PoC; mostly it is complete corruption of registers, including
EIP and ESP. I'm not sure if the objects have anything to do with the memory
corruption - it may be an unrelated side effect. I noticed that the number of
USER and GDI objects can get pretty high while running the PoC; several
thousand. According to
http://msdn.microsoft.com/en-us/library/ms725486(VS.85).aspx and
http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx, there are two a
registry key that limit the number of USER and GDI objects a process can
create; the values on my Vista x64 test machine are 10,000 for both. However, I
have not seen this limit being reached during any of my tests. Also, the number
of objects at the time of the crash seems to vary. I can't see this being the
cause of the crash.

Since both browsers crash in a completely different ways every time I run the
PoC, I've omitted a stack dump.

Repro for Chrome:
<SCRIPT>
        setInterval("window.open('javascript:window.close()');", 1);
</SCRIPT>
http://skypher.com/SkyLined/Repro/Chrome/open+close%20memory%20corruption/repro.html

For Safari 3.0 it seems to be easier to trigger this with a small window, which
is why I have create a separate repro that gives you time to resize the window
before you start it:
http://skypher.com/SkyLined/Repro/Chrome/open+close%20memory%20corruption/Safari.html

On my XPsp3 test VM with Safari 4.0 (528.1.1) and WebKit Nightly r36882
(september 25th), it does not seem to trigger with the above repro. I think
I've found a way to do so using this:
<SCRIPT>
        while (true) try {
                window.open('javascript:close()');
        } catch (e) {}
</SCRIPT>
http://skypher.com/SkyLined/Repro/Chrome/open+close%20memory%20corruption/Nightly.html
I am not sure if this is the same issue: this opens up ~120 Safari windows,
uses quite a bit of CPU for a while and then either dies or closes all but the
first window. I've tried to run it under windbg, but I get this message as soon
as I have ~120 windows open:
Localizable string "localized string not found" not found in strings table
"Localizable" of bundle CFBundle 0143F730 <C:\Program
Files\Safari\Safari.resources> (DLL, loaded).eax=00000001 ebx=00000000
ecx=7c8137ed edx=7c97d600 esi=7c90de50 edi=00000001
eip=7c90e4f4 esp=0012dc10 ebp=0012dd0c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!KiFastSystemCallRet:
7c90e4f4 c3              ret
If I try to continue the process, I get this:
0:000> gn
       ^ No runnable debuggees error in 'gn'
...which is odd because there are still Safari windows open.

I've tried to use windbg as a post-mortem/JIT debugger, but nothing happens.
I've seen that before when the stack in the process is exhausted or corrupt,
causing the exception handler to fail completely. The end result is that I have
not a clue what the problem is. It may be easier to track it down in
Chrome/Safari 3.0 then in Nightly, but I'll leave that to you.

For Safari, the memory corruption may be controlable and allow an attacker to
execute arbitrary code with the priviliges of the user running the browser. For
Chrome, the same applies but the sandbox mitigates the risk of code execution;
an attacker would only be able to run code in the sandbox, which gives him/her
very limited access to the system.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.