The Cost of Performance: Breaking ThreadX with Kernel Object Masquerading Attacks

The Cost of Performance: Breaking ThreadX with Kernel Object Masquerading Attacks

Speakers: Xinhui Shao

Conference: USENIX Security

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

Overview

This talk, presented by Xinhui Shao, unveils a novel and potent attack methodology dubbed Kernel Object Masquerading (COM) attacks against ThreadX, a widely deployed real-time operating system (RTOS) in embedded and IoT devices. The research, a collaborative effort among Southeast University, Drexel University, Angu University of Technology, and UMass Law, highlights a critical tension between performance optimization and security. Specifically, ThreadX's aggressive shortcuts in parameter sanitization, designed to enhance speed, inadvertently create a broad attack surface that can be exploited by unprivileged user threads.

The core of the discovery is that ThreadX's validation mechanisms, which check address ranges and specific fields within kernel objects rather than directly validating pointer values, can be tricked. Malicious user threads can manipulate accessible kernel object fields to mimic the conditions expected by the operating system, thereby forging valid kernel objects in memory. This allows attackers to bypass security checks, achieve privilege escalation, and ultimately gain arbitrary memory access, severely undermining the security guarantees of ThreadX and posing significant risks to the embedded systems that rely upon it.

The implications of this research are substantial. Given ThreadX's pervasive presence in critical infrastructure, medical devices, automotive systems, and various IoT deployments, the demonstrated COM attacks expose a fundamental flaw that could be leveraged for sophisticated exploits. The talk not only details the attack primitive but also introduces an automated framework for its construction, underscoring the practicality and ease with which such vulnerabilities could be discovered and exploited in real-world scenarios.

Background

▶ Watch: Introduction to ThreadX and its performance optimization vulnerability (0:00)

Real-time operating systems (RTOSes) form the foundational software layer for countless embedded and IoT devices, ranging from consumer electronics to industrial control systems and critical infrastructure. Their design prioritizes determinism, low latency, and efficient resource utilization, often at the expense of comprehensive security features found in general-purpose operating systems. Among the myriad RTOS options available, ThreadX stands out, alongside Zephyr OS, as one of the few that claims to provide "comprehensive security protection mechanisms." However, the research presented challenges this assertion, particularly concerning ThreadX's approach to performance optimization.

The crux of the problem lies in ThreadX's aggressive parameter sanitization strategy. Unlike some counterparts that perform thorough, direct validation of kernel object pointers, ThreadX employs a faster, two-pronged shortcut:

1. Address Range Validation: Instead of verifying the integrity or legitimacy of the values of kernel object pointers themselves, ThreadX primarily validates that these pointers fall within expected memory address ranges. This is a coarse-grained check that doesn't prevent manipulation of the object's contents.
2. Internal Field Condition Checks: Subsequently, it checks specific "condition fields" inside the pointed-to object. These fields are expected to hold certain values or states for the object to be considered valid for a particular operation.

This design choice, while boosting performance, creates a window of opportunity for attackers. By focusing on address ranges and internal field conditions, ThreadX inadvertently assumes the integrity of the object's internal state. This assumption becomes exploitable if an attacker can modify these internal fields, leading to a scenario where a seemingly valid object is, in fact, a cleverly forged construct. The research highlights that this "design shortcut" is where the vulnerability arises, setting the stage for sophisticated attacks that exploit the trust placed in the internal state of kernel objects.

Key Findings

▶ Watch: Introducing Kernel Object Masquerading (COM) attacks (2:50)

The central discovery of this research is that ThreadX's performance-oriented parameter sanitization creates a critical vulnerability, enabling what the researchers term Kernel Object Masquerading (COM) attacks. The core insight is deceptively simple yet profoundly impactful: malicious user threads can mimic expected conditions by strategically modifying specific fields within kernel objects that they have legitimate access to.

This manipulation allows an attacker to trick ThreadX into believing a forged object is valid, even when it's not. The process involves invoking a system call to modify a kernel object's fields to values that satisfy subsequent checks for a different type of kernel object. When a second system call is invoked, treating the modified memory region as the "valid" forged object, the system proceeds with operations on a memory area that the attacker controls. The result is the creation of a forged object that effectively overlaps and repurposes modified memory, bypassing ThreadX's security checks.

