In October 2021, Adobe released a security update for vulnerabilities in Adobe Acrobat and Reader. Among these vulnerabilities is an out-of-bounds read (CVE-2021-40729) that was discovered by Zscaler’s ThreatLabz. In this blog, we present our analysis of this vulnerability in the Adobe Acrobat Pro DC Solid Framework. Adobe uses the Solid Framework for the conversion of PDF files to Microsoft Office files. Foxit’s PDF Editor is also impacted by this vulnerability since it also uses the Solid Framework for the conversion of PDF files to other file formats.

Vulnerability Description

CVE-2021-40729 is an out-of-bounds read vulnerability that could potentially lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious PDF file.

Known Affected Software Configurations

Acrobat DC Continuous 21.007.20095 and earlier versions in Windows
Acrobat DC Continuous 21.007.20096 and earlier versions in macOS
Acrobat 2020 Classic 2020 20.004.30015 and earlier versions in Windows & macOS
Acrobat 2017 Classic 2017 17.011.30202 and earlier versions in Windows & macOS
Foxit PDF Editor 11.2.0.53415 and all previous 11.x versions, 10.1.6.37749 and earlier

Proof of Concept

The vulnerability can be triggered by opening a specially crafted PDF file and exporting it to a Microsoft Word document. Zscaler ThreatLabz created a PoC file that will cause the following crash.

