Just An Application

August 25, 2014

Anatomy Of A PDF: Part Six — The Allocation And Deallocation Of Strings By Javascript Considered Harmful ?

Filed under: Javascript, Security — Tags: , — Simon Lewis @ 6:53 am

When it is not Base64 decoding other bits of Javascript disguised as images the Javascript in the XFA form is mostly messing about with strings which on the face of it doesn’t look as though it could be that dangerous.

The messing about occurs in three distinct phases.

The Allocation And Selective Deallocation Phase

The Javascript triggered by the initialize event starts by creating four arrays.

It then proceeds to set each element of the first array to a newly allocated string.

Each string is the result of concatenating two distinctive patterns plus two elements computed using the current iteration index.

Interestingly the size of the created strings looks very much as though it may be the same as the width of the really really big BMP image.

Having gone to all that trouble to create all those different strings it then proceeds to repeatedly null out every tenth element of the first array.

Search Phase

The search phase is performed by the Javascript triggered by the docReady event.

The code iterates over all the elements of the first array. If the element is not null the first character of the string is compared with the value that was used to initialize it when the string was created.

If they are not equal the index of the element is noted, the contents of part of the changed string are saved and the iteration terminates.

Targetted Deallocation and Second Allocation Phase

This phase is also performed by the Javascript triggered by the docReady event but only occurs if a changed string was found during the search phase.

This phase begins by assembling a new string from various bits of hex.

The element in the first array which references the changed string and the element before it in the array are then repeatedly set to null.

Each element of the second array is then set to a string created from the new string constructed at the start of this phase.

It is at this point there is a reference to “Image_2” which we know to be Base64 encoded Javascript.

The image data is decoded and then handed off to eval which is masequerading under an alias !

The “Image_2” code builds another string out of information from the version indexed table in “Image_1”, large amounts of repeated hex, some of which is in all probability x86 code, the strings




plus the result of unescaping a big chunk of data which, it turns out, contains, amongst other things, the hard-wired URL of a .exe.

I cannot begin to imagine what they are going to try and do with all of that !

The string is then repeatedly concatenated with itself until the result is a string which occupies at least 1MB of memory.

One hundred copies of this string are then created, presumably just to be on the safe side ?

By this point the heap must surely consist almost entirely of x86 code !


The order of events is

  1. the initialize event code runs.

  2. System attempts to load really, really, big BMP

  3. the docReady event code runs.

and what happens is

  1. the initialize event code sets up a known heap state based on the allocation of strings with distinctive contents, interspersed with holes created by freeing every tenth string.

  2. the System image loading code corrupts the heap attempting to load the really, really, big BMP

  3. he docReady event code finds the location of the heap corruption on the basis of the known state set up by the initialize event code and exploits it.

Given that the Javascript it looking for a string that has changed underneath it so to speak the assumption must be that the string has been freed despite still being in use. Once freed it is re-used by non Javascript code which changes it.

This in turn implies that the heap corruption involves the data used by the heap management code to keep track of which pieces of memory in the heap are in use and which are free. Such data is often contiguous with the memory that is allocated, in which case the easiest way to corrupt it is to write beyond the limits of a piece of memory as allocated which is what the really really big BMP is for.

Copyright (c) 2014 By Simon Lewis. All Rights Reserved.

Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and owner Simon Lewis is strictly prohibited.

Excerpts and links may be used, provided that full and clear credit is given to Simon Lewis and justanapplication.wordpress.com with appropriate
and specific direction to the original content.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

%d bloggers like this: