Motivation

It is important to setup a debugging environment to gain a deep understanding of software internals and learn how the software behaves when processing different kinds of user-provided input.

At the same time, it is also important to not lose sight of the main goal - to find, exploit, and report an impactful memory-corruption security bug in Chromium.

High-Level Methodology for Learning Software Internals

1. Identify types of software vulnerabilities you want to find.
2. Identify the component where you think such software vulnerabilities will be relevant.
3. Learn about the component’s software architecture if documentation is available.
4. Identify how such a component accepts and processes user input.
5. Identify some code that looks vulnerable and form a hypothesis.
6. Challenge the hypothesis and puppet program execution to try to trigger the type of software vulnerability you thought of in step 1.

The Learning Strategy

Chromium is one of the largest open-source software projects today. As I’ve chosen to focus on memory corruption vulnerabilities, it would be helpful to know how to test for them in the context of this project. We can review some of Chromium’s top reported vulnerabilities in the following page. Some of the older CVEs had PoCs and steps to reproduce the issue along with the impacted Chromium build, etc… This is perfect for learning, so why not take a shot at reproducing one of the most impactful CVEs?

After some digging, I’ve decided to reproduce CVE-2024-5839 as it seemed like some good research to learn from!

CVE-2024-5839 - MiraclePtr Bypass

After reading Google’s bug bounty program, a bypass to MiraclePtr is worth ~ $100,000 USD. This suggests that the bug bounty program maintainers really care about any PoCs and writeups that will bypass such a security mechanism. That page also suggests other restraints for an exploit and writeup to be eligible for a reward. It is important to also keep in mind the build and runtime environment constraints for testing and reproducing the exploit such that they align with the bug bounty criteria!

From reading the issue where the PoC and steps to reproduce the exploit was posted, they indeed rewarded the researcher with $100,115 USD! This issue was also very clear and easy to follow which also made it look like an excellent learning opportunity!

Why Reproduce Some Old Work?

When starting security research in any new project, my preferred way is to learn by example and use those examples as inspiration for further research.

Realistically, this would let me be more hands-on with the project, learn how to give it various inputs, observe how it behaves, and debug it without “starting from scratch”.

Research Environment Setup

Follow the documentation on this page.

Make sure you have enough disk space (100+ GB). Having 16+GB RAM is also helpful. The documentation recommends installing the debugging/development environment on an Ubuntu Linux system.

The source download and build process may very well take over an hour, so you’ll have to be patient!

Building the Vulnerable Version

Building Chromium should be pretty straight forward as you can just follow the instructions documented here. However, remember that is 2025 and we will need an older build of Chromium to walk through the exploit.

The following documentation suggests that the depot_tools checkout should be roughly around the same date of the commit of the software you are trying to build. As such, it is recommended to downgrade your depot_tools so that they will be compatible with the version you’re building.

cd ~/chromium/src

# Checkout desired version (e.g., vulnerable version)
git fetch origin refs/branch-heads/6367
git checkout -b chromium-124 245920a2b1275307b0072193a79e8fb11a8e1af8

# Sync dependencies for this version, purging any artifacts from mismatching versions
gclient sync -D --force --reset

# Regenerate build config with parameters suggested by the triager in https://issues.chromium.org/issues/340122160
gn gen out/asan --args='
  is_debug=true
  symbol_level=2
  is_asan=true
  dcheck_always_on = false
  enable_ipc_fuzzer = true
  is_asan = true
  is_component_build = false
  is_lsan = true
  use_remoteexec = false
  v8_enable_verify_heap = true
'

# Build Chromium
ninja -C out/debug_asan chrome

use_remoteexec is false because this is restricted to Google employees and is used for parallel builds on distributed infrastructure.

The exploit author reproduced the vulnerability against Chromium release version 124.0.0.0, so we should check out that version. We can think of version 124.0.0.0 as milestone 124 as described here. As we can see, milestone 124 is the HEAD of refs/branch-heads/6367.

In the ~/chromium/src directory, we should list the branches to find the Chromium version that matches milestone 124.

git fetch origin refs/branch-heads/6367
git checkout -b chromium-124 245920a2b1275307b0072193a79e8fb11a8e1af8

Note that 245920a2b1275307b0072193a79e8fb11a8e1af8 is the commit at the head of refs/branch-heads/6367.

Applying the Patch

The exploit’s author provided all code required for the PoC in this issue - https://issues.chromium.org/issues/340122160

Following their instructions, everything seemed to patch well except for base/allocator/partition_allocator/src/partition_alloc/in_slot_metadata.h. Maybe the full patching process will work for you, but I had to patch this part manually. You will also need to add ./content/browser/permissions/uaf111.h and ./content/browser/permissions/uaf111.cc.

At this point, just go ahead and rebuild Chromium. In my next post, we’ll be tracing through the steps to reproduce the exploit!

Possible Next Steps

• Since MiraclePtr is one of the base low-level pillars that Chromium stands on, it might be worth figuring out how to build just enough components you want to test (the Chromium build takes hours!!)
• Review some other memory-corruption vulnerabilities and learn from them. Use this Chromium issue hotlist for inspiration.