CVE-2020-16040原理解析

1.Background

V8是Chromium内核中的JavaScript引擎，负责对JavaScript代码进行解释优化与执行，而CVE-2020-16040是V8优化编译器Turbofan在SimplifiedLowering阶段产生的一个整数溢出漏洞 (源自src/compiler/machine-operator-reducer.cc)

V8引擎

其中Parser（解析器）、Ignition（解释器）、TurboFan（编译器） 是 V8 中三个主要的工作模块

Parser(解析器)：负责通过对源代码进行词法分析得到的token对源代码进行语法错误分析、转换为AST抽象语法树并确定词法作用域

Ignition(解释器)：负责将 AST 转换为中间代码即字节码(Bytecode)并逐行解释执行

TurboFan(优化编译器)：负责将字节码和一些分析数据作为输入并生成优化的机器代码

接下来将重点讲述TurboFan

TurboFan优化编译器

我们主要关注 Ignition 和 TurboFan 的交互

当 Ignition 将 JavaScript 代码转换为字节码后，代码开始执行，V8 会一直观察 JavaScript 代码的执行情况，并记录执行信息，如每个函数的执行次数、每次调用函数时，传递的参数类型等。如果一个函数被调用的次数超过了内设的阈值，监视器就会将当前函数标记为热点函数（Hot Function），并将该函数的字节码以及执行的相关信息发送给 TurboFan。TurboFan 会根据执行信息做出一些进一步优化此代码的假设，在假设的基础上将字节码编译为优化的机器代码。如果假设成立，那么当下一次调用该函数时，就会执行优化编译后的机器代码，以提高代码的执行性能。当某一次调用传入的信息变化时，表示 TurboFan 的假设是错误的，此时优化编译生成的机器代码就不能再使用了，于是进行优化回退，重走原复杂函数逻辑。

Turbofan优化过程

Turbofan优化过程首先会进入SimplifiedLowering阶段，通过正反向遍历确定字节码树(Bytecode Graph Tree)中各节点的输入类型、输出类型、最大取值范围等，其共分为三个⼦阶段Propagate、Retype、Lower。

优化示例

考虑代码

function sum(a,b){
	return a+b;
}

function manysum(x,y){
	for(var i =0;i<0x10000;i++){
		sum(x,y)
	}
}

JavaScript 是基于动态类型的，a 和 b 可以是任意类型数据，当执行 sum 函数时，Ignition 解释器会检查 a 和 b 的数据类型，并相应地执行加法或者连接字符串的操作。

如果 sum 函数被调用多次，每次执行时都要检查参数的数据类型是很浪费时间的。此时 TurboFan 就出场了。它会分析监视器收集的信息，如果以前每次调用 sum 函数时传递的参数类型都是数字，那么 TurboFan 就预设 sum 的参数类型是数字类型，然后将其编译为机器指令。

就可以将manysum函数优化为简单的加法:

add eax,ebx;

2.漏洞解析

 

Looking at the commit message, we see that it states the following:

[compiler] Fix a bug in SimplifiedLowering ​ 
SL's VisitSpeculativeIntegerAdditiveOp was setting Signed32 as restriction type even when relying on a Word32 truncation in order to skip the overflow check. This is not sound.

SL的VisitSpeculativeIntegerAdditiveOp将Signed32设置为限制类型，甚至在依赖Word32截断以跳过溢出检查时也是如此。这是不对的。

所以我们知道补丁修改了一个函数：VisitSpeculativeIntegerAdditiveOp,并且还包含有如下注释

+    // Using Signed32 as restriction type amounts to promising there won't be
+    // signed overflow. This is incompatible with relying on a Word32
+    // truncation in order to skip the overflow check.
使用Signed32作为限制类型等于承诺不会有signed溢出。这与依靠Word32截断来跳过溢出检查是不兼容的。
+    Type const restriction =
+        truncation.IsUsedAsWord32() ? Type::Any() : Type::Signed32();

该bug的影响是这样的:引擎承诺不会发生有符号整数溢出，但实际结果是有符号整数溢出确实发生了。

回到回归测试，我添加了自定义的assertTrue和assertFalse函数，以便我可以实际运行它(我相信ClusterFuzz自动做到这一点)。修改后的poc如下:

