ReVault! Compromised by your Secure SoC

ReVault! Compromised by your Secure SoC

Speakers: Philippe Laulheret, Senior Vulnerability Researcher, Cisco Talos

Conference: Hexacon

YouTube: https://www.youtube.com/watch?v=DKYdC6WAV5A

Overview

In this Hexacon presentation, Philippe Laulheret, a Senior Vulnerability Researcher at Cisco Talos, unveiled a series of critical vulnerabilities affecting Dell's ControlVault 3 and ControlVault 3 Plus secure system-on-chip (SoC) solutions. Laulheret's research, part of his work at Cisco Talos focusing on Windows embedded systems, demonstrates how a seemingly "secure" hardware component designed to protect sensitive data and manage security peripherals can be fully compromised, leading to permanent firmware modification, login bypasses, and even system-level privileges on the host operating system.

The ControlVault platform, present in tens of millions of Dell Latitude and Precision business laptops, integrates hardware, firmware, and software to handle secure functions like fingerprint readers, smart card readers, and NFC. Laulheret's investigation exposed deep-seated design flaws and implementation weaknesses, some of which appear to date back over 15 years to ControlVault 1. The talk meticulously details the process of reverse engineering the undocumented firmware, chaining multiple vulnerabilities from heap corruptions to stack overflows and host-side deserialization issues, ultimately achieving arbitrary code execution on both the SoC and the host, and fundamentally undermining the trust placed in the secure hardware.

This research is particularly significant as it highlights the often-overlooked attack surface presented by embedded secure elements within mainstream computing devices. Despite being marketed as secure, these components frequently lack the robust security mitigations (like ASLR, DEP, and stack cookies) common in modern operating systems, making them ripe targets for sophisticated attackers. The findings underscore the critical need for thorough security audits of all components in the supply chain, especially those intended to be the root of trust, and provide actionable intelligence for both vendors and defenders to improve the security posture of millions of devices.

Background

▶ Watch: Introduction to ReVault! and Secure SoC compromise (0:00)

Dell's ControlVault is presented as a "unified secure hub" (USSH) responsible for managing various security peripherals such as fingerprint readers, smart card readers, and NFC devices. More critically, it's designed to provide secure storage for secrets, utilizing an encrypted flash chip. The specific model targeted in this research is ControlVault 3, built around a Broadcom BCM58202 ARM chip running a real-time operating system (RTOS) firmware. This solution is widely deployed in Dell's business-oriented Latitude and Precision laptop lines, with an estimated tens of millions of affected devices. Older versions, ControlVault 1 and 2, also exist, and some identified vulnerabilities appear to be inherited from these earlier iterations, suggesting a long-standing architectural weakness.

Laulheret's journey into ControlVault began with a simple observation: system binaries related to Broadcom's ControlVault, specifically a DLL imported by do_stuff.exe and a service running at SYSTEM level, were conspicuously lacking Address Space Layout Randomization (ASLR). This immediately flagged the component as a potentially vulnerable target. The lack of ASLR in a SYSTEM process is a significant security weakness, simplifying exploitation by making memory addresses predictable.

Given the absence of public documentation for ControlVault, the initial research phase involved extensive reverse engineering. Key resources included:

1. Linux Host-Side APIs Repository: A public repository containing the Linux host-side APIs for ControlVault. Crucially, these binaries were compiled with debug symbols, providing invaluable insights into data structures, enums, and function prototypes shared with the firmware. This significantly accelerated the understanding of the internal communication protocol and command structures.
2. Certification Documents: While not providing deep technical details, certification documents for the SoC's cryptography module offered hints about the system's operation and definitions for acronyms like SBI (Secure Boot Image), which proved useful later.
3. Installer File Extraction: Extracting files from the Dell ControlVault installer revealed a wealth of components: USB drivers, peripheral stacks (fingerprint, smart card, NFC), Windows services, and most importantly, the firmware files. The presence of an unencrypted SBI and an encrypted "Citadel" application firmware hinted at the boot process and the need to decrypt the main application.

The overall system architecture involves the host (Windows) communicating with the ControlVault firmware over an internal USB connection. A USB driver on the host converts userland DeviceIoControl calls into USB packets for the firmware. Higher-level functions, termed CV commands (e.g., CV_Open, CV_Close, CV_CreateObject), are implemented in Broadcom DLLs, exposing a large attack surface with approximately 150 commands. The firmware, in turn, has a CV_Manager_Command dispatcher to handle these incoming commands.

