Exploits / Vulnerability Discovered : 2019-04-24 |
Type : remote |
Platform : multiple
This exploit / vulnerability Google chrome 72.0.3626.121 / 74.0.3725.0 newfixeddoublearray integer overflow is for educational purposes only and if it is used you will do on your own risk!
// If estimated number of elements is more than half of length, a
// fixed array (fast case) is more time and space-efficient than a
// dictionary.
bool fast_case = is_array_species &&
(estimate_nof * 2) >= estimate_result_length &&
isolate->IsIsConcatSpreadableLookupChainIntact(); // ***4***
https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-array.cc?rcl=9ea32aab5b494eaaf27ced51a6608e8400a3c4e5&l=1378
MaybeHandle<JSArray> Fast_ArrayConcat(Isolate* isolate,
BuiltinArguments* args) {
[...]
int result_len = 0;
{
DisallowHeapAllocation no_gc;
// Iterate through all the arguments performing checks
// and calculating total length.
for (int i = 0; i < n_arguments; i++) {
Object arg = (*args)[i];
if (!arg->IsJSArray()) return MaybeHandle<JSArray>();
if (!HasOnlySimpleReceiverElements(isolate, JSObject::cast(arg))) {
return MaybeHandle<JSArray>();
}
// TODO(cbruni): support fast concatenation of DICTIONARY_ELEMENTS.
if (!JSObject::cast(arg)->HasFastElements()) {
return MaybeHandle<JSArray>();
}
Handle<JSArray> array(JSArray::cast(arg), isolate);
if (!IsSimpleArray(isolate, array)) { // ***6***
return MaybeHandle<JSArray>();
}
// The Array length is guaranted to be <= kHalfOfMaxInt thus we won't
// overflow.
result_len += Smi::ToInt(array->length());
DCHECK_GE(result_len, 0);
// Throw an Error if we overflow the FixedArray limits
if (FixedDoubleArray::kMaxLength < result_len || /// ***7***
FixedArray::kMaxLength < result_len) {
AllowHeapAllocation gc;
THROW_NEW_ERROR(isolate,
NewRangeError(MessageTemplate::kInvalidArrayLength),
JSArray);
}
}
}
return ElementsAccessor::Concat(isolate, args, n_arguments, result_len);
}
https://cs.chromium.org/chromium/src/v8/src/builtins/builtins-array.cc?rcl=9ea32aab5b494eaaf27ced51a6608e8400a3c4e5&l=244
BUILTIN(ArrayPrototypeFill) {
[...]
// 2. Let len be ? ToLength(? Get(O, "length")).
double length;
MAYBE_ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
isolate, length, GetLengthProperty(isolate, receiver)); // ***8***
// 3. Let relativeStart be ? ToInteger(start).
// 4. If relativeStart < 0, let k be max((len + relativeStart), 0);
// else let k be min(relativeStart, len).
Handle<Object> start = args.atOrUndefined(isolate, 2);
// 5. If end is undefined, let relativeEnd be len;
// else let relativeEnd be ? ToInteger(end).
// 6. If relativeEnd < 0, let final be max((len + relativeEnd), 0);
// else let final be min(relativeEnd, len).
Handle<Object> end = args.atOrUndefined(isolate, 3);
// Make sure COW arrays are copied.
if (IsSmiOrObjectElementsKind(Subclass::kind())) {
JSObject::EnsureWritableFastElements(receiver);
}
// Make sure we have enough space.
uint32_t capacity =
Subclass::GetCapacityImpl(*receiver, receiver->elements());
if (end > capacity) {
Subclass::GrowCapacityAndConvertImpl(receiver, end); // ***10***
CHECK_EQ(Subclass::kind(), receiver->GetElementsKind());
}
|NewFixedDoubleArray| doesn't expect the |length| argument to be negative (there's even a DCHECK for
that), as it would pass the maximum length check[1] and cause an integer overflow when computing the
size of the backing store[2]. The undersized backing store then might be used for out-of-bounds
access. It turns out there are at least two methods that allow passing negative values to
|NewFixedDoubleArray|.
1. Concat
The implementation of |Array.prototype.concat| in V8 has quite a few fast code paths that deal with
different kinds of arguments. The structure roughly looks like:
The relevant code path for this issue is the packed double array case inside |Slow_ArrayConcat|.
The method uses an unsigned variable for computing the result array length and caps it at
|kMaxElementCount|[3], i.e., at 0xffffffff. Then the value of the variable gets converted to a
*signed* type and passed to |NewFixedDoubleArray|[5] provided that the |fast_case| condition is
satisfied[4], and the estimated array type is PACKED_DOUBLE. Thus, any value in the range
[0x80000000, 0xffffffff] could pass the length check and trigger the overflow.
That still means an attacker has to make the method iterate through more than two billion array
elements, which might seem implausible; actually, the whole process takes just a couple of seconds
on a modern machine and has moderate memory requirements because multiple arguments can refer to the
same array.
Also, |ArrayConcat| calls |Fast_ArrayConcat| in the beginning, and the fast method has a more strict
length check, which might throw an error when the result length is more than |FixedDoubleArray::
kMaxLength|[7]. So, the attacker has to make |Fast_ArrayConcat| return early without triggering the
error. The easiest way to achieve that is to define an additional property on the array.
The bug in |concat| allows writing data beyond the bounds of an array, but it's difficult to limit
the size of the OOB data to a sane value, which makes the exploitation primitive less useful.
So, I've spent some time looking for variants of the issue, and found one in |Array.prototype.fill|.
|ArrayPrototypeFill| initially obtains the length of an array[8] and uses that value to limit the
|start| and |end| arguments. However, a later call to |GetRelativeIndex|[9] might trigger a
user-defined JS function, which could modify the length. Usually, that's enough to cause OOB
access, so |FastElementsAccessor::FillImpl| double-checks that the capacity of the array is not less
than |end| and might call |GrowCapacityAndConvertImpl|[10], which in turn might call
|NewFixedDoubleArray|. The issue here is that there's no check that |end| is small enough to fit in
a signed type; therefore the same overflow leading to the allocation of an undersized backing store
could occur.
Exploitation:
Unlike |concat|, |fill| conveniently allows limiting the size of the OOB block by modifying the
|start| argument. The exploit forces the method to return an array whose length value is bigger than
the actual size of the backing store, which is essentially a ready-to-use OOB read/write
exploitation primitive. The rest is just copied from https://crbug.com/931640.
<script>
let data_view = new DataView(new ArrayBuffer(8));
reverseDword = dword => {
data_view.setUint32(0, dword, true);
return data_view.getUint32(0, false);
}
let oob_access_array;
let ptr_leak_object;
let arbirary_access_array;
let ptr_leak_index;
let external_ptr_index;
let external_ptr_backup;
const MARKER = 0x31337;
VERSION
Google Chrome 72.0.3626.121 (Official Build) (64-bit)
Google Chrome 74.0.3725.0 (Official Build) canary
I'd recommend changing |NewFixedDoubleArray| so it throws an OOM error on negative values, the same
way as the similar |AllocateRawFixedArray| function currently does.
Google chrome 72.0.3626.121 / 74.0.3725.0 newfixeddoublearray integer overflow