// Copyright 2020 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
​
// Flags: --allow-natives-syntax
​
function assertTrue(c) {
    if (!c) { throw "Assertion failed"; }
}
​
function assertFalse(c) {
    assertTrue(!c);
}
​
function foo(a) {
  var y = 0x7fffffff;  // 2^31 - 1 (INT_MAX)
​
  // Widen the static type of y (this condition never holds).
  if (a == NaN) y = NaN;
​
  // The next condition holds only in the warmup run. It leads to Smi
  // (SignedSmall) feedback being collected for the addition below.
  if (a) y = -1;
​
  const z = (y + 1)|0;
  return z < 0;
}
​
%PrepareFunctionForOptimization(foo);
assertFalse(foo(true));
%OptimizeFunctionOnNextCall(foo);
assertTrue(foo(false));

关于function foo:

1.变量y被设置为INT_MAX

2.一些TurboFan的特定操作可以触发bug

3.变量z设置为(y+1)|0 与0进行按位或

4.return语句应该在第一次调用foo时返回false(参数a为true，因此y将被设置为-1，这将导致z被设置为y+1 == -1+1 == 0)。

5.对于foo的第二次调用，a将为false，因此z将被设置为y+1 == 0x7fffffff+1 == 0x80000000。根据回归测试，这个加法似乎应该产生负数-2147483648，这应该导致函数返回true，因为这个负数小于0。

然而，当运行这个回归测试时，最终的assertTrue将失败。==>我们可以得出结论，该bug可能导致引擎错误地假设整数溢出没有发生，而实际上它已经发生了

Some question:

• The “static type” of y is widened initially. The question is, how does this work? What is the “static type”, and why does it need to be widened here?y的“静态类型”开始扩大。问题是，这是如何运作的?什么是“静态类型”，为什么这里需要扩大它?

• In the warmup run (i.e the initial call to foo), SignedSmall feedback is collected by setting y to -1. Again, why is this required here? How does this specific line of code collect SignedSmall feedback?在对foo的初始调用中，通过设置y为-1收集SignedSmall反馈。为什么这里需要这个?这一行代码是如何收集SignedSmall反馈的?

• Why is z set to (y + 1)|0? More specifically, why is it bitwise OR’d with 0?为什么z被设为(y + 1)|0?更具体地说，为什么要用0进行位或?

Turbofan优化过程首先会进入Escape Analysis阶段，之后进入SimplifiedLowering阶段，通过正反向遍历确定字节码树(Bytecode Graph Tree)中各节点的输入类型、输出类型、最大取值范围等，其共分为三个⼦阶段Propagate、Retype、Lower。

Unpatched vs Patched Turbolizer graphs

比较一下V8版本和未打补丁版本之间的Turbolizer图，看看补丁对引擎到底有什么影响

当我查看这些图时，我注意到在Escape Analysis阶段(在简化降低阶段Simplified Lowering Phase之前运行)中，这些图看起来是完全相同的。我只会在这里展示相关的部分。

Escape Analysis Phase:

 

图中的差异只显示在简化降低阶段。以下是两个版本的简化降低阶段:

Unpatched Simplified Lowering Phase:

 

Patched Simplified Lowering Phase:

 

显而易见的是，从Escape分析阶段的NumberLessThan节点已经在未补丁版本的简化降低阶段改为Uint32LessThan节点，而它已经在补丁版本的简化降低阶段改为Int32LessThan节点。

该节点用于最终的返回z < 0比较。很大概率，Uint32LessThan节点意味着TurboFan没有注意到整数溢出发生在加法期间，因为它试图将两个数字作为无符号32位整数进行比较。

相比之下，补丁版本的Simplified lower Phase将正确地使用Int32LessThan节点将两个数字作为带符号的32位整数进行比较。这是正确的方法，因为加法确实产生一个负数。

The Simplified Lowering Phase

Simplified Lowering Phase的代码可以在src/compiler/simplified-lowering.cc中发现，Simplified Lowering Phase 在 Escape Analysis Phase逸出分析阶段之后运行

bool PipelineImpl::OptimizeGraph(Linkage* linkage) {
  // [ ... ]
​
  if (FLAG_turbo_escape) {
    Run();
    // [ ... ]
  }
​
  // Perform simplified lowering. This has to run w/o the Typer decorator,
  // because we cannot compute meaningful types anyways, and the computed types
  // might even conflict with the representation/truncation logic.
  //执行简单的降低。这必须在没有Typer装饰器的情况下运行，因为无论如何我们都不能计算有意义的类型，并且计算的类型甚至可能与表示/截断逻辑冲突
  Run(linkage);
​
  // [ ... ]
}