Security mitigations on the Windows side were noted as inconsistent: no ASLR for certain Broadcom services, but Data Execution Prevention (DEP) was present. Stack cookies were hit-or-miss. On the firmware side, the situation was even more dire: while execution-in-place (XIP) from encrypted flash was a neat feature, there was no ASLR and no stack cookies. DEP was "questionable," as attempts to jump on the stack would crash, but critically, read-execute regions were mapped, allowing for easy shellcode execution if instruction pointer control was gained. This stark lack of mitigations made the firmware an attractive target.

Key Findings

▶ Watch: Research approach: leveraging Linux debug symbols for reversing (2:40)

The research uncovered a comprehensive set of vulnerabilities across the ControlVault hardware, firmware, and host-side software components. These findings collectively led to a complete compromise of the "secure" SoC.

1. Firmware Decryption Weaknesses:

• The Secure Boot Image (SBI), responsible for bootstrapping the main application firmware, uses hardcoded default keys and IVs for initial decryption if no specific keys are present. This allows an attacker to decrypt the application firmware without prior knowledge of device-specific secrets.
• The decryption process employs AES-CBC with a custom IV computation function that is predictable, based on the memory address of the data chunk being decrypted. This predictability, combined with the default keys, enables full decryption and re-encryption of the firmware.

1. Heap Vulnerabilities in CV Commands:

• The CV_Open command, which establishes a session with the firmware, returns a direct pointer to the session object on the firmware heap as its handle. This leaks critical heap addresses to the attacker.
• The CV_Close command validates a session simply by checking if the provided handle (a pointer) is within the heap and contains a specific "SE_SS" session tag. This simplistic validation enables an arbitrary free primitive: by crafting a fake session object on the heap (using CV_CreateObject) and placing the "SE_SS" tag at the expected offset, an attacker can free arbitrary heap chunks.
• The CV_GetRandom command, intended to return random data, can be repurposed as a session oracle. By feeding it various addresses, an attacker can determine if a forged session object is located at a particular heap address, effectively locating controlled data on the heap.

1. Stack Overflow via Heap Corruption:

• A critical vulnerability was found in the secure_bio_identify function (a CV command), which performs a memcpy operation using a property_size field from an object. While direct control over property_size was limited, the previously identified heap primitives allowed for heap feng shui. An attacker could create a large object, free it, and then allocate a smaller object that would partially overlap with the freed large object's metadata. By writing to the smaller object's controlled data, the attacker could corrupt the property_size field of the overlapping large object, thus triggering a stack overflow in secure_bio_identify.

1. Arbitrary Flash Write and Firmware Modification:

• The system has a legitimate firmware update mechanism that includes a file called clear_sedd.bin. This file, when flashed, forces a reboot into the SBI and effectively erases or corrupts the Secure Code Descriptor (SCD). This reveals a "by design" arbitrary flash write capability.
• Combined with the ability to leak device-specific OTP (One-Time Programmable) keys (HMAC and AES keys used to protect the flash and decrypt the SCD) via the SOTP_read_key function (callable after gaining arbitrary code execution on the firmware), an attacker can bypass the encryption and HMAC protections of the flash. This allows flashing arbitrary, maliciously crafted data onto the ControlVault's flash memory.
• The crucial finding here is that there is no signature check of the application firmware at boot. The boot ROM verifies the SBI, and the SBI loads keys to decrypt the SCD, which in turn sets up the application firmware. But once the SCD is decrypted and loaded, the application firmware itself is not re-verified. This means an attacker can forge a custom SCD containing their own RSA public key, sign their own malicious firmware update, and flash it, making permanent modifications to the ControlVault firmware.

1. Host-Side Exploitation via Type Confusion/Overflow:

