Technical Details

In general, the code causing the overflow error appears as follows : <IFRAME src=file://AAAAAA name ="BBBBBBxx"></IFRAME> , where AAAAAA and BBBBB are Unicode text strings of a strictly -defined length and xx are characters that overwrite the pointer to the virtual function of the object-oriented programming (OOP) object instance located inside the shdocvw.dll library.

The disassembled listing of the vulnerable code is shown in Listing 7.1. Note that specific addresses vary from version to version of the vulnerable application.

Listing 7.1: Disassembled Internet Explorer fragment, ensuring control is passed to shellcode

 7178EC02  8B 08          MOV ECX, DWORD PTR [EAX] 7178EC02                 ; Load the pointer to the table of virtual 7178EC02                 ; functions of some OOP object. After the 7178EC02                 ; overflow occurs, the EAX register will contain 7178EC02                 ; the xx characters located in the tail of the 7178EC02                 ; Unicode string containing the file name. 7178EC04  68 84 7B 70 71 PUSH 71707B84 7178EC04                 ; Push the constant pointer to the stack. 7178EC04 7178EC09  50             PUSH EAX 7178EC09                 ; Push the this pointer to the stack. 7178EC09                 ; The this pointer points to the OOP object 7178EC09                 ; containing the virtual table inside it. 7178EC09 7178ECOA  FF 11          CALL NEAR DWORD PTR [ECX] 7178ECOA                 ; Call the virtual function by the ECX pointer 7178ECOA                 ; (already overwritten with fictitious data). 

 

The double implicit call of the function by the pointer gives the hacker a terrible headache . There is no problem in loading the pointer to the arbitrary memory area into the EAX pointer. It is more difficult to ensure that the pointer to the shellcode resides at that address, which is not known beforehand. How did hackers solve this problem?