This function
call ends up looking at the assembly level for ???call [object-pointer]+0x8???. Seems
okay from the IE perspective, right? After all, we don??™t want to leak memory even if the
HTML is busted. But now let??™s look at the assembly equivalent of what I just described.
In the display that follows, the pageheap flag is enabled, which initializes all memory to
0xc0. Anytime you see 0xc0, you know that memory was not initialized before use.
Here??™s what the crash looks like in the debugger at the point of the access violation:
(f8c.220): Access violation - code c0000005 (!!! second chance !!!)
eax=c0c0c0c0 ebx=056a6ae8 ecx=075a9608 edx=7c97c080 esi=075a9130 edi=00000000
eip=7c508666 esp=0013e59c ebp=0013e5b8 iopl=0 nv up ei ng nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\javaprxy.dll -
javaprxy+0x8666:
7c508666 8b08 mov ecx,[eax] ds:0023:c0c0c0c0=????????
We see that eax is loaded with uninitialized memory, which is not surprising since the
second phase of initialization was never called. The other registers look okay, but ecx is
about to be filled with the contents of memory where eax points.
Pages:
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665