What is CVE-2024-5839?

CVE-2024-5839 was the first publicly acknowledged bug report to bypass Chrome’s MiraclePtr defense via a use-after-free (UAF) vulnerability. It is worth noting that this vulnerability was patched in Chromium version 126.0.6478.54.

Since 2022, the Chromium team has invested heavily in UAF mitigations via MiraclePtr. Many historical UAFs involved raw pointers, prompting Chromium to introduce MiraclePtr in their custom memory allocator PartitionAlloc. Among multiple MiraclePtr implementations, Google selected BackupRefPtr to mitigate the exploitability of UAF vulnerabilities, which is enabled in non-ASAN release builds.

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?

Motivation

I’ve always had an interest for finding security vulnerabilities in widely-used complex software with a large attack surface. Web browsers seem to be an excellent target for this as they are open source and widely documented. They have an array of components with a complex software architecture. This makes their attack surface quite large. Since there are many browsers, I decided to pick the most widely adopted one - Chromium.

Bypassing Antivirus in 2021

Before You Start

Disable automatic malware sample submission on your test machine. Trust me, it will make your life easier if you make any mistakes trying to bypass AV software and get caught. Before proceeding, you will need a Windows development machine with Visual Studio.

The tool we will be using will be Alaris which leverages antivirus evasion techniques such as:

• Shellcode Encryption (AES-CBC 256)
• Direct x86 Syscalls (Does not use NtDLL.dll)
• Prevents 3rd party (non-Microsoft Signed) DLL’s from hooking or injecting both the parent and child processes.
• Parent Process ID spoofing
• Overwrites its own shellcode after execution.

Alaris’s creator has written an excellent blog post on all the technical details for how this shellcode loader works and how to use it.

Tenable CTF 2021 - The Friendzone

The friendzone was the 250 point pwn challenge from Tenable CTF 2021 which involved finding an obscure vulnerability in C++ code. The challenge required the pwner to bypass auhtorization countermeasures to read a VIP’s profile. Solving this challenge is proof that buffer overflow vulnerabilities are still applicable in hardened C++ apps and that one does not necessarily need to achieve remote execution to take control over the business logic of an application.

Summary

Fusion Level 04 was a tough challenge from exploit excercises that required the pwner to implement a timing attack and defeat modern countermeasures implemented by the compiler (stack canary, PIE, and non-executable stack) and operating system (ASLR). This was the most realistic binary exploitation challenge I have done yet which proves that in certain circumstances, buffer overflows are still exploitable today. You can read more on the challenge here.