(1734.15d4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=a7acaff8 ebx=a7fc4fa0 ecx=00000001 edx=80000090 esi=809f8220 edi=04afbb7c
eip=80a82943 esp=04afbb00 ebp=04afbb18 iopl=0         nv up ei ng nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210293
PDFLibTool!CPdfColorSpace::SetCurrentColorIndirect+0xb3:
80a82943 f20f100cc8      movsd   xmm1,mmword ptr [eax+ecx*8] ds:002b:a7acb000=????????????????
0:000> dc eax
a7acaff8  6f23f199 3ff0cd9a ???????? ????????  ..#o...?????????
a7acb008  ???????? ???????? ???????? ????????  ????????????????
a7acb018  ???????? ???????? ???????? ????????  ????????????????
a7acb028  ???????? ???????? ???????? ????????  ????????????????
a7acb038  ???????? ???????? ???????? ????????  ????????????????
a7acb048  ???????? ???????? ???????? ????????  ????????????????
a7acb058  ???????? ???????? ???????? ????????  ????????????????
a7acb068  ???????? ???????? ???????? ????????  ????????????????
0:000> !heap -p -a a7acaff8
    address a7acaff8 found in
    _DPH_HEAP_ROOT @ 9501000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                a7993bc8:         a7acaff8                8 -         a7aca000             2000
    672ba8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240
    7714f10e ntdll!RtlDebugAllocateHeap+0x00000039
    770b70f0 ntdll!RtlpAllocateHeap+0x000000f0
    770b6e3c ntdll!RtlpAllocateHeapInternal+0x0000104c
    770b5dde ntdll!RtlAllocateHeap+0x0000003e
    75840166 ucrtbase!_malloc_base+0x00000026
    80d11770 PDFLibTool!CxManagedImage::Set+0x000c27b0
    80a09dcd PDFLibTool!SolidWatermark::CSolidImageWatermarkOptBase::getWatermarkFileName+0x0000095d
    80b1e9ed PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand+0x00001d6d
    80b1c398 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x000005a8
    80b1bdce PDFLibTool!CPdfPageContentProcessor::ProcessCommandStream+0x0000002e
    848d7fad SecurePdfSDK!CLayoutPage::PerTextContent+0x0000004d
    848ffbf4 SecurePdfSDK!CPdfOCRPageRenderTools::IsPageScanned+0x00000174
    83f89e31 PdfFlt+0x00009e31
    83fa634d PdfFlt+0x0002634d
    8453a8dd PdfFlt+0x005ba8dd
    80b17800 PDFLibTool!CPdfDocumentImplEx::RenderPDFDocument+0x00000410
    8453c8b8 PdfFlt+0x005bc8b8
    84541c4b PdfFlt+0x005c1c4b
0:000> kb # ChildEBP RetAddr  Args to Child             
WARNING: Stack unwind information not available. Following frames may be wrong.
00 04afbb18 80b225ed 04afbb7c a7acaff8 00000000 PDFLibTool!CPdfColorSpace::SetCurrentColorIndirect+0xb3
01 04afbbf8 80b1ea41 00000001 a7acaff8 00000000 PDFLibTool!CPdfPageContentProcessor::SetCurrentColor+0x1cd
02 04afbd98 80b1c398 04afc1b8 80b1c398 04afbe9c PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand+0x1dc1
03 04afc0cc 80b1bdce a38defb8 a329efe8 04afe918 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x5a8
04 04afc0e4 848d7fad a38defb8 88a9b2b0 a329efe8 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStream+0x2e
05 04afc114 848ffbf4 88a9b7a8 6c818f20 83f87840 SecurePdfSDK!CLayoutPage::PerTextContent+0x4d
06 04afc40c 83f89e31 6a550cf0 a329efe8 04afc474 SecurePdfSDK!CPdfOCRPageRenderTools::IsPageScanned+0x174
07 04afc8d8 83fa634d 6c818f20 4e1b0412 83fa62c0 PdfFlt+0x9e31
08 04afc92c 8453a8dd 6c818f20 4e1b0156 84539dd0 PdfFlt+0x2634d
09 04afcc68 80b17800 6babbb4c 04afe918 6fdf4f40 PdfFlt+0x5ba8dd
0a 04afcd90 8453c8b8 95236fe0 4e1b00de 04afe918 PDFLibTool!CPdfDocumentImplEx::RenderPDFDocument+0x410
0b 04afcde0 84541c4b 95236fe0 04afe990 73f2aff0 PdfFlt+0x5bc8b8
0c 04afce00 84541d1a 4e1b030a 04afe990 6a550cc0 PdfFlt+0x5c1c4b
0d 00000000 00000000 00000000 00000000 00000000 PdfFlt+0x5c1d1a

Test Environment

Adobe Acrobat Pro DC, Product version: 21.7.20095.60881
PDFLibTool.dll, Product version: 10.0.12082.1
Solid Framework (x86), Product version: 10.0.12082.1

Technical Analysis

The out-of-bounds read vulnerability CVE-2021-40729 exists in Adobe Acrobat Pro DC’s third-party library Solid Framework, which is located in the directory C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\plug_ins\SaveAsNonPDF\Solid. Figure 1 shows a comparison between a properly structured PDF file with a minimized PoC file that triggers this vulnerability.

Figure 1. Comparison between a proper PDF file and the minimized PoC file that triggers CVE-2021-40729

Figure 2 shows the single modified byte that triggers the vulnerability located in obj 4.

Figure 2. Hexdump of the obj 4 buffer including the modified byte that triggers the vulnerability

The structure of the minimized PoC file is shown below in Figure 3.

Figure 3. The structure of the minimized PoC file

In Figure 3, the obj 2 uses obj 6 as its resource and obj 4 as its content. obj 6 references obj 8 as its colorspace. obj 8 is an ICCBased family color space. ICCBased color spaces can have 1, 3, or 4 components (defined by the N dictionary value). So they often use Gray (1 component), RGB (3 components), or CMYK (4 components). obj 25 contains the ICC profile in its stream. The parameter “/N 3” indicates the number of color components in the color space described by the ICC profile data. In this PoC PDF file, it uses RGB color spaces. Therefore, when the Solid Framework processes the SC (set color) operator, three operands are required.

The description of the SC operator is listed in Figure 4.

Figure 4. The SC (set color) operator definition

The stream data in obj 4 has been compressed using the deflate algorithm. (For more information on deflate, please refer to https://tools.ietf.org/html/rfc1951). Zlib is a C library that implements the deflate algorithm. Adobe Acrobat also uses Zlib to decompress the deflate-compressed data, we can use the Python script shown below to decompress the data in obj 4.

Figure 5. Python Zlib decompression code

The uncompressed stream content in obj 4 contains a stream of graphics operators. Many of these streams contain invalid operators and abnormal operands including “1.050196108SC” as highlighted in Figure 6.

Figure 6. Uncompressed stream content in obj 4 in the minimized PoC file

Normal stream data for the SC operator is shown in Figure 7.

Figure 7. Uncompressed stream content in obj 4 in a normal PDF file

The parsing and processing of these abnormal operands for the SC operator are directly related to this vulnerability. In the section of “Proof of Concept”, the methods CPdfPageContentProcessor::ProcessCommandStreamMultiThread and CPdfPageContentProcessor::ProcessGeneralCommand in the stack backtrace stand out.

The method CPdfPageContentProcessor::ProcessCommandStreamMultiThread(std::streambuf &) is responsible for processing the command stream of graphic operators and operands. First, it calls the function sub_101288B0() that starts a thread to parse the stream content. The thread calls the function sub_1012AB70(). Finally, in the function sub_1012AB70() it parses each command from the stream content. The call flow graph is shown in Figure 8.

Figure 8. The control flows for parsing the PDF stream content

The following breakpoint in Figure 9 can be set in order to analyze the memory layout for each command.

Figure 9. Breakpoint to analyze the memory layout of the CPdfCmdContext structure

After the method CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) is called, a breakpoint can be set on the following instruction to analyze the memory layout of the CPdfCmdContext structure.

bu PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x75e ".echo get cmd: ; dd ebp-0x3c L1; .echo Vector<CPdfLexem>; db poi(ebp-0x38) L(poi(ebp-0x34)-poi(ebp-0x38)); gc; "

Example output when this breakpoint is hit is shown in Figure 10 with the std::Vector<CPdfLexem> graphic operator objects. Each CPdfLexem object consists of 0x28 bytes that store the operator and its operands.

Figure 10. Memory dump for a CPdfCmdContext structure

A conditional breakpoint can be set after the method CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) finishes parsing the stream content “0.5968767 m.5285492” followed by the stream content “1.050196108SC” to further understand how the invalid data is processed.