Building on this fundamental vulnerability, the researchers designed the COM attack as a powerful confused deputy attack carried out by chaining multiple system calls. In a confused deputy scenario, a privileged entity (the kernel) is tricked into performing an action on behalf of a less privileged entity (the user thread) that it would not ordinarily allow. By conducting COM attacks, attackers can achieve:

• Privilege Escalation: Gaining higher privileges than initially authorized, often to kernel level.
• Arbitrary Memory Access: Reading from or writing to any memory location within the system, including sensitive kernel memory.

These capabilities demonstrate that COM attacks can completely undermine the security guarantees of ThreadX, turning a performance optimization into a critical security flaw that allows unprivileged threads to gain full control over the system.

Technical Deep Dive

▶ Watch: Achieving arbitrary kernel memory access via COM attack (5:05)

The Kernel Object Masquerading (COM) attack is a sophisticated, multi-step process designed to exploit ThreadX's parameter sanitization weaknesses. It leverages the ability to manipulate kernel object fields to create type confusion and gain control over critical system resources. The attack unfolds in four distinct steps:

1. Creating or Identifying Malicious and Compliant Kernel Objects:

• Malicious Kernel Object: This object must be accessible to the attacker and possess at least one modifiable field. Its purpose is to serve as the initial target for manipulation. These can be existing kernel objects or newly created ones through legitimate system calls.
• Compliant Kernel Object: This object is the ultimate target of the attack. It must contain a pointer that can be dereferenced by a system call. The goal is to eventually hijack this pointer to point to sensitive memory locations.

1. Creating the Initial Forged Kernel Object:

• The attacker invokes a system call that can modify a field within the identified malicious kernel object.
• This modifiable field is set to a chosen kernel object type ID, effectively declaring the malicious object (or a part of it) to be of a different, desired type.
• Simultaneously, the attacker fabricates a pointer that points to this modified region, which now has a "valid" type ID. This pointer refers to the "initial forged kernel object."
• Crucially, this initial forged object must also contain at least one modifiable field, allowing for further manipulation.

1. Creating Sequences of Forged Objects to Override Fields in the Compliant Object:

• This is an iterative process where the attacker invokes a series of system calls, using the pointer to the initial forged object.
• Each system call is chosen to modify different modifiable fields within the forged object.
• The key insight here is that different system calls operate on different fields. By chaining these calls, the attacker can progressively build more complex forged objects.
• This process can be recursively repeated, generating multiple sequences of forged kernel objects of various types from the initial one. The objective is to gain fine-grained control over the memory region that the compliant object occupies.

1. Overwriting the Target Pointer and Dereferencing:

• Once the attacker has generated a sufficient sequence of forged objects, the final step is to overwrite the target pointer within the compliant kernel object. This pointer is manipulated to point to sensitive data or control registers (e.g., in kernel memory or memory-mapped peripherals).
• Concurrently, the condition fields of the compliant object are adjusted to satisfy any remaining validation checks, ensuring the system still perceives the object as legitimate.
• Finally, the now-hijacked pointer is dereferenced through a system call. For example, if the pointer is directed to the Memory Protection Unit (MPU) control register, dereferencing it can disable the MPU. This action allows an unprivileged thread to directly access kernel memory, achieving arbitrary memory read/write capabilities.

These four steps collectively transform a seemingly innocuous design shortcut in ThreadX's parameter sanitization into a potent attack primitive.

Automated Framework for COM Attack Construction

Manually identifying vulnerable system calls and constructing such complex attack sequences is tedious and error-prone. To overcome this, the researchers developed an automated framework comprising three phases:

1. Symbolic Execution for Vulnerable System Call Identification:

