[TSSCTG] Sample Problems

The following challenge problems are provided for inspiration. Proposals are welcome to explore solutions to the provided challenge problems, or to come up with their own challenge problems and solutions within the scope of the grant.

Sample Problem #1 -- Vulnerabilities in JIT Compilers

Just-in-time (JIT) compiler technology is an integral part of many browsers, but from a security research perspective, there had been insufficient attention. Potential attack surfaces include implementation errors in JIT internals, mismatch assumptions or implicit assertions between JIT compiler and the rest of browser, and unintended side-effects of JIT code execution. Recent works demonstrate that the risks are real and more works are needed. A useful research output could be, but not limited to, a rigorous and demonstratively effective analysis or testing tool or framework for finding vulnerabilities in JIT compilers.

Example #1 Consider the following code snippet from a buggy version of the Chrome Browser's Javascript JIT engine (TurboFan):

Type* Typer::Visitor::JSCallTyper(Type* fun)
{
        ...;
        switch (function->builtin_function_id()) {
                ...;
                case kStringLastIndexOf:
                return Range(-1.0, String::kMaxLength - 1.0);
        ...;
}

The buggy snippet concerns the Javascript S.lastIndexOf(T) builtin function. Here, the builtin function returns the last index of sub-string T in string S if it exists, else it returns -1 if T is not a sub-string. The buggy snippet incorrectly assumes that the maximum value returned by the builtin function is one less than the maximum string length (highlighted). In reality, the function may return a value equal to the maximum string length for the special case where T is the empty string (T="").

Since the output of JSCallTyper is used by the JIT engine for bounds-check removal optimization, out-of-bounds memory access from Javascript code is now possible:

var maxLength = 268435440; // = 2**28 - 16
var buf = new Uint8Array(maxLength + 1);
function hax()
{
        var s = "A".repeat(maxLength);

        // Compiler: i = Range(-1, maxLength - 1)
        // Reality: i = Range(-1, maxLength)
        var i = s.lastIndexOf("");

        // Compiler: i = Range(0, maxLength)
        // Reality: i = Range(0, maxLength + 1)
        i += 1;

        // Compiler: Bounds-check removed
        // Reality: OOB access!
        return buf[i];
}

This example shows how bugs in the JIT engine can be promoted to vulnerabilities in Javascript code.

[Chrome Issue #762874] [example credit]

Sample Problem #2 -- Hardware Side Channels

Recently discovered hardware side channel attacks, such as Spectre and Meltdown, can bypass normal memory protections allowing for the leakage of private/sensitive information. Vulnerable processors are ubiquitous, and mitigations are difficult or costly, meaning that such attacks have a real world impact. Recent works have also discovered new variants of attacks, demonstrating that the risks are real. A useful research output could be, but not limited to, a rigorous and demonstratively effective analysis for the detection or mitigation of hardware side channel attacks.

Example #2 Code exhibiting weakness to Spectre-style hardware side channel attacks can occur naturally in practice. For example, consider the following code snippet from the FreeRADIUS project:

static int fr_trie_path_lcp(..., int keylen2, ...)
{
        ...
        if (end_bit > keylen2) end_bit = keylen2;
        ...
        e2 = end_bit;
        ...
        xor <<= s2;
        xor |= lcp_end_bit[e2 - s2];
        lcp = xor2lcp[xor];
        ...
}

Here, the highlighted if-statement implements a bounds check, but the CPU may speculatively execute states after the check. However, the CPU may mis-predict the outcome of the check, and specularly execute the subsequent statements (highlighted) which now include a possibly out-of-bound (OOB) read (lcp_end_bit). Furthermore, the speculative OOB value (xor) is used in another array access (xor2lcp), leading to the possibility of the information about the speculative OOB value leaking via side channels, in this case the CPU cache. Although this code exhibits a potentially vulnerable pattern, whether or not it is practically exploitable is another possible research question.

[FreeRADIUS]

Sample Problem #3 -- Bugs in Mobile Applications

Mobile phones are ubiquitous, and the potential mixture of buggy apps and sensitive data present an attractive target. A useful research output could be, but not limited to, a rigorous and demonstratively effective analysis for the detection or mitigation of mobile application attacks.

Example #3 The following code is an example of a privilege escalation vulnerability in an android system app. Here, a malicious app without the SEND_SMS permission can send any message to any destination by attacking the vulnerability. To do so, the malicious app places the destination and content into the draft box, and broadcasts an intent with correct action ...MESSAGE_SENT and result error code RESULT_ERROR_RADIO_OFF. This vulnerable system app will catch the intent and reach the following conditional branch (highlighted). The malicious SMS will be moved to a queue and sent later.

private void handleSmsSent(Intent intent, int error) {
    ...
    if ((mResultCode == SmsManager.RESULT_ERROR_RADIO_OFF) || ...) {
        registerForServiceStateChanges();
        // put in the queue and send it later.
        Sms.moveMessageToFolder(this, uri, Sms.MESSAGE_TYPE_QUEUED, error);
    }
    ...
}

By attacking the vulnerable system app, the malicious app can send any sensitive data without user's knowledge or consent.

[link] [link]