Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The author was running a fuzzer on Adobe reader. They had both a JavaScript section and a PDF portion. Let's triage!

The CPDField of a PDF are internal AcroForm.api C++ objects used to represent text fields, buttons and many other things. In the POC, there is a CPDField object that is a child of another object. When doing this and calling JavaScript on the parent with a callback that has state changing actions on the child, we crash. But why?

The CPDField has an internal property called LockFieldProp in order to prevent concurrent access issues. This field is checked every time some change is happening on the object. However, when using a custom callback on (like mentioned above) a recursive call can be made that can free the child object, since it was never locked.

When the recursive call goes back up the call stack, the object pointer is now free, resulting in a use after free vulnerability. The initial patch ONLY locked the directory child of ab object. Hence, the author wrote a POC that modified the grandchild of a field, which resulted in the same vulnerability as before.

This bugs appears to be extremely exploitable! In JavaScript, controlling the CPDField is easy to control via a heap spray of similarly sized objects. Once the freed CPDField has been swapped out with an object that we control, it is now gameover! The POC submitted to ZDI, once dereferenced, demonstrated control of a virtual function pointer.

Overall, interesting find that appears to be extremely exploitable. Seeing deep into the crash analysis of a real bug that the author found fuzzing was quite the insight.