Fuzzing Adobe Reader - Exploit Development

Question

I have been fuzzing Adobe Reader lately. I found couple of bugs.

One of the major issues that I'm facing are listed below.

1. How to identify the root cause of the issue? I mean, the PoC has a large number of modification and it's not easy to change each block and test. So, it's very difficult to find the bytes that caused the crash.

I have been studying Taint Analysis and Symbolic Execution driven Fuzzing and vulnerability research.

I use IDA pro for my RE work. Is there any good plugin that does that task. I know about "tree-cbass" https://code.google.com/p/tree-cbass/

But I'm unable to use it efficiently. I would like to get inputs and tips from experienced vulnerability researchers and exploit developers.

I want to pursue my career as vulnerability researcher and have a little knowledge in this domain.

Thanks.

Answer 1

There are good answers to your question here. However, I wanted to give you my opinion. Root cause analysis, over all, is best done half-manually. One of the reasons is that techniques like Dynamic Taint Analysis, using SMT solvers, etc... are good tools for small or specific problems but almost unusable for whole projects + real targets, for the average researcher, because of the time and power required. Also, it's worth considering the time you will need to develop a tool using such techniques that might work well with a real target, like Acrobat Reader.

The very first thing I can recommend you, in order to make your task less annoying, is to write minimization tools. Depending on how you created your mutated samples, you could even use some of the tools I wrote myself for Nightmare like this kind of generic crash minimization tool that works for some binary files and for text only files (it might work for you with Acrobat Reader with some modifications). Once you minimized your PDF, you might want to do also the following:

1. Use MyNav, BinNavi or a similar tool able to do differential debugging.
2. Record a first execution with a blank PDF. Be sure to record as most GUI events as possible.
3. If you created your mutated file from a template PDF file, then record also an execution of that original PDF file. It will remove all the functions and basic blocks that were used for that specific template.
4. After the previous steps were you record a trace of a blank PDF file, GUI events, etc... record the execution of your crashing PDF sample. As you're using differential debugging, only the last basic blocks and/or functions will appear in the last trace.

Hopefully, you will have only a few basic blocks or functions to analyse and you might be able to see which conditional jumps where taken or not taken and determine why it crashed.

BTW, if you're on Unix, you can also diff logs of valgrind executions with the original template and with your crashing sample.

My 2 cents...

Answer 2

First of all you should write script to lower the difference between your mutated(fuzzed) file and original in order to know the main byte/bytes that make program crash. This would be a byte by byte compare,change,check to make sure you have the minimal difference needed to crash the app.(It's possible that you found new crashes this way. believe me!)

Second part would be mixing your code with debugger that can check if lowered file is still crash-able or not.

if you choose Python for this work, it can be done in couple of hours.

P.S. check WinAppDbg, PyDbg, PyDbgEng and etc.

Answer 3

The best thing you can do is to learn how to read assembly. Start at the crash, see what type of memory is being used, values in registers, and previous instructions. Learn how to use windbg. Taint analysis and smt solving is intended for pure binary data, it sucks for interpreters or abstract state machines. In other words, its great when the relationship between data and code is 1 to 1 as in media players etc. If you want to be a vulnerability researcher then learning how to efficiently reverse engineer is the best long term investment you can make. Itll shorten the time between crash and root cause analysis and will improve the quality of the bugs you find.

The size difference between the original and fuzzed file is substantial and likely was not produce by dumb binary byte flipping. Also, the PDF format contains a lot of non binary data. You have to study how Reader works and also get very intimate with the PDF spec. This is a manual endeavor.

Check out the tutorials at https://www.corelan.be/index.php/category/security/exploit-writing-tutorials/

EDIT - Code coverage and a lot of other stuff is easy to do with PIN, including taint tracking with XED2. Check out Dytan and Privacy Scope, both of which are open source. If the application is complex then most likely you will have to customize your tools for it. You dont want to run your code against decompression. Theres also static taint tracking and a good example is http://phrack.org/issues/67/10.html which goes backwards from a crash. The rules are simple so its easy not complex to make this sort of tool. The difficulties come when interfacing with system APIs and third party libraries which is where the customization comes in. You could use more advanced features as well, check out shadow memory and one of my favorite papers http://dynamorio.org/pubs/zhao-million-watchpoints-CC08.pdf