NULL Pointer Exploitation Causes Concern

Some news is in circulation regarding a recently disclosed (and patched) vulnerability in Adobe’s Flash. The attack used dereferenced NULL pointers, which were believed to be very hard to exploit.

The findings were first revealed in a paper called “Application-Specific Attacks: Leveraging the ActionScript Virtual Machine,”(pdf) by Mark Dowd. The paper described a new technique for causing exploitable memory corruption vulnerability in Adobe’s Flash. Whilst the technique has targeted the ActionScript Virtual Machine for Win32/Intel platform, it’s understood that the attack could be carried out on any other platforms where Flash is available. The real question is whether this attack can be more generic to target dereferenced NULL pointers in general!

It is possible to do so, but it’s not that easy. There are certain conditions an exploit of this type has to satisfy before reaching the ultimate goal. Dowd used some wacky techniques to inject malicious ActionScript byte code into Flash runtime (basically by crafting an SWF with something to trigger the vulnerability and point the execution to another loaded-in-memory part of the file that had the malicious content). Then he forced malloc() to fail by trying to allocate some huge memory chunk. When malloc() failed, it returned NULL.

(OK, at this step a program trying to access a NULL pointer would basically crash, and something to check for malloc() return value is necessary to prevent that crash.)

In this case, Flash didn’t check for malloc() failure and did some pointer arithmetic operation to add the value of the pointer (NULL here) to some offset. Now, this “offset” was controllable, and this is where Dowd had preloaded his malicious content. (Don’t get too excited, folks. There were quite a few other conditions that Dowd’s exploit had to meet before loading his payload. But I’m eliminating a lot of details to present the overall picture). So now we have a pretty successful and reproducible exploit on Flash ActionScript VM. It even bypassed Vista’s ASLR because Vista’s Flash was compiled with the runtime security bit off.

Now, scaling this attack against native code is more difficult in spite of the success it had against ActionScript VM. We will still be looking for a controllable offset and a place to preload our payload. Nevertheless, it is still a neat discovery when taking into consideration the level of complexity needed to load the malicious payload.

This discovery reflects a trend that it is possible to circumvent runtime security countermeasures such as ASLR and the like by targeting other environments with higher privileges running on top of the native platform. And if you’re involved in any secure development lifecycle, you’d better go and check your code!

Tags: exploit, vista, vulnerability, Zero-Day