• The ThreadX source code is first converted to LLVM Intermediate Representation (IR) to facilitate symbolic execution.
• Each system call is then symbolically executed. During this process, the framework inspects memory operations to identify all modifiable fields (those subject to memory writes) and condition fields (those involved in validation checks) within kernel objects.
• Modifiable fields' relative locations are determined by resolving memory address expressions.
• Identifying condition fields is more challenging due to complex arithmetic and logical expressions and pointer resolutions. While demanding significant engineering effort, the researchers found the number of pass constraints to be limited (no more than six), enabling manual deduction of condition fields for each syscall.
• By analyzing these fields, system calls are classified as exploitable for COM attacks.

1. Candidate Object Type Selection:

• This phase identifies suitable kernel object types to serve as malicious or compliant objects.
• For malicious objects, types with modifiable fields and, ideally, fully controllable pointer references are prioritized. Fully controllable pointer references are critical as they enable arbitrary memory read or write operations when dereferenced. The data written via such pointers can be controlled by attacker-supplied system call parameters or member variables.
• For compliant objects, any type that enables fully controllable pointer dereferencing is suitable.
• Memory location determination, either through allocator addresses or reverse-engineering object pointers (e.g., on the stack or heap), helps narrow the scope for subsequent exploration.

1. Feasible System Call Sequences Generation:

• While choosing an optimal sequence of system calls is theoretically an NP-hard problem, the limited number of vulnerable system calls in ThreadX makes it tractable.
• A deep-spur search algorithm is employed. At each step, it checks modifiable and condition fields, pruning infeasible branches to efficiently generate practical system call sequences for exploitation.

Experimental Findings

The research systematically evaluated ThreadX using this framework, yielding several significant findings:

• Exploitable System Calls: Out of 60 system calls analyzed, 31 were found capable of modifying kernel object fields. Specifically, 17 could set fixed values, and 30 allowed parameter-driven arbitrary modifications. Both categories are exploitable, leading to data corruption or kernel crashes, indicating a broad attack surface within ThreadX.
• Effectiveness in Diverse Environments: COM attacks proved effective across various scenarios. For instance, by chaining module_allocate and timer_create system calls, the researchers could iteratively create forged timer objects. This allowed them to overwrite multiple consecutive memory locations, achieving arbitrary memory write using only legitimate ThreadX system calls.
• Exploitable Object Types: Almost all kernel object types in ThreadX, with the sole exception of mutexes, could serve as malicious objects because their fields could be modified to desired values. Furthermore, every kernel object type could function as a compliant object due to their support for fully controllable pointer dereferencing. The research specifically highlighted how linked list operations in ThreadX, such as in the Q_SEND system call, make pointer dereferences particularly powerful, enabling arbitrary memory content writes via system call parameters.
• Efficiency of Symbolic Execution: The optimized symbolic execution engine was efficient, with most system calls being analyzed within one minute. The mutx_put system call was an outlier, taking approximately 9 hours due to its numerous branches and loops. One system call did not terminate normally due to complex constraint solving issues. Overall, the approach achieved high coverage within practical resource limits.

Demo / Proof of Concept

▶ Watch: Automated framework for constructing COM attacks (6:30)

The researchers didn't just theorize about COM attacks; they practically demonstrated their efficacy on real-world hardware platforms. The proof of concept validation was conducted on:

• ST only max boards
• Wilderness Labs boards
• QEMU platforms

On these diverse environments, the team successfully mounted Kernel Object Masquerading (COM) attacks. The practical demonstrations confirmed the ability to achieve arbitrary memory access, a critical primitive for full system compromise. Perhaps the most striking demonstration was the ability to disable the Memory Protection Unit (MPU). Disabling the MPU, a hardware feature designed to enforce memory access permissions, effectively nullifies a fundamental layer of security, allowing an unprivileged attacker to read from and write to any memory location, including sensitive kernel regions.

These experiments unequivocally confirm that COM attacks are not merely theoretical constructs but are practical on real-world hardware. This undermines the core security guarantees of ThreadX and poses serious, tangible risks to the myriad embedded and IoT systems that rely on this RTOS. The ability to disable hardware-enforced security mechanisms like the MPU underscores the severity of these vulnerabilities.

Defensive Implications

▶ Watch: Experimental results: 31 exploitable ThreadX system calls (11:05)

