TESTED VERSIONS

PRODUCT URLs

DETAILS

While parsing a malformed PDF file, with an object that contains malformed
/Kids reference, the value right after the /Kids element is interpreted as a string, where
an array of references should be located. This leads to parser expecting a pointer where
the string copied from the file is located resulting in an arbitrary read access violation.
In a properly formatted PDF file, an array of at least one reference must follow after /Kids element.

In the supplied testcase, an ASCII value after the /Kids element is placed on the heap
and is later referenced by the parser, and wrongfully interpreted as a pointer. The bug
appears in libvs_pdf.so (with base address 0x0xB74BF000):

Value of eax at [1] in the above basic block is the integer value following
the /Kids element in the file making a fully controlled arbitrary read.
Further more, the read value ends up being used as a pointer at the start of
the basic block mentioned first leading to a double controlled dereference.

With the integer value following the /Kids element equal to 1094795585 (or 0x41414141)
the application crashes in the following way :