UfPBCtrl ActiveX Remote Code Execution

An advisory has been posted on most of the security sites regarding the Trendmicro's Internet Security Pro 2010 product. It is on the subject of a vulnerability in the ActiveX control UfPBCtrl's function extSetOwner. This particular function takes one argument as the input and treats that a pointer to memory location. This causes the vulnerability as there are no prior checks that are done before the program starts using the pointer that has been passed to it. Malicious users can take advantage of this and can pass their own pointers which they have already allocated elsewhere in the memory. This can basically be achieved by the means of heap spraying. All the malicious user does is spray the memory with huge chunks of nop slide followed by the shellcode and then reference a memory address that points to the address of the shellcode (pass the memory address as argument to the function). More on the vulnerability in this advisory by Abysssec here. This blog post assumes that the reader is aware of basic Heap Spraying techniques.

As detailed in the advisory the vulnerable portion of the control is as below.

The parameter that is passed to the vulnerable method is taken into EAX register and is added by 4. After which the content of the EAX register [EAX] (EAX should actually contain certain valid memory address) is moved into ECX. It is visible in the third instruction of the screenshot that ECX is being called without any proper checking. So the vulnerable method would be called like,

exploit.extSetOwner(unescape(%u7190%u8979))

where the argument that is passed to the function is a valid address that inturn refers to the address in the memory where our shellcode is already heap sprayed. In order for this exploit to work the malicious user has to find himself a pattern within the memory that references the heap sprayed portion in the memory. As with the exploit that is available publicly a large nop slide + shellcode is sprayed to memory. Directing the execution to the nopslide + shellcode is fairly simple. Quickly if we search using ollydbg (for patterns) in memory we can find a memory location 7DD148F3. That belongs to MSHTML's address space. So if we have to pass this address to the vulnerable function we will have to modify the exploit a little bit. If we pass the argument as unescape('%u48F3%u7DD1') our exploit will work promptly. This is because the address that we have just passed will refer to 0A0A0A06 as seen in the screenshot below.

But the code says that EAX will be added by 4 and then the content of EAX will be moved to ECX register. So we will have to subtract 4 from our address which will make it to be 7DD148EF. Hence the final exploit code will turn into unescape('%u48EF%u7DD1'). Now when content of EAX is moved into ECX the register will take the figures as shown below.

As you can see here that the content of the EAX+4 (7DD148F3) is moved into ECX. ECX now holds the little endian format of 0A0A0A06. When we follow the memory location referenced by ECX we can see the nop slide clearly followed by the shell code.

And now when the program slides into CALL ECX instruction the nop slide will be executed followed by the shellcode which we can see clearly in stack that the shellcode simply calls CALC.EXE.

That clearly is a very serious vulnerability. The vendor has provided a hotfix for the this vulnerability. To keep yourself safe either set the killbit for this control or apply the hotfix provided by the vendor. The latter is the best option.

binaryhax0r