Nozzle and BuBBLE: a trick to JUMP them!

It is a busy time for me and as you see I rarely find time to write on my own blog, but as promised in the past I'll keep on posting some of my notes. Today, for example, I want to stare a nice trick to bypass Noozle and (theoretically) Bubble; two of the most used anti heap spray techniques. Both of the techniques aim to block the "Heap Spray payload delivering". While Noozle recognizes a sprayed payload and block it, Bubble blocks the execution of the payload by messying up the memory.

Lets start to keep a quick and dirty look into the "Heap Spray Payload Delivery Technique". The following image shows how the payload is delivered through the "spray" technique.
Payload Delivering technique: Heap Spray (From Microsot Noozle paper)

The attacker delivers to the target machine a significant number of payloads composed by a NOP sequence (white in the picture) and a final Shellcode (red in the picture). In order to guarantee high performances the kernel allocates memory randomly (ASLR) BUT in organized and atomic blocks.  Dependining on the memory blocks size it happens to have contiguous payloads.  Once the payloads have loaded into the memory the attacker needs to "fire" one of them by pointing EIP to the top-level addressese (NOP) which will eventually take the CPU to execute the desired Shellcode. 

A full attack scenario follows three main steps:
  1. Spray the Heap. Dinamic memory allocation. Fiilling memory with NOP+Shellcode
  2. Trigger the bug. Firing UP the bug to get a pointer.
  3. Control \xEIP to point to the Heap. Making the pointer "pointing" to the memory heap.
One of the most classic way to Spray the heap is to use scripting laguage such as: javascript for spraying browsers or  PDF readers, VBA macros for spraying Microsoft Office suite, ActionsScriptins for spraying Adobe Flash, etc...  One of the most famous (IE6/IE7) script used by attacker all around the world is the following one (I don't know who the author is)

Spray Heap commonly used scripts, from spray2.html (exploitdb)

The anonymous script will produce a heap layout like the one showed in the next picture where  the big yellow section (in the bottom of the memory graphic visualization)  represents the contiguous payload (NOP+Shellcode) just allocated in the memory  (memory array variable in the script):


 
An example of how to trigger the payload generated by the anonymous script, using SEH chain  could be the following:
Example of Payload using SEH chain technique. Add NOPs in the first JUNK section to have more chances to get it.

 A wrong access to the RET address  (\xff\xff\xff\xff) raises the SEHandler which points directly to the memory heap (which is randomized but always on top of the stack ... top = lower addresses...) where is located the payload. From the attacker prespective it is enough to find out a NOP in the memory heap. The NOP sleed will take the CPU to execute the desired payload.
 
According to the paper: "Noozle: A Defense Against Heap-spraying Code Injection Attacks" by Paruj Ratanaworabhan et Al. it possible to exploits the pattern used by memory heap sprayers against themeselves. Common "sprayers" (like the script above) allocte high memory content, one close to the other, filled by NOPs and Sellcodes.

Noozle system architecture, From Noozle paper by Microsoft
The previous image represents the Nozzle architecture. Noozle parses and detects memory alloctions before letting them free in the Browser heap. This security layer introduced in IE8 does not reduce the overall process speed and it's totally transparent to the user. If the Noozle's detectors find a payload according to the described pattern, the running script execution is blocked. Contrary if not patterns have detected the content is freely available to the application heap.
 
Another gret example of how to prevent  memory heap spraying implemented on Mozilla Firefox is called BuBBLE. Introduced by Francesco Gadelata et Al in 2010 it changes the way javascript writes strings in the memory. The following image shows what a delivered payloads becomes after BuBBLE messed up with it

BuBBLE memory transformation (From Bubble Paper, ACM)

 
 
Aim of this contromeasure is to change the way javascript strings are dinamically allocated in the memory. As the image shows it gets hard from the attacker to address the exact point in the heap since NOP chain is interrupted by BuBBLE.

Both of these techniques are very effective in modern browsers, but what if do we introduce smaller payloads within further jump instructions? In other words; what if do we add a "jump to a further small payload" in addition to the NOPs chain ?
 
The following image shows an example of this trick. The delivered payload -- which uses a ROP chain to bypass DEP/Nx protection-- bypasses Nozzle detectors since the NOPs chain is reduced and jump statements have used. I decided to introduce ROP chain in this example just to let you know the techniques are componible and can be used toghether. For more information about ROP here.
 
Example of possible delivered payload to bypass Noozle
 
 
 This technique is about reducing the payload size and the number of NOPs in memory. Splitting the payload into multiple smaller payloads chained together through a forward JUMP. Statistically speaking the most probable address in which to JUMP is on \0x0c0c0c0c. Why this is the most "probable" address is not scope of this post. I might have time to describe the most probable addresses (\0x06060606, \0x08080808, \0x09090909) in future posts.
 
In this post another great example on how "security" follows "hacking" and on how security following hacking failed and will fail again. I do believe that Security should prevent hacking and not following it; more research on how to prevent Heap Spraying Technique is needed.