Kuboid
Open Luck·Kuboid.in

ReVault! Compromised by your Secure SoC

DEFCONConference672 views42:016 months ago

This talk demonstrates a series of vulnerabilities in the Dell ControlVault 3 (CV3) system-on-chip (SoC) that allow for full system compromise, including privilege escalation to SYSTEM and persistent firmware modification. The researcher details how to bypass secure boot and authentication mechanisms by exploiting heap-based vulnerabilities and improper input validation in the firmware's communication interface. The presentation highlights the risks of trusting proprietary hardware security components and provides a methodology for reverse-engineering and exploiting embedded systems. The researcher successfully demonstrates a physical attack vector and a software-based exploit to achieve code execution on the secure SoC.

Bypassing Secure Boot: How to Turn a Dell ControlVault SoC into a Permanent Implant

TLDR: Researchers at DEF CON 2025 demonstrated that the Dell ControlVault 3 (CV3) system-on-chip is vulnerable to heap-based memory corruption and type confusion, allowing for full system compromise. By exploiting these flaws, an attacker can achieve code execution on the secure SoC, bypass Windows Hello authentication, and install persistent firmware implants. This research underscores the danger of trusting proprietary hardware security components that lack rigorous, transparent security auditing.

Hardware security modules are often treated as black boxes, assumed to be impenetrable by design. The reality, as Philippe Laulheret demonstrated at DEF CON 2025, is that these components are just as susceptible to classic memory corruption bugs as any other piece of software. The Dell ControlVault 3 (CV3) is a Broadcom BCM5820x based system-on-chip responsible for handling sensitive operations like fingerprint matching and credential storage. Because it sits outside the main OS kernel, it is often overlooked during standard penetration testing engagements.

The Anatomy of the ControlVault Compromise

The research focuses on the communication interface between the Windows host and the CV3 firmware. The host interacts with the SoC via a series of IOCTL commands, which are processed by a high-level DLL. The firmware itself runs on an RTOS, and the communication protocol relies on a Tag-Length-Value (TLV) structure.

The vulnerability stems from the firmware's handling of these TLV structures. Specifically, the firmware fails to properly validate the size and type of parameters passed from the host. By crafting malicious IOCTL requests, an attacker can trigger heap-based buffer overflows and type confusion bugs within the firmware's memory space.

One of the most critical findings is the lack of a signature check for the application firmware during the boot process. While the bootloader verifies the initial stages, the application firmware itself can be modified and re-flashed if an attacker can gain sufficient control over the communication interface. This allows for the installation of a persistent, malicious implant that survives OS re-installs.

Exploiting the Heap

To achieve code execution, the researcher identified a session-handling vulnerability. The cv_open function allocates memory on the heap and returns a pointer to the user as a session handle. Because the firmware does not implement proper address space layout randomization (ASLR) or stack cookies in this context, the heap is predictable.

By using the cv_create_object function, an attacker can place arbitrary data on the heap. Combined with a heap-based free vulnerability—triggered by manipulating the session handle—the researcher was able to perform an arbitrary free operation. This is a classic primitive for heap exploitation.

# Simplified example of the heap manipulation logic
# The attacker uses the session handle to trigger an arbitrary free
def trigger_arbitrary_free(handle):
    # This function calls the vulnerable CV_CLOSE IOCTL
    # which performs a free on the provided handle
    dll.cv_close(handle)

By overlapping objects on the heap, an attacker can modify the metadata of a legitimate object, leading to a controlled write or execution flow redirection. The researcher demonstrated this by targeting the cv_fingerprint_identify function. By patching the firmware to always return a successful match, they effectively bypassed Windows Hello, allowing any fingerprint—or even a piece of green onion—to unlock the system.

Real-World Pentesting Implications

For a penetration tester, this research changes the threat model for any engagement involving Dell hardware. If you have local access to a machine, you are no longer limited to attacking the OS. You can now target the hardware security layer directly.

During an engagement, you should look for the BrcmStorageAdapter.dll and other Broadcom-related services. These are the primary interfaces for the ControlVault. If you can interact with these services, you can potentially escalate privileges from a standard user to SYSTEM. The impact of such an exploit is total system control, as the implant operates at a level below the operating system's security controls.

Defensive Considerations

Defending against this class of vulnerability is difficult because the flaw lies in the proprietary firmware of the hardware itself. The most effective mitigation is to ensure that all firmware updates provided by the vendor are applied immediately. Dell has released advisories addressing these issues, such as DSA-2025-053, which patch the specific CVEs identified in this research, including CVE-2025-24311 and CVE-2025-24919.

Beyond patching, organizations should implement strict physical security policies for high-value assets. Since the attack requires either local software access or physical access to the internal USB headers, preventing unauthorized physical access is a necessary layer of defense.

The research serves as a stark reminder that hardware security is not a magic bullet. As we continue to push more security logic into isolated SoCs, we are simply moving the attack surface, not eliminating it. Researchers and developers must demand more transparency from hardware vendors regarding the security of these embedded components. If you are working on a red team engagement, start looking at the hardware interfaces. You might find that the most secure part of the machine is actually the most vulnerable.

Talk Type
research presentation
Difficulty
expert
Has Demo Has Code Tool Released


DEF CON 33 Main Stage Talks

98 talks · 2025
Browse conference →
Premium Security Audit

We break your app before they do.

Professional penetration testing and vulnerability assessments by the Kuboid Secure Layer team. Securing your infrastructure at every layer.

Get in Touch
Official Security Partner
kuboid.in