The authors of this post spent a bunch of time trying to find vulnerabilities in popular PDF readers. This post is an out of bounds read in Adobe Acrobat but there should be more articles to come. For some background, Adobe XFA (XML Form Architecture) provides the functionality for dynamic form manipulation using the JavaScript APIs and their XML specification. They targeted this section because it has been historically bad for bugs.
They setup a fuzzing harness to test the XFA functionality. Unfortunately, they don't talk about the fuzzing setup or anything else besides the bug triaging. What's crazy, is that the bug is ONLY triggered upon a mouseUp event or when the user clicks on the form.
The only input is a single XFA XDP packet. While reviewing the crash the reason appears to be an out of bounds read with the register rcx having a extremely large value that is defined in a <float> tag. The buffer is being treated as an ANSI string. However, this is where the mistake occurs: the text encoding of the form is set to UTF-16 but the code path taken is ANSI.
So, in essence, we have a type confusion vulnerability. The buffer is being treated as ANSI even though it should be treated as UTF-16. Since the data is differently sized between the two, this leads to an out of bounds read issue.
Simply changing the string size in the <float> field allows for differently sized buffers to be created. The author chose 0x58 for the size because this size is not commonly allocated/freed in the background, making the exploit much more reliable.
To groom for this size on Windows, they allocated a bunch of strings of the 0x58 size via JavaScript then triggered the garage collection by calling more JavaScript. Because the Windows heap has some randomization in place, the authors decided to add multiple <float> tags. This way, one of them is likely to succeed and get the information leak.
Overall, an interesting vulnerability! I wish they would have included more background and information on the fuzzing setup though.