SpiderMonkey Research - The Beginning

For a while now, I have been really interested in getting into browser exploitation but the thought alone has been daunting. I checked out Browser Hacker's Handbook briefly but that scared me too. I then decided to contribute to Mozilla to get my hands dirty. Although I have not contributed as much as I would love to, I have been fortunate to e-meet Matthew Gaudet. Matthew is a really friendly, smart and helpful dude. I also stumbled across his blog while scouting for resources on SpiderMonkey

Few days ago while checking on LiverOverflow, I saw he has just began his browser exploitation journey! This was amazing, his first video spoke to me on a personal level. As a young researcher, it is easy to see what other known researches are up to and feel like you'll never get there because time waits for no one and the industry is rapidly changing. Seeing LiveOverflow explain his own challenges and take on it re-inspired me. I thought to myself; I can start with him, with discipline, by the time he has become advanced, I would too! Maybe not as good but I will be somewhere better than where I am now.

Fortunately, I had Mozilla's Firefox repo since I was contributing to that. I decided to use SpiderMonkey as the research Engine on Windows. This is pretty different from LiveOverflow's setup but that's the fun part!

Approach

My goal is to mirror his research closely. Discover the (near) equivalence or differences between both engines, pick a similar bug to his, walk-through it and share my part of the story like he is doing. I'm excited and scared at the same time but this is gonna be fun. This blog would help keep me accountable and responsible.

Every post on this topic would contain an "Into the weeds" section where I hope to elaborately describe my challenges and mistakes. It would typically be at the end of the post and the intention is make the posts less magical and more realistic.

Honourable Mentions

Stanko Jankovic a Bugcrowd researcher is also doing similar work with V8 and Windbg. Check it out!

Conclusion

LiveOverflow, I'm just one of the many people you inspire and teach indirectly. Once again, thank you for what you are doing in and for the community. Shout out to other researchers bringing knowledge that once rested among gods to the average man,  encouraging and inspiring us to work hard and consistently. I look forward to contributing more than I have received/been given.

Anyone, finally, if you see anything wrong, weird, etc. Feel free to correct me. Without further ado, let's get to it!

0x01 - SpiderMonkey Research - Setup & Debug >>

SpiderMonkey Research - 0x01 - Setup & Debug

Anyone else find Setup of any sort to be somewhat always complicated? Whether its setting up dev environment, going through documented installation steps etc. For me most things just would not work like they have been documented to. Maybe it's just me. Well, this was one of those. Check out the "Into the weeds the section" at the end of the post for more details on mistakes, frustrations, challenges and general lolz and facepalm moments and troubleshooting tips.

Obligatory Environment Details

1. Windows 10 Enterprise Evaluation v1809

Setup & Debug
In each step, where applicable, the superscript numbers reference the official Mozilla Documentation. This would help with troubleshooting when required.

1. Getting SpiderMonkey Source.

• Get the latest Mozilla-build ¹. Use default installation settings.
• Run the start-shell.bat file in C:\mozilla-build
• From within a new Shell navigate to a location where you would want the source to reside
• Fetch the source using mecurial
  hg clone https://hg.mozilla.org/mozilla-central
  This is going to take some time

2. Compiling SpiderMonkey ²

    SpiderMonkey requires some pre-requisites as mention in Mozilla build docs.

1. Follow the instructions from Getting-Ready till Required Tools. During the Visual Studio Setup also select clang for Windows in the individual components. 
2. Download and Install Microsoft Visual C++ Compiler for Python 
3. Install .NET Framework 3.5 from "Turn Windows Features Off or On"
4. launch the start-shell.bat script and navigate to your repo location
5. Execute the following command to properly configure your environment and catch any missing deps

mozilla-central$ ./mach bootstrap
6. In the js/src folder create a build directory. Mine is called BUILD_DBG.OBJ (as recommended by Mozilla)
   mozilla-central/js/src$ mkdir BUILD_DBG.OBJ
7. From within the new directory run the following commands

          mozilla-central/js/src/BUILD_DBG.OBJ$ autoconf-2.13 #Note the official docs use autoconf2.13 but checking C:\mozilla-build\msys\local\bin we see the correct command
     mozilla-central/js/src/BUILD_DBG.OBJ$ ../configure --enable-debug --disable-optimize --enable-nspr-build

     mozilla-central/js/src/BUILD_DBG.OBJ$ mozmake -j4 -s

3. Debugging

    We want to be able to instrument the JS engine from within the debugger and break into it to examine memory. We would be using WinDbg.

1. Install the WinDbg Preview App from the Windows Store. You can find the app by searching WinDBG in Cortana search box. If you prefer, you can install WinDbg by following these instructions from Download Debugging Tools for Windows
2. Configure WinDbg as a Postmortem debugger by following these instructions from Microsoft
3. Configure Symbol path in the debugger
   

   .sympath srv*c:\symbols*https://msdl.microsoft.com/download/symbols

   .sympath+ srv*C:\symbols*https://symbols.mozilla.org/

4. Next, we would be using a tool by @0vercl0k. Follow the installation guide on GitHub
   1. Note that to use the command interface on the debugger, you'll have to have attached to a process. You can start and attach to the JS shell at

      /path/to/debug/build/dist/bin/js.exe

5. Install python3.7 from Python
6. Two notable functions only available in Debug build of JS shell are dumpObject() and objectAddress()
7. Now we should be set to start our Journey

Resources

1. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites
2. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Build_Documentation
3. https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/#setting-it-up

Into the Weeds
I originally tried to use the source from GitHub using the following command.
git clone --depth 1 https://github.com/mozilla/gecko-dev.git
The build time using this method was supposed to be significantly faster. However, I ran into problems running step 7 using that source.The major reason was ./mach bootstrap which is supposed to help with dependencies only works with the Mecurial source. Technically, I could go through the code, see what it does and validate the environment myself but that would be way too much work (I think).

Now, there's definitely a way to use Mecurial and still get cloning to complete in a significantly shorter time but I did not explore this option. Feel free to share your quick clone/build tips in the comment below.

Oh, I almost forgot. Step 2 and 3 where written after multiple fails in step 5. So you may have more fails but that means step 5 is really doing it's job. Just make the fix to your environment as it suggest. Also it does take sometime.

I also ran into problems using the following options for configure. --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32. Definitely, If you have some advice regarding this please share in the comments! But I don't think we need this.

I ran config without the --enable-nspr-build option and mozmake failed with 'prinit.h' not found. This was frustrating because I thought I had done everything right. A quick check on my configure and I returned here to update Step 7!

In the debugging stage. Setting the symbols path, at this point of writing. I'm not sure if that step is required. I seemed to be able to find symbols without specifying the symbols path. This is probably a result of the debug build.

Special Thanks to 0vercl0k, his blog on Introduction to SpiderMonkey Exploitation³ is a useful reference as I compare and contrast with LiveOverflow's work on Webkit. It has really helped fast-track my progress