这将调用 SimplifiedLowering::Run，它实际上有三个独立的子阶段:

void Run(SimplifiedLowering* lowering) {
    GenerateTraversal();
    RunPropagatePhase();
    RunRetypePhase();
    RunLowerPhase(lowering);
  }

GenerateTraversal首先将当前图中的每个节点放入一个名为traversal_nodes_的向量中。它是通过从End节点开始执行pre-order遍历，并在访问每个节点时将它们推入临时堆栈来实现这一点的。在访问完所有节点之前，节点不会被推入traversal_nodes__ 向量中

简而言之，这基本上意味着可以从头到尾迭代遍历traversal_nodes_向量，本质上与从上到下遍历Turbolizer图相同

The Propagation Phase传播阶段

在此阶段，traversal_nodes_向量将被反向遍历(即访问的第一个节点将是End节点)，而“截断”则在图中传播。

截断实际上可以被认为是一个附加到节点上的标签。根据特定的条件(如节点的类型等)，截断可能会也可能不会传播到其他节点。The truncations signify what “representation” a node should be restricted to.

可以在TruncationKind枚举中找到定义的截断列表：

enum class TruncationKind : uint8_t {
    kNone,
    kBool,
    kWord32,
    kWord64,
    kOddballAndBigIntToNumber,
    kAny
  };

可以在MachineRepresentation枚举中找到表示的列表:

enum class MachineRepresentation : uint8_t {
  kNone,
  kBit,
  kWord8,
  kWord16,
  kWord32,
  kWord64,
  kTaggedSigned,       // (uncompressed) Smi
  kTaggedPointer,      // (uncompressed) HeapObject
  kTagged,             // (uncompressed) Object (Smi or HeapObject)
  kCompressedPointer,  // (compressed) HeapObject
  kCompressed,         // (compressed) Object (Smi or HeapObject)
  // FP representations must be last, and in order of increasing size.
  kFloat32,
  kFloat64,
  kSimd128,
  kFirstFPRepresentation = kFloat32,
  kLastRepresentation = kSimd128
};

关于节点的表示、截断等信息存储在NodeInfo对象中。每个节点都与一个NodeInfo对象相关联，该对象可以通过在任何节点上调用GetInfo(node)来访问:

---

当简化降低阶段开始时，上面的所有字段将被设置为图中每个节点的默认值(即表示将是kNone，截断将是truncation::None()，etc)。当每个子阶段完成时，字段将被更新。

接下来看一个A simplified example：

We’ll trace the SpeculativeSafeIntegerAdd node as that is the one that contains the bug (based on the patch)

Running d8 with --trace-representation, we get the following output:

---

--{Propagate phase}--
 [ ... ]
 visit #45: SpeculativeNumberBitwiseOr (trunc: truncate-to-word32)
  initial #43: truncate-to-word32
  initial #44: truncate-to-word32
  initial #43: truncate-to-word32
  initial #36: no-value-use
 visit #43: SpeculativeSafeIntegerAdd (trunc: truncate-to-word32)
  initial #39: no-truncation (but identify zeros)
  initial #42: no-truncation (but identify zeros)
  initial #22: no-value-use
  initial #36: no-value-use
 visit #42: NumberConstant (trunc: no-truncation (but identify zeros))
 visit #39: Phi (trunc: no-truncation (but identify zeros))
  initial #32: no-truncation (but identify zeros)
  initial #38: no-truncation (but identify zeros)
  initial #36: no-value-use
 [ ... ]

---

