Technical Analysis of the Pegasus Exploits on iOS

arr) will not be explicitly protected from deallocation by <strong>the</strong> MarkedArgumentBuffer during
garbage collection.
When defineOwnProperty() is called for <strong>the</strong> length property, it will attempt to convert <strong>the</strong> value
(not_number) to a number. As part <strong>of</strong> this code path, <strong>the</strong> toString() method will be called,
allowing <strong>the</strong> last two references to <strong>the</strong> arr JSArray to be removed. Once removed, this JSArray
is no longer marked, and <strong>the</strong> next garbage collection pass will deallocate <strong>the</strong> object. <strong>Pegasus</strong>
creates memory pressure (allocates a large amount <strong>of</strong> memory) within <strong>the</strong> toString() method in
an attempt to force garbage collection to run (and deallocate <strong>the</strong> arr object).
var attempts = new Array(4250000);
var pressure = new Array(100);
...
not_number.toString = function() {
...
for (var i = 0; i < pressure.length; i++) {
pressure[i] = new Uint32Array(262144);
}
var buffer = new ArrayBuffer(80);
var uintArray = new Uint32Array(buffer);
uintArray[0] = 0xAABBCCDD;
for (i = 0; i < attempts.length; i++) {
attempts[i] = new Uint32Array(buffer);
}
}
Each <strong>of</strong> <strong>the</strong> 4.25 million Uint32Arrays allocated for <strong>the</strong> attempts array use <strong>the</strong> same backing
ArrayBuffer. These objects are used to attempt to reallocate a series <strong>of</strong> Uint32Arrays into <strong>the</strong>
same memory referenced by <strong>the</strong> JSArray object (arr).
Once complete, <strong>the</strong> exploit checks to see whe<strong>the</strong>r garbage collection was successfully
triggered.
var before_len = arr.length;
Object.defineProperties(target, props);
stale = target.stale;
var after_len = stale.length;
if (before_len == after_len) {
throw new RecoverableException(8);
}
If <strong>the</strong> length <strong>of</strong> <strong>the</strong> JSArray remains <strong>the</strong> same it means that ei<strong>the</strong>r garbage collection was not
triggered or that none <strong>of</strong> <strong>the</strong> allocated Uint32Arrays were allocated into <strong>the</strong> same address as <strong>the</strong>
stale object. In <strong>the</strong>se cases, <strong>the</strong> exploit has failed and <strong>the</strong> exploit is retried.
Acquiring an arbitrary read/write primitive
Assuming <strong>the</strong> exploit has succeeded to this point, <strong>the</strong>re are now two objects <strong>of</strong> different types
that are represented by <strong>the</strong> same memory. The first is <strong>the</strong> (now stale) JSArray, and <strong>the</strong> second
is one <strong>of</strong> <strong>the</strong> many Uint32Arrays that were allocated (in fact, <strong>the</strong> underlying templated type is
JSGenericTypedArrayView). By reading from and writing to <strong>of</strong>fsets into <strong>the</strong> stale object, member
Page 8