• The communication between the firmware and the host involves complex serialization and deserialization. The host prepares arguments, sends the CV command, and then deserializes the returned data based on an expected format. However, the firmware can redefine the encapsulation type and size of the output data sent back to the host.
• This led to type confusion and stack/heap overflows on the host side. Specifically, by backdooring CV_GetRandom in the firmware to return a raw buffer instead of a structured type, an integer variable on the host's stack (intended to hold a size) was treated as a buffer and overwritten with attacker-controlled data, leading to a stack overflow and calc.exe pop.
• A similar vulnerability was found in the Broadcom Storage Adapter DLL, used by Windows Hello for fingerprint handling. A wrapper function around CV_GetObject loaded an object header onto a stack variable. This variable was located past the end of the function's stack frame in the parent caller, which notably lacked stack cookies. By backdooring CV_GetObject in the firmware, an attacker could trigger an overflow in this host-side DLL, corrupting the parent's return address and gaining SYSTEM privileges.

1. Physical Attack Scenario:

• The ControlVault device, connected via an internal USB ribbon cable, can be physically extracted and connected to an external USB adapter. This transforms the internal logical attacks into a physical attack vector, allowing an attacker with physical access to bypass Windows security and compromise the board even if the system is locked or powered off.

Technical Deep Dive

▶ Watch: Initial motivation: ASLR disabled binaries in Control Vault (4:00)

The technical heart of this research lies in understanding the intricate communication between the Windows host and the ControlVault firmware, and then systematically dismantling its security assumptions.

ControlVault Communication Architecture

The ControlVault board communicates with the motherboard via an internal USB connection. On the Windows side, a dedicated USB driver exposes a device interface. Userland applications, including Dell's own services and the Windows Biometric Service, interact with this device by sending DeviceIoControl requests. These requests are then translated into USB packets and transmitted to the firmware.

Broadcom provides a set of DLLs that abstract these low-level interactions into high-level CV commands, such as CV_Open, CV_Close, CV_CreateObject, CV_GetRandom, and CV_fingerprint_identify. There are approximately 150 such commands, each with specific arguments and expected return values. On the firmware side, a central CV_Manager_Command function acts as a dispatcher, routing incoming CV commands to their respective handlers. This extensive command surface provided a rich hunting ground for vulnerabilities.

Firmware Decryption and Modification

The main application firmware, referred to as "Citadel," is encrypted. However, the Secure Boot Image (SBI), which loads and starts Citadel, is not. By reversing the SBI, Laulheret identified the firmware decryption routines. The process involves three key commands:

1. upgrade_start: This command initiates the firmware update. It provides an encrypted firmware header. Crucially, if no specific keys are present, the firmware uses hardcoded default AES keys and IVs for decryption. After decryption, new keys are generated for the execution-in-place (XIP) engine, which encrypts the firmware stored on flash.
2. upgrade_update: This command sends chunks of encrypted firmware. The decryption process for these chunks uses a custom IV computation. Laulheret found that the IV is derived from the memory address where the data chunk is mapped. This deterministic IV calculation, combined with the default keys, allowed for full decryption of the firmware using AES-CBC. A common pitfall noted was the firmware's tendency to swap endianness for numerical values.
3. upgrade_complete: This command finalizes the update, verifying the firmware's signature and committing remaining data to flash.

The ability to decrypt and re-encrypt the firmware using default keys was a foundational step. It allowed the researcher to inspect the firmware's internals thoroughly and eventually craft malicious firmware.

Heap Exploitation on Firmware

The initial heap vulnerability revolved around the CV_Open and CV_Close commands:

• CV_Open: This command allocates a session object on the firmware's heap and writes a "SE_SS" tag into it. Critically, it then returns the direct memory pointer to this session object as the session handle to the host. This immediately leaks a heap address, bypassing any potential ASLR on the firmware (which it lacked anyway).
• CV_Close: This command takes a session handle (the leaked pointer). Its validation logic is minimal: it checks if the pointer is within the valid heap range and if the "SE_SS" tag is present at the expected offset within the session structure. If these conditions are met, the memory is freed.

This design enables an arbitrary free primitive. An attacker can use CV_CreateObject to allocate an arbitrary data buffer on the heap. By carefully crafting this buffer to include the "SE_SS" tag at the correct offset, it can be made to resemble a valid session object. Then, by calling CV_Close with the address of this forged object (which can be located using an oracle), the attacker can free arbitrary heap chunks.

The session oracle was implemented using CV_GetRandom. This function validates the session handle and returns different error codes based on validity. By iterating through possible heap addresses and calling CV_GetRandom, an attacker can precisely locate their forged session objects on the heap.