可以看到，SpeculativeNumberBitwiseOr节点将向它的第一个输入(#43,SpeculativeSafeIntegerAdd节点)传播一个Word32截断，而它将不向前两个输入传播截断。

RunPropagatePhase将向后迭代遍历traversal_nodes_向量，并在每个节点上调用PropagateTruncation，然后在所遍历的每个节点上调用VisitNode。

对于SpeculativeSafeIntegerAdd节点，VisitNode调用VisitSpeculativeIntegerAdditiveOp:

  template 
  void VisitNode(Node* node, Truncation truncation,
                 SimplifiedLowering* lowering) {
    // [ ... ]
    switch (node->opcode()) {
      // [ ... ]
      case IrOpcode::kSpeculativeSafeIntegerAdd:
      case IrOpcode::kSpeculativeSafeIntegerSubtract:
        return VisitSpeculativeIntegerAdditiveOp(node, truncation, lowering);
      // [ ... ]
    }
  }

VisitSpeculativeIntegerAdditiveOp是一个有点长的函数，所以我将只显示相关部分

  template 
  void VisitSpeculativeIntegerAdditiveOp(Node* node, Truncation truncation,
                                         SimplifiedLowering* lowering) {
    Type left_upper = GetUpperBound(node->InputAt(0));
    Type right_upper = GetUpperBound(node->InputAt(1));
​
    // [ 1 ]
    if (left_upper.Is(type_cache_->kAdditiveSafeIntegerOrMinusZero) &&
        right_upper.Is(type_cache_->kAdditiveSafeIntegerOrMinusZero)) {
      // [ ... ]
    }
​
    // [ ... ]
    return;
  }

首先，left_upper和right_upper变量本质上就是Turbolizer图上看到的前两个输入节点的类型。在这种情况下，它们是:

 

所以我们有：

left_upper - Phi节点的类型，是NaN | Range(-1, 2147483647)的UnionType。

ight_upper - NumberConstant[1]节点的类型，它是Range(1,1)的RangeType。

接下来，注释[1]处的if分支将不会被接受，因为第一次检查将失败。type_cache_->kAdditiveSafeIntegerOrMinusZero是一个介于Type::MinusZero()和Range(-4503599627370496, 4503599627370496)之间的UnionType，不包括NaN。这将导致left_upper.Is(…)调用返回false。

这实际上回答了第一个问题。通过将y的静态类型设置为NaN, y的静态类型就被扩大了。由于第一个if语句就是因为这个原因而被跳过的，我们可以推断这样做是为了通过if语句(函数在if分支中返回，不会再进一步)。这是由补丁进一步确认的，因为补丁对这个函数的唯一修改是在这个if分支之后。

我们还可以推断什么是“静态类型”。在本例中，静态类型似乎就是Turbolizer图中显示的类型(即先前由Typer Phase键入的类型)。另一方面，反馈类型(在NodeInfo类中跟踪)似乎是一个特定于简化降低阶段的东西。

接下来，我们将看到以下代码，它有助于回答我们的第二个问题:

  template 
  void VisitSpeculativeIntegerAdditiveOp(Node* node, Truncation truncation,
                                         SimplifiedLowering* lowering) {
    // [ ... ]
    NumberOperationHint hint = NumberOperationHintOf(node->op());
    DCHECK(hint == NumberOperationHint::kSignedSmall ||
           hint == NumberOperationHint::kSigned32);
​
    // [ ... ]
    return;
  }

我们看到SpeculativeSafeIntegerAdd节点的NumberOperationHint被存储到hint中，DCHECK确保这个提示要么是kSignedSmall，要么是kSigned32。这告诉我们，为了真正达到这个代码，我们需要SignedSmall或Signed32反馈.

我们可以通过首先修改poc以删除收集SignedSmall反馈的行来验证这一点，然后跟踪代码。首先，如果你查看修改后的poc的Turbolizer图，你会看到一个SpeculativeNumberAdd节点(与SpeculativeSafeIntegerAdd节点不同)将在graph Builder阶段插入:

 

这将使bug不可能触发，因为在简化降低阶段Simplified Lowering Phase，SpeculativeNumberAdd节点没有调用VisitSpeculativeIntegerAdditiveOp。

决定是否插入一个SpeculativeSafeIntegerAdd节点或一个SpeculativeNumberAdd节点的代码可以在JS Type Hint lower reducer中找到.这在图形构建器阶段Graph Builder Phase运行:

 const Operator* SpeculativeNumberOp(NumberOperationHint hint) {
    switch (op_->opcode()) {
      case IrOpcode::kJSAdd:
        if (hint == NumberOperationHint::kSignedSmall ||
            hint == NumberOperationHint::kSigned32) {
          return simplified()->SpeculativeSafeIntegerAdd(hint);
        } else {
          return simplified()->SpeculativeNumberAdd(hint);
        }
      // [ ... ]
    }
    UNREACHABLE();
  }

我们可以看到Ignition正在收集这些反馈:

TNode