bu PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x75e ".echo get cmd: ; dd ebp-0x3c L1; .echo Vector<CPdfLexem>; db poi(ebp-0x38) L(poi(ebp-0x34)-poi(ebp-0x38)); .if(poi(poi(ebp-0x38)+0x20)=0x2a47d227) { .echo 0.5968767 m.5285492 hit; } .else {gc;}"

In Figure 11, the memory layout is shown with the members of a CPdfCmdContext structure.

Figure 11. The members of a CPdfCmdContext structure

After the call to CPdfCommandStreamBase::GetNextCmd(CPdfCmdContext &) the memory layout of std::Vector<CPdfLexem> object contains the stream content “1.050196108SC” as seen in Figure 12. This std::Vector<CPdfLexem> object includes two CPdfLexem objects: the first comes from a single operand, and the second comes from the operator SC.

Figure 12. Memory layout of std::Vector<CPdfLexem> for the stream content “1.050196108SC”.

The memory layout of the type double 1.050196108 is correct (0x3ff0cd9a6f23f199) as shown in Figure 13 using an online conversion tool.

Figure 13. The 1.050196108 double value converted to a hex value

The method CPdfPageContentProcessor::ProcessCommandStreamMultiThread(std::streambuf &), obtains all commands via parsing the stream content for graphic operators and operands. Then, it calls CPdfPageContentProcessor::ProcessGeneralCommand(GrStateCommands const &,char const *,std::vector<CPdfLexem> &,int) to process these commands one by one in a loop.
Thereby, another conditional breakpoint can be set on the method call CPdfPageContentProcessor::ProcessGeneralCommand(GrStateCommands const &,char const *,std::vector<CPdfLexem> &,int).

bu PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand ".if(poi(poi(esp+4))=0x23) {.printf \"stream 0x23 \\n\"; .printf  \"CPdfPageContentProcessor::ProcessGeneralCommand hit\\n\"; dps esp L7; db poi(esp+8); dd poi(esp+4) L1; }; .else{ gc;}"

This function takes 4 parameters. The 1st parameter stores the command number, the 2nd parameter stores the graphic operator, the 3rd parameter is a reference to a std::vector<CPdfLexem> object, and the 4th parameter is the number of operands in this graphic operator.

The following output shows when this breakpoint is hit the second time.

