Tuesday, May 1st, 2007

Heap Feng Shui in JavaScript and HeapLib

Category: IE, JavaScript, Library

<p>Alexander Sotirov has gone deep into JavaScript internals in IE. Really deep. His focus was on exploits, but there is knowledge that help us understand why Array.join is better than string += “foo” for large amounts of data.

Introduction

The exploitation of heap corruption vulnerabilities on the Windows platform has become increasingly more difficult since the introduction of XP SP2. Heap protection features such as safe unlinking and heap cookies have been successful in stopping most generic heap exploitation techniques. Methods for bypassing the heap protection exist, but they require a great degree of control over the allocation patterns of the vulnerable application.

This paper introduces a new technique for precise manipulation of the browser heap layout using specific sequences of JavaScript allocations. We present a JavaScript library with functions for setting up the heap in a controlled state before triggering a heap corruption bug. This allows us to exploit very difficult heap corruption vulnerabilities with great reliability and precision.

We will focus on Internet Explorer exploitation, but the general techniques presented here are potentially applicable to any other browser or scripting environment.

HeapLib, a JavaScript heap manipulation library, came out of this work:

javascript
< view plain text >
  1. // Create a heapLib object for Internet Explorer
  2. var heap = new heapLib.ie();
  3.  
  4. heap.gc();      // Run the garbage collector before doing any allocations
  5.  
  6. // Allocate 512 bytes of memory and fill it with padding
  7. heap.alloc(512);
  8.  
  9. // Allocate a new block of memory for the string "AAAAA" and tag the block with "foo"
  10. heap.alloc("AAAAA", "foo");
  11.  
  12. // Free all blocks tagged with "foo"
  13. heap.free("foo");

Posted by Dion Almaer at 9:47 am
10 Comments

+++--
3.6 rating from 35 votes

10 Comments »

Comments feed TrackBack URI

Can you provide a link to the original article please?

Comment by Dean Edwards — May 1, 2007

And the link???

Comment by elalecs — May 1, 2007

Looks like it’s http://www.determina.com/security.research/presentations/bh-eu07/bh-eu07-sotirov-paper.html

Comment by Rich Strangfeld — May 1, 2007

Please excuse my lack of intelligence but after reading the description and the link supplied by Mr. Strangfeld, I still don’t understand why Array.join is better than string concatenation. Could some kind folk give me a quick explanation, please?

Comment by Jordan — May 1, 2007

To free one of the strings we’ve allocated, we need to delete all references to it and run the garbage collector. Fortunately, we don’t have to wait for one of the heuristics to trigger it, because the JavaScript implementation in Internet Explorer provides a CollectGarbage() function which forces the garbage collector to run immediately.

CollectGarbage() !!!

Comment by Dean Edwards — May 1, 2007

My mind has just exploded!

And why have I never heard of CollectGarbage() before?

Comment by Steve Kollars — May 2, 2007

Eric Lippert discusses garbage collection here.
http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx
Some great comments here re: memory leaks, “what if”, the 95% case and dismissal of concerns (keep in mind this was 2003.) Heh.
CollectGarbage() is one of those fun MSDN undocumented methods.

Comment by Scott Schiller — May 2, 2007

@Jordan
I think there is memory leak in IE.
On 6000+ strings with overall length of 360Kb array.join version runs 20 times faster (18sec against 1sec) and use about 20Mb less memory on IE. ((timed using Date().getTime() on IE6sp2))
All other browsers don’t show any speed increase, and are 10 times faster then IE on array.join version. So, string concatenation in any browser is 200 times faster than in IE.

Anyway, inserting these 6000+ elements into DOM takes more time in any browser (and can’t be accurately timed).

Comment by DPP — May 5, 2007

Interesting..
AVG blocks access to the main article on determina.com with the message indicating the page has a trojab horse by the name of “JS:DAO-Exploit [Trj]“.

Comment by Abba Bryant — May 6, 2007

array.join is and has always been the only reason my code runs at speed. thank you jeebus!

Comment by rektide — May 29, 2007

Leave a comment

You must be logged in to post a comment.