Brief Analysis On Adobe Reader SING Table Parsing Vulnerability (CVE-2010-2883)

So now pretty much everyone knows about the Adobe 0-day vulnerability found in the wild. It is a classic stack buffer overflow inside CoolType.dll. CoolType.dll has developed a bad reputation during the last few months. This module has become a popular target for attackers. Interestingly, the last jailbreakme.com exploit against iPhone also leverages a vulnerability inside a font processing routine. And it is also a stack overflow. You can check out our analysis here.

Looks like it's not using return address or SEH overwriting to gain EIP control, but controls some stack data and takes advantage of the calls made after the buffer overflow.

The buffer overflow itself is caused by a strcat API call on a fixed-size stack variable. You might wonder what element of a PDF document can cause this issue. A blog post titled Return of the Unpublished Adobe Vulnerability from the Metasploit project identifies the "uniqueName" field in a SING table as causing the issue. So we dug into the issue by writing our own PDF parser to see what we can find. 
The SING specification can be found in GlyDevKit.zip. The archive contains the specification file named "Gaiji SING Glyphlet Spec.pdf". 

Illustration 1: Malicious PDF Dissection

Illustration 1 shows the SING table that is breaking Adobe parsing code. The "uniqueName" field is supposed to hold an ASCII string. The specification document clearly states that the "uniqueName" field is 28 bytes long and 7-bit ASCII with null-termination. The problem with the data here is that it's not null-terminated. 

Illustration 2: Raw Data of SING Table

Illustration 2 shows the raw data causing the overflow. 

Illustration 3: The Vulnerable Code with Unsafe strcat Call

Illustration 3 shows the actual code that leads to buffer overflow. When the block starts, the eax register holds the pointer to the start of the SING table. The offset to uniqueName(10h) is added to the register at the first instruction (00803DD9F). It is used directly for strcat operation without any kind of sanitization or verification. At the very least, the code should force null termination or verify null termination. Or they can just copy a fixed size of data out of the "uniqueName" field because it's a fixed-sized field.

Illustration 4: Contaminated Stack after Overflow

After the strcat call is performed the stack is ruined as shown in Illustration 4. 


So with this Adobe 0-day, we can learn two lessons. First, don't trust any user data and don't pass any data without sanitization or verification. Second, it might be time to throw away old unsafe string APIs.

Thanks to Mila Parkour for providing the sample.