stream 0x23
CPdfPageContentProcessor::ProcessGeneralCommand hit
04efb85c  84fac398 PDFLibTool!CPdfPageContentProcessor::ProcessCommandStreamMultiThread+0x5a8
04efb860  04efb954     ;1st parameter
04efb864  aaab4fdc     ;2nd parameter
04efb868  04efb958     ;3rd parameter
04efb86c  00000001     ;4th parameter
04efb870  39045405
04efb874  50caaff8
aaab4fdc  53 43 00 85 ff ff ff ff-b4 fd c5 a4 40 11 f6 84  SC..........@...
aaab4fec  02 00 00 00 0f 00 00 00-00 00 00 00 00 00 00 00  ................
aaab4ffc  00 00 00 00 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ....????????????
aaab500c  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab501c  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab502c  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab503c  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab504c  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
04efb954  00000023
eax=1103d938 ebx=04efbc70 ecx=04efbc70 edx=55000054 esi=881ec9c0 edi=564c6fb8
eip=84facc80 esp=04efb85c ebp=04efbb84 iopl=0         nv up ei pl zr na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200247
PDFLibTool!CPdfPageContentProcessor::ProcessGeneralCommand:
84facc80 53              push    ebx
0:000> db poi(04efb958)
aaab4fb0  04 00 00 00 00 f0 1a 85-ff ff ff ff b4 fd c5 a4  ................
aaab4fc0  40 11 f6 84 00 00 00 00-0f 00 00 00 00 00 00 00  @...............
aaab4fd0  99 f1 23 6f 9a cd f0 3f-07 00 00 00 53 43 00 85  ..#o...?....SC..
aaab4fe0  ff ff ff ff b4 fd c5 a4-40 11 f6 84 02 00 00 00  ........@.......
aaab4ff0  0f 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
aaab5000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab5010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
aaab5020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> !heap -p -a aaab4fb0
   address aaab4fb0 found in
    _DPH_HEAP_ROOT @ 87a1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                aa9929f4:         aaab4fb0               50 -         aaab4000             2000
    707ba8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240
    7714f10e ntdll!RtlDebugAllocateHeap+0x00000039
    770b70f0 ntdll!RtlpAllocateHeap+0x000000f0
    770b6e3c ntdll!RtlpAllocateHeapInternal+0x0000104c
    770b5dde ntdll!RtlAllocateHeap+0x0000003e
    75840166 ucrtbase!_malloc_base+0x00000026
    851a1770 PDFLibTool!CxManagedImage::Set+0x000c27b0
    84f1df85 PDFLibTool!UnicodeHelper::unicodeStringToPdfUnicodeString+0x00002b25
    84f9cb50 PDFLibTool!CPdfCommandStreamBase::GetNextCmd+0x00000240
    84faabbe PDFLibTool!CPdfPageContentProcessor::~CPdfPageContentProcessor+0x0000075e
    84fa8b08 PDFLibTool!CPdfDocumentImplEx::SetupPageData+0x00000728
    75854f9f ucrtbase!thread_start<unsigned int (__stdcall*)(void *),1>+0x0000003f
    76f8fa29 KERNEL32!BaseThreadInitThunk+0x00000019
    770d7a9e ntdll!__RtlUserThreadStart+0x0000002f
    770d7a6e ntdll!_RtlUserThreadStart+0x0000001b
    00000000 +0x00000000

In this example, the command number is 0x23. This causes the code to enter the following switch case shown in Figure 14 in the function CPdfPageContentProcessor::ProcessGeneralCommand.

Figure 14. The switch case for command 0x23 in CPdfPageContentProcessor::ProcessGeneralCommand

This switch code block reads 8 bytes at the offset 0x20 in the std::vector<CPdfLexem> object. The value of the 8 bytes represents the type double 1.050196108. Then it creates a heap buffer with a size of 8 bytes. Next, it copies these 8 bytes from the std::vector<CPdfLexem> object to the newly created heap buffer. Next, it makes an indirect call to the method CPdfPageContentProcessor::SetCurrentColor(int,double *,char const *,int). When it enters into this function CPdfPageContentProcessor::SetCurrentColor, the second parameter is a pointer to a double with the value 1.050196108 as shown in Figure 15.

Figure 15. The parameters of CPdfPageContentProcessor::SetCurrentColor

In the method CPdfPageContentProcessor::SetCurrentColor, the code calls the method CPdfColorSpace::SetCurrentColorIndirect(CGSColor &,double const *,int,std::string const &). This first parameter is a CGSColor object. The second parameter comes from the 2nd parameter of CPdfPageContentProcessor::SetCurrentColor. The register ECX is the this pointer for a CPdfColorSpace object whose size is 0x60 bytes. The 4 bytes at offset 0x08 in the CPdfColorSpace object represents the number of color components in the color space described by the ICC profile data. In Figure 16, the 4 bytes at offset 0x08 in the CPdfColorSpace object is equal to 0x3. As previously described in Figure 3 and Figure 4, “/N 3” indicates the number of color components in the color space, which explains why the value at offset 0x8 in the CPdfColorSpace object is 0x3.

Figure 16. Inspect the parameters of CPdfColorSpace::SetCurrentColorIndirect

The function CPdfPageContentProcessor::SetCurrentColor calls the method CPdfColorSpace::SetCurrentColorIndirect. This method tries to read 3 required color components from its second parameter in a loop. However, in the PoC the second parameter stores only one color component. When it tries to read the second color component from the heap buffer, it causes an out-of-bounds read crash as shown in Figure 17.

Figure 17. Read color components from a heap buffer

This concludes the analysis of this out-of-bounds read vulnerability. In short, due to abnormal SC operands in obj 4 when Adobe Acrobat parses “1.050196108SC”, it converts this stream content to one double type as the only operand of the SC operator. One double type takes 8 bytes. obj 25 declared that in color spaces it required 3 color components (i.e., three operands). Therefore, it tries to read 3 double type values in the heap buffer when it handles the graphic operator SC. This heap buffer only consists of 8 bytes, which subsequently causes an out-of-bounds read crash.

Mitigation

All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of this software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against this vulnerability.