SIL765: Assignment 3 on Heap Spraying Attacks


In the first assignment, you gained experience with exploiting memory vulnerabilities in a care- fully controlled sandbox. In this project, you will experience the added difficulty of exploiting a large program-Firefox-in a less carefully controlled setting.

Your goal will be to produce an HTML file that, when opened in a vulnerable Firefox browser, executes arbitrary machine code with the privileges of the user running Firefox. Specifically, we will ask you to run code that binds a shell to port 8080 on the victim's machine.

As with the previous project, your work must be done on the VMware virtual machine provided on the course website; see below for information about this environment.

To save you the minutes and minutes of effort that would be required to find an exploitable vulnerability in Firefox, we have packaged a custom version of Firefox with the Boxes VM you'll use for this project. This special version has a new DOM method, navigator.pwnMe(), that will transfer control to the memory address given to it as an argument.

Just calling this method won't be enough. You'll be graded on the reliability of your exploit. Your exploit should work when the browser is freshly opened, and after a long browsing session. Your exploit should work with one tab open, or dozens. To make things worse, Firefox will be running with address-space layout randomization (ASLR) enabled, so objects may move in memory between otherwise identical runs.

To make your exploit reliable under such challenging conditions, you will want to use heap spraying.

Note: In this project, you are being asked to perform exploitation of real-world programs under real-world conditions, not the more controlled laboratory conditions of the first project. You may find this project less straightforward and more open-ended than the first one.

The Vulnerable Browser

For reasons of licensing and philosophy that are mostly orthogonal to our concerns, the Debian Project's version of the Firefox browser does not use the Firefox name or branding. Instead, the browser is called "Iceweasel".

Running iceweasel on the command line from an xterm will launch a browser window. Debug symbols are available in case you find them helpful. If you run iceweasel -g on the command line, Iceweasel will run itself under GDB.

The Firefox browser keeps its configuration, history, and caches in the ~/.mozilla/directory. You can remove this directory (or rename it) when you wish to start fresh.

For your reference, here is the C++ code implementing the navigator.pwnMe() DOM method:


nsNavigator::PwnMe(PRUint32 addr)


((void (*)())(addr))();

return NS_OK;


The Environment

You (and we, for grading!) will test your exploit programs within a VMware virtual machine. The Boxes environment for this project has the X Win- dowing System installed. (You'll need X to run Firefox.) You can use SSH X forwarding to have X clients running insider the VM display on the host machine.

The Assignment

You are to write a single HTML file, called [yourlastname].html. This file must be self-contained: it must not include any external scripts or other resources.

When opened in the Iceweasel browser (using File -> Open from the menu), this file should exploit the pwnMe vulnerability and bind a shell to port 8080 on the VM. We will then connect to this port from the host machine and run shell commands, using netcat: "nc [VM IP address] 8080". To get you started, we have provided a bindshell shellcode that execs netcat to bind a shell to port 8080, as required, at bindshell.txt; feel free to modify this shellcode or use a different one if you prefer.

We will test your exploit in several configurations, and grade you based on its reliability. You can use your HTML file to display a witty message to the TAs, if you'd like.

Update:Exploits that do not interfere with user's activity will earn extra credit. User should be able to continue doing whatever (s)he was doing. This part will be examined critically.


  1. You can find the process ID for running Iceweasel processes by running "pstree -p". The child processes shown will in fact be Linux "light-weight processes" (threads), and won't have their own memory map. For the parent process, you can show its memory map by listing the file "/proc/[processid]/maps".
  2. There doesn't seem to be any convenient way to examine the internals of the JavaScript heap from within Firefox itself. If you do want to use GDB to explore the JavaScript heap, you will find it handy to have access to a JavaScript context object, cx. Here are instructions, for obtaining a context:
    1. Run Firefox in debug mode, using the command "iceweasel -g".
    2. Create a breakpoint at a function that is very rarely called on Firefox:

      (gdb) break js_ValueToXMLObject

      If asked whether to make this breakpoint pending on library load, say yes. This is a function for XML processing. Inside this function, we can get the access to cx, the JavaScript context.

    3. Do your heap spray. At the JS program point that you believe your heap spray is done, insert a JavaScript statement such as the following (to trigger a call to js_ValueToXMLObject):

      var sales = (<) sales vendor="John">

      (<)item type="peas" price="4" quantity="6"/>

      (<)item type="carrot" price="3" quantity="10"/>

      (<)item type="chips" price="5" quantity="3"/>


      The JS code triggers the function with the breakpoint.

    4. In the GDB breakpoint inside the function, the variable cx is a usable JavaScript context.
  3. Test your exploit in many different settings: with Iceweasel freshly launched and after some browsing, with few or many tabs open, with ~/.mozilla/ present and without, etc.



  1. You are to provide a tarball (i.e., a .tar.gz or .tar.bz2 file) containing the HTML file for your exploit.
  2. Along with your HTML exploit file, you must include a text file/PDF Report to explain the strategy you used in your exploit.


  1. To be done individually.
  2. The last date of submission of is March 16, 11:59:00 PM.