HeapLocker Tool Protects Against Heap-Spray Attacks

As attackers have focused more and more of their energies on exploiting bugs in Web applications, and specifically memory-corruption vulnerabilities, researchers have followed along, trying to find new ways to protect users from these attacks. One of the newer entrants in this field is a tool called HeapLocker, designed to prevent heap-spray attacks.

HeapLockerAs attackers have focused more and more of their energies on exploiting bugs in Web applications, and specifically memory-corruption vulnerabilities, researchers have followed along, trying to find new ways to protect users from these attacks. One of the newer entrants in this field is a tool called HeapLocker, designed to prevent heap-spray attacks.

The HeapLocker tool is the invention of Didier Stevens, a Belgian security researcher who is well-known for his work from earlier this year finding a method to exploit PDFs without a vulnerability. The way that HeapLocker works is by being loaded as a DLL inside of a given application process and then taking away some of the techniques used during heap-spray attacks, which have become a common method for attackers to exploit memory-corruption bugs in various applications.

Heap spraying techniques often are used in conjunction with a buffer overflow vulnerability in a Web application or browser. “With heap spraying, attackers leverage their ability to allocate
arbitrary objects in the heap of a type-safe language, such as
JavaScript, literally filling the heap with objects that contain
dangerous exploit code. In recent years, spraying has been used in many
real security exploits, especially in Web browsers,” Microsoft Research said in a paper on defenses against heap spraying last year.

One of the ways that Stevens’s HeapLocker tool defends against such attacks is by pre-allocating portions of the process heap to prevent exploit code from allocating it.

“Pre-allocating exploitable addresses prevent heap-sprays from planting shellcode at exploitable addresses by removing these addresses from the heap. The heap manager can’t request the virtual pages containing the exploitable addresses for allocation, because they are already allocated. The result is that the heap manager ignores these pages, and thus that a heap-spray will not plant shellcode inside these pages,” Stevens wrote in the documentation for HeapLocker. “It is clear that pre-allocating only works when pages are pre-allocated before the heap-spray is executed. This is why pre-allocating is done when the HeapLocker DLL is loaded inside the process (i.e. at process startup).”

HeapLocker also uses several other techniques for detecting and preventing heap-spraying attacks, including a method that detects the use of a NOP-slide to get to an attacker’s shellcode. 

“Depending on the size of the buffer the
exploit is overwriting, there might be enough space for thousands of NOP
instructions before the shellcode. When a return address is overwritten (or the
execution of the vulnerable program is hijacked by other means), the jump
location does not need to point to the first instruction of the shellcode. It
can point to any of the NOP instructions in the buffer,” The Honeynet Project wrote in an explanation of an attack on one of its honeypots several years ago. “The execution will ‘slide’ down the NOPs and reach the shellcode. The advantage of this technique
is that the attacker can guess the jump location with a low degree of accuracy
and still successfully exploit the program.”

Attackers will use NOP-slides in some situations as a part of a
heap-spray attack, and HeapLocker looks for unusually long NOP-slides as
a way to detect exploitation attempts. Stevens said in a blog post that HeapLocker has some specific applicability in detecting exploit attempts via PDFs.

“When a malicious document performs a heap spray, allocation of private
virtual memory will skyrocket. HeapLocker allows you to set a maximum to
the amount of private virtual memory a process is using. If the maximum is exceeded, HeapLocker will suspend the process and inform the user,” Stevens wrote. “When HeapLocker is loaded inside Acrobat Reader (AcroRd32.exe
process), it will find the PrivateUsageMax setting and start a new
thread inside the Adobe Reader process. During most of its life, this
thread will do nothing (sleep). Every second, it will wake-up and check
the amount of private memory allocated by the process (PrivateUsage). If
this amount is equal to or larger than the maximum value specified in
PrivateUsageMax, the thread will suspend all other threads in the
process and display a message box to the user.”

The user then has the option of either terminating the offending process or allowing it to continue.

Stevens stressed in his release notes for HeapLocker that the tool is a beta release and is still experimental. However, he said he has tested it against a number of applications, including Reader, Firefox and Internet Explorer, without any crashes.

Suggested articles