The findings from the Kernel Object Masquerading (COM) attacks on ThreadX carry significant defensive implications for developers, system architects, and security professionals working with embedded and IoT devices.

1. Enhanced Parameter Sanitization: The most direct defense is for ThreadX developers to implement significantly stronger and more granular parameter sanitization. This must go beyond mere address range validation to include direct validation of pointer values and comprehensive integrity checks on internal kernel object fields, especially those designated as "condition fields." Every field that influences an object's type or behavior should be immutable or strictly validated after creation.
2. Type Confusion Prevention: Mechanisms to prevent type confusion must be integrated. This could involve unique, cryptographically strong type identifiers, or ensuring that memory regions designated for one object type cannot be reinterpreted as another without explicit, secure transitions.
3. Hardware-Assisted Memory Protection: While the attack demonstrated disabling the MPU, robust use of Memory Protection Units (MPUs) or Memory Management Units (MMUs), configured with the principle of least privilege, remains a crucial layer. This includes locking down MPU configurations post-initialization and implementing runtime integrity checks on MPU registers to detect unauthorized modifications.
4. Fine-Grained Access Control for Kernel Objects: Implement more stringent access control mechanisms for kernel objects. User threads should only be able to modify fields truly necessary for their legitimate operations, and any modification should be subject to strict validation against the object's defined type and state.
5. Runtime Integrity Checks: Implement runtime integrity checks for critical kernel object metadata, especially type IDs and pointers. Regular, randomized checks could detect malicious modifications before they are exploited.
6. Secure Development Practices: Developers using ThreadX should prioritize secure coding practices, minimizing the exposure of modifiable fields and being acutely aware of how system calls can interact with kernel object states. Regular security audits and vulnerability assessments of ThreadX-based applications are essential.
7. Patching and Updates: Users of ThreadX must diligently apply any security patches released by Microsoft (the current maintainer of ThreadX, now part of Azure RTOS) that address these vulnerabilities.
8. Consider Alternative RTOSes: For applications with extremely high-security requirements, organizations might need to re-evaluate ThreadX's suitability and consider alternative RTOSes that employ more robust security architectures from the ground up, or those that have undergone extensive formal verification.

Ultimately, these findings necessitate a re-evaluation of the security posture of systems relying on ThreadX and a shift towards proactive defense strategies that account for the subtle yet powerful exploits enabled by performance-driven design shortcuts.

Key Takeaways

• Performance vs. Security Trade-off: ThreadX's aggressive performance optimizations, particularly in parameter sanitization through address range and internal field validation, create critical vulnerabilities that allow for Kernel Object Masquerading (COM) attacks.
• Confused Deputy Attack Primitive: COM attacks are a sophisticated form of confused deputy attack, where unprivileged user threads trick the ThreadX kernel into performing actions (like dereferencing a malicious pointer) that lead to privilege escalation and arbitrary memory access.
• Multi-Stage Exploitation: The attack involves a four-step process: identifying malicious and compliant objects, creating initial forged objects, iteratively building sequences of forged objects to manipulate memory, and finally overwriting and dereferencing critical pointers.
• Automated Attack Construction: An automated framework leveraging symbolic execution and deep-spur search was developed to efficiently identify vulnerable system calls and construct complex COM attack sequences, demonstrating the practicality of discovering and exploiting these flaws.
• Real-World Impact: The practicality of COM attacks was confirmed on real-world hardware (ST only max, Wilderness Labs boards), successfully achieving arbitrary memory access and even disabling the Memory Protection Unit (MPU), fundamentally undermining ThreadX's security guarantees.
• Urgent Defensive Measures: Defenders must implement significantly enhanced parameter sanitization, type confusion prevention, fine-grained access control for kernel objects, and runtime integrity checks to mitigate these vulnerabilities in ThreadX-based systems.

About the Speaker(s)

Xinhui Shao is a researcher involved in this collaborative work, which spans multiple academic institutions including Southeast University, Drexel University, Angu University of Technology, and UMass Law. The presentation highlights their expertise in embedded systems security and their significant contribution to identifying and demonstrating critical vulnerabilities in widely deployed real-time operating systems like ThreadX.