Chaining to Stack Overflow

The arbitrary free was then chained with a stack overflow in the secure_bio_identify command. This function contained a memcpy that copied data based on an object's property_size field into a stack-allocated buffer. While direct control over property_size was limited, the heap primitives allowed for heap feng shui:

1. Allocate a large object (Object A) using CV_CreateObject and place the "SE_SS" tag within it.
2. Free Object A using the arbitrary free primitive. This creates a hole in the heap.
3. Allocate a smaller object (Object B) using CV_CreateObject. Due to the allocator's behavior, Object B will be placed within the hole left by Object A, causing a partial overlap between Object B's data and Object A's metadata (which includes property_size).
4. By writing to Object B, the attacker can corrupt the property_size field of the overlapping Object A.
5. Finally, calling secure_bio_identify with Object A's handle will trigger the memcpy with the attacker-controlled property_size, leading to a stack overflow.

Since the firmware lacked ASLR and stack cookies, gaining control of the instruction pointer via a stack overflow was straightforward. The presence of read-execute memory regions (e.g., driver code copied from flash to RAM) allowed the attacker to place shellcode directly into these regions for execution, bypassing any potential DEP-like protections on the stack. IDA scripts were used to identify suitable ROP gadgets (e.g., pop {rX, pc}) for constructing the exploit chain.

Permanent Firmware Modification

With arbitrary code execution on the firmware, the next step was permanent modification. This involved:

1. Leaking OTP Keys: The SOTP_read_key function, an internal firmware function, was called to exfiltrate device-specific OTP HMAC and AES keys. These keys are crucial for decrypting the Secure Code Descriptor (SCD) and for the execution-in-place engine.
2. Abusing clear_sedd.bin: A legitimate firmware update file, clear_sedd.bin, is designed to overwrite the SCD and force a reboot into the SBI, effectively clearing the device's secure boot configuration. This is an arbitrary flash write by design.
3. Forging a Malicious SCD: Using the leaked OTP keys, the attacker can now craft a custom SCD. This custom SCD can contain the attacker's own RSA public key, which will then be trusted by the SBI for future firmware updates.
4. Signing and Flashing Custom Firmware: With a trusted public key, the attacker can sign their own malicious firmware blob and use the CV_flash_update command to permanently flash it onto the ControlVault, persisting across reboots and Windows reinstalls.

This capability was demonstrated by modifying the USB device descriptor string to "control_pond" and, more functionally, by patching the CV_fingerprint_identify function to always return true, effectively bypassing the fingerprint login.

Host-Side Privilege Escalation

The final layer of attack targeted the Windows host itself, leveraging deserialization vulnerabilities:

The host and firmware exchange data using a TLV (Type-Length-Value)-like protocol. The host prepares arguments and expects a specific data structure in return. However, the firmware has the ability to redefine the encapsulation type and size of the output data.

1. CV_GetRandom Backdoor (Toy Example): By modifying the firmware, CV_GetRandom was backdoored. When requested with a specific "magic size," the firmware would change the expected deserialization type to a raw buffer and return a malicious payload. On the host side, an integer variable on the stack (intended for size) was then confused with a buffer and overflowed by the raw buffer data, leading to a stack overflow and calc.exe execution in a toy binary.
2. Windows Biometric Service Exploitation: This technique was then applied to a real-world target: the Broadcom Storage Adapter DLL, used by the Windows Biometric Service for fingerprint handling. This DLL loaded by the SYSTEM-privileged Windows Biometric Service, contained a wrapper function for CV_GetObject. This wrapper function copied an object header into a stack variable. Crucially, this stack variable was located past the end of its function's stack frame, meaning it could overflow the return address of its parent function (which lacked stack cookies and ASLR). By backdooring CV_GetObject in the firmware to return a malicious payload that triggers this overflow, the attacker gained SYSTEM privileges on the host. This attack was reachable from any user via an IO control interface.

Demo / Proof of Concept

▶ Watch: Overview of Control Vault's host-firmware system architecture (5:50)

Philippe Laulheret demonstrated several compelling proofs of concept throughout his presentation, showcasing the full impact of the discovered vulnerabilities.

1. Key Leakage Demo:

• This demonstration started with an already exploited firmware, having achieved arbitrary code execution.
• The exploit leveraged the secure_bio_identify stack overflow to call the internal firmware function SOTP_read_key twice.
• The results, displayed live, showed the exfiltration of two distinct keys from the device's OTP fuses: an HMAC key and an AES key. These keys are unique to each device and are used to secure the flash and decrypt the Secure Code Descriptor (SCD). This validated the ability to extract critical device secrets.

1. Firmware Modification and Fingerprint Bypass Demo:

• After successfully leaking the OTP keys and understanding the firmware update mechanism, Laulheret demonstrated permanent firmware modification.
• He had previously crafted a malicious firmware update, overcoming an initial challenge with incorrect endianness when forging the SCD. This modified firmware included his own RSA public key in the SCD, allowing his custom firmware to be signed and validated.
• The first visual proof of modification was a change to the USB device description: instead of the default "ControlVault," the device now reported itself as "control_pond" to Windows.
• The more impactful part of this demo showed a bypass of the Windows login screen. The modified firmware had patched the CV_fingerprint_identify function to always return true, regardless of the actual fingerprint scanned.
• Using a plastic finger (with a piece of green onion taped on for organic sensor activation), Laulheret successfully unlocked a Windows laptop configured for fingerprint login, demonstrating a complete bypass of the biometric security mechanism. This modification persists even after reboots or Windows reinstalls.

1. Host-Side Exploit (CV_GET_RANDOM) Demo:

• This demo illustrated the type confusion and stack overflow vulnerability on the Windows host side.
• A toy application was used, which simply called CV_GetRandom. The firmware had been backdoored so that when CV_GetRandom was called with a specific "magic size" argument, it would return a malicious payload and modify the deserialization type to a raw buffer.
• The demonstration showed the toy application initially running normally, returning random data. However, when called with the special argument, the host-side deserialization routine would misinterpret an integer on its stack as a buffer and overflow it, resulting in a calc.exe pop-up, demonstrating arbitrary code execution on the host.

1. Host-Side Privilege Escalation (Windows Biometric Service) Demo:

• Building on the host-side exploitation techniques, Laulheret showcased a privilege escalation to SYSTEM by targeting the Windows Biometric Service.
• The firmware was modified to backdoor CV_GetObject. A user-mode script was then used to call into the Windows Biometric Service with a specific "magic handle" that triggered the backdoored CV_GetObject functionality.
• This caused a stack overflow in the Broadcom Storage Adapter DLL (loaded by the SYSTEM-privileged Windows Biometric Service), corrupting the return address of a parent function.
• The result was the spawning of a netcat listener on the compromised system. Laulheret then connected to this listener, demonstrating a SYSTEM shell, signifying full control over the Windows operating system.

1. Physical Attack Scenario (Conceptual Demo):

• Laulheret presented a custom hardware contraption that split the ControlVault's internal USB ribbon cable into power lines and a standard USB adapter.
• This demonstrated that the ControlVault board, normally internal, could be connected externally to any machine via USB. This means all the previously demonstrated attacks, which assumed a compromised user or local access, could also be performed by a physical attacker simply by opening the laptop, removing the battery, and connecting to the ControlVault board.

Defensive Implications

▶ Watch: Host-firmware communication via Device IO Control and CV commands (6:20)

The findings presented by Philippe Laulheret reveal fundamental weaknesses in the design and implementation of Dell's ControlVault, a component intended to be a secure root of trust. Addressing these issues requires a multi-faceted approach from both vendors and end-users.

For Vendors (Dell & Broadcom):

1. Implement Robust Security Mitigations:

• Firmware ASLR and Stack Cookies: The most glaring omission on the firmware side is the lack of ASLR and stack cookies. These are basic, yet highly effective, mitigations against memory corruption vulnerabilities. They must be implemented across all firmware components.
• Strict DEP/XN Enforcement: While DEP was "questionable" on the firmware, explicit and consistent enforcement of non-executable memory regions is critical to prevent shellcode execution.
• Stronger Input Validation: The heap vulnerabilities and stack overflows stemmed from insufficient input validation and trust in attacker-controlled data. All CV commands must rigorously validate sizes, types, and content of incoming data.

1. Secure Boot Process Reinforcement:

• Application Firmware Signature Verification: The most critical flaw in the boot process is the absence of signature checks for the application firmware at boot time. The Secure Boot Image (SBI) must be extended to verify the integrity and authenticity of the loaded application firmware before execution.
• Discontinue Default Keys: The use of hardcoded default AES keys and IVs for firmware decryption is a severe vulnerability. Device-specific, unique keys should be provisioned securely and never fall back to easily discoverable defaults.
• Secure Flash Write Mechanisms: The clear_sedd.bin mechanism, which allows arbitrary flash writes, represents a significant design flaw. Any flash write operations must be authenticated, authorized, and cryptographically verified at every stage, not just at the SBI level.

1. Host-Side Software Hardening:

• ASLR for All Components: All Broadcom-related services and DLLs running on the host, especially those interacting with ControlVault, must have ASLR enabled.
• Robust Deserialization: The type confusion and overflow vulnerabilities on the host side highlight flaws in the deserialization logic. The host should never implicitly trust encapsulation types or data sizes specified by the firmware. All deserialization routines must perform strict bounds checking and type validation.

1. Comprehensive Security Audits:

• Given the age of some vulnerabilities (potentially 15+ years), a complete and independent security audit of the entire ControlVault platform—hardware design, firmware, and host software—is imperative. This includes reviewing the communication protocols, cryptographic implementations, and all command handlers.

For Defenders (IT Admins & Users):

1. Apply Firmware Updates Promptly: Dell has released patches for these vulnerabilities. It is crucial to ensure that all Dell Latitude and Precision laptops receive and apply these firmware updates as soon as they are available.
2. Be Aware of Physical Access Risks: The ability to exploit ControlVault via physical access means that laptops should not be left unattended, especially in untrusted environments. Physical security measures, such as cable locks and secure storage, become even more critical.
3. Monitor for Suspicious Activity: While difficult for embedded components, monitoring for unusual network activity originating from the ControlVault interface or unexpected process launches (like calc.exe or netcat) from system services could indicate compromise.
4. Question "Secure" Hardware: This research serves as a strong reminder that "secure" hardware components are not impenetrable. Defenders should maintain a healthy skepticism and understand that any undocumented or unaudited component can become a weak link in the security chain.
5. Layered Security: Relying solely on a single security mechanism, such as a fingerprint reader, is insufficient. Multi-factor authentication, strong passwords, and disk encryption remain essential layers of defense.

Key Takeaways

• Undocumented "Secure" Hardware is a Critical Attack Surface: Dell's ControlVault 3/3+, found in tens of millions of business laptops, was largely undocumented, making it a prime target for researchers and attackers alike. Its "secure" designation did not equate to robust security.
• Lack of Basic Mitigations is Fatal: The absence of fundamental security mitigations like ASLR and stack cookies in the firmware, and inconsistent application on the host side, drastically simplified exploitation, allowing for straightforward ROP chain construction and arbitrary code execution.
• Chaining Vulnerabilities Leads to Full Compromise: The research demonstrated a successful chain of vulnerabilities, from heap corruption and arbitrary free primitives to stack overflows and host-side deserialization flaws, ultimately achieving permanent firmware modification and SYSTEM level privilege escalation.
• Firmware Modification Enables Persistent Implants: The ability to bypass firmware signature checks and write arbitrary data to flash allows for the creation of permanent implants that survive operating system reinstalls and provide persistent backdoors, login bypasses (e.g., fingerprint), and host compromise capabilities.
• Physical Access Remains a Potent Threat: By demonstrating how the internal ControlVault board could be connected externally via USB, the research underscored that physical access to a device can bypass software-only security measures and facilitate deep system compromise.
• Vendor Due Diligence is Paramount: The presence of vulnerabilities potentially dating back 15 years highlights a severe lack of ongoing security audits and robust design principles for embedded secure components. Vendors must prioritize comprehensive security reviews across their entire supply chain, especially for components designated as security-critical.

About the Speaker(s)

Philippe Laulheret is a Senior Vulnerability Researcher at Cisco Talos. His work primarily focuses on discovering vulnerabilities within Windows embedded systems. As part of his role, he conducts third-party research, responsibly reports his findings to affected vendors, and subsequently discloses the details of these vulnerabilities through blogs and conference presentations, such as this one. His expertise lies in reverse engineering complex systems to uncover deep-seated security flaws.