One day short of a full chain: Real world exploit chains explained

When it comes to security research, the path from bug to vulnerability to exploit can be a long one. Security researchers often end their research journey at the “Proof of Concept” (PoC) stage. A PoC is intended to trigger or exploit a vulnerability to demonstrate risk and impact, but without any real expectation of reliably compromising a targeted system.

But how do such PoC research tools relate to the sophisticated attacks that make news headlines? Just like any other software development effort, there’s a world of difference between a first effort PoC and attack tooling that can be used to compromise people in the real world.

Below, GitHub Security Lab tells the story of how we combined multiple vulnerabilities we’d reported in various Google and Qualcomm Android system components, and how we went from exploiting the Chrome browser to ultimately elevating attacker access to kernel code execution on an Android device.

Why would we go through this effort? It’s important to measure how well system mitigations stand up to modern attacker know-how. This allows the security research community to identify current gaps in systems security and to iterate on improving those defenses.

From proof of concept to full exploit chain

In the real world, an attacker often has to combine multiple vulnerabilities and stitch together many different mitigation bypasses to reliably get from point A to point B.

Modern browsers heavily rely on sandboxing and other security mitigations to try and mitigate the impact of vulnerabilities by containing would-be attackers in a jailed-off process environment to keep them locked away from wider system access even if they manage to compromise the browser itself.

To go from modern browser exploit to privileged system access, attackers have to hop multiple system defences.

In attacker jargon, this sequenced fence hopping is referred to as building a full exploit chain: Combining multiple vulnerabilities into a chain of attack that ends with the attacker in a privileged position on the targeted system.

To break down the various components of our attack chain, the GitHub Security Lab team worked our way back from full Android kernel exploitation to Chrome sandbox escape to Chrome renderer exploit. We essentially solved a real world attacker’s conundrum by starting at their intended goalpost, and then walked our way back to the start of any modern browser exploit chain: a user visiting a malicious webpage.

Luckily, some crucial parts of this attack chain never made it out of Chrome Beta before we reported the vulnerabilities (throughout 2020), and all the vulnerabilities detailed here have since been patched with ample time provided for end users to update their devices.

Part 1: Attacking the Android kernel through a Qualcomm driver flaw

In the first part of the attack chain research, we exploited a flaw reported as GHSL-2020-375 (CVE-2020-11239) to elevate privileges on Android devices that use the widespread Qualcomm chipset. This includes such devices as the Google Pixel 4, Samsung A71, Samsung S20, and many other popular Android handsets.

We detail the exploitation of a so-called Use After Free (UAF) vulnerability in the Qualcomm Kernel Graphics Support Layer (KGSL). UAF vulnerabilities are a type of memory mismanagement flaw that allow attackers to control the contents of objects in system memory and then supply attacker-controlled memory contents to system software interacting with those objects.

CVE-2020-11239, which is the Common Vulnerabilities and Exposure (CVE) identifier assigned to this vulnerability, provided all the features an attacker requires to fully elevate their system privileges from the context of an Android application, such as a compromised Chrome browser, and as such we could use it to hop the fence from browser to privileged system access.

Read the deep dive here: One day short of a full chain: Part 1 – Android Kernel arbitrary code execution

Part 2: Escaping the Chrome sandbox

We’d compromised the kernel, and were now ready to work our way back through the attack chain. In part two, we detail a flaw reported as GHSL-2020-165 (CVE-2020-16045) in the Beta version of Chrome. This abuses a memory management flaw in Chrome payment processing code that enabled an attacker to escape from the sandboxed Chrome renderer process, which affords them the app privileges required to exploit the Qualcomm kernel vulnerability detailed in part one.

Read the deep dive here: One day short of a full chain: Part 2 – Chrome sandbox escape

Part 3: Exploiting the Chrome renderer

In the final installment of the full chain attack series, we arrive at the tip of the exploit chain spear and detail the exploitation of a flaw reported as GHSL-2020-167 (CVE-2020-15972). This vulnerability was present in Chrome’s WebAudio handling code and again involved a UAF flaw that allowed an attacker to achieve arbitrary code execution in the context of the sandboxed Chrome Renderer. In a real world attack, this is where the attack chain begins, and this is the first bug that would be exploited when a victim visits a malicious site.

Read the deep dive here: One day short of a full chain: Part 3 – Chrome renderer RCE

Fitting the pieces together

Combining these three components ultimately resulted in a scenario where affected Android users could be fully compromised by visiting a malicious website.

The three attack components detail a complicated journey of exploitation and mitigation bypass that closely mimics the kind of research and effort real world attackers are putting into their attack chains.

There is a lot of discussion about the level of resources required to pull off such a sophisticated attack in the modern age. This often results in attack attribution hyperbole that is quick to point at state-sponsored groups. Yet, this entire attack chain was put together by a single GitHub Security Lab researcher building on open research material with no particular resources beyond focused research time.

This is another reason why performing this kind of research is important. It provides a reality check on some of the intuitions and assumptions that come with seeing a real world exploit in the wild. It takes advanced systems exploitation out of the realm of magic and offers tangible examples of where current system mitigations are falling short and practical advice on how they might be improved.

---

Follow GitHub Security Lab on Twitter for the latest in security research.