OVPNX: 4 Zero-Days Leading to RCE, LPE and KCE (via BYOVD) Affecting Millions of OpenVPN Endpoints

OVPNX: 4 Zero-Days Leading to RCE, LPE and KCE (via BYOVD) Affecting Millions of OpenVPN Endpoints

Speakers: Unknown

Conference: Black Hat USA

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

Overview

This talk unveils a critical kernel vulnerability discovered across multiple popular Virtual Private Network (VPN) clients, including ExpressVPN, Proton VPN, and those leveraging the widely adopted OpenVPN framework. The researcher, an unnamed speaker from Black Hat USA, detailed a classic integer overflow flaw within the TAP drivers—a fundamental component responsible for creating virtual network interfaces—used by these VPN solutions. This vulnerability, identified as a kernel buffer overflow, carries severe implications, potentially leading to Local Privilege Escalation (LPE), Kernel Code Execution (KCE), and as indicated by the talk's title, even Remote Code Execution (RCE).

The significance of this discovery lies not only in the high impact of a kernel-level vulnerability but also in its pervasive nature. What began as an investigation into a single VPN client quickly escalated into the identification of the same core bug across numerous drivers, hinting at a widespread issue stemming from shared codebases or common development practices. The speaker's journey highlights a critical supply chain security concern, where a single flaw in a foundational component can expose millions of endpoints to severe compromise, underscoring the urgent need for robust security auditing in core networking software.

The talk frames this as a Bring Your Own Vulnerable Driver (BYOVD) scenario, where an attacker could potentially leverage the vulnerable driver to elevate privileges on a compromised system. While the speaker confirmed the vulnerability's existence and demonstrated a system crash, the intricacies of achieving full Kernel Code Execution were acknowledged as a complex task beyond the scope of this particular presentation. Nevertheless, the findings present a stark reminder of the delicate balance between performance and security in critical system components.

Background

▶ Watch: Introduction and finding first bug in ExpressVPN driver (0:00)

The genesis of this significant discovery traces back to a relatable scenario: a Saturday night gaming session plagued by network lag. When a friend attributed his connection issues to ExpressVPN, the speaker's curiosity was piqued, leading to an initial investigation into the VPN's underlying mechanisms. The focus quickly narrowed to the TAP driver, a crucial component in the architecture of many VPNs. A TAP driver functions as a software-only network adapter, creating a virtual Ethernet device that allows VPN software to send and receive raw Ethernet frames, effectively tunneling network traffic.

The initial deep dive involved reverse engineering the ExpressVPN TAP driver's binary. The speaker specifically examined the DriverEntry function, which typically initializes the driver, and identified the MiniportSendNetBufferLists callback. This callback is responsible for forwarding network data to the driver for processing. Within this data path, the TapAdapterTransmit function was identified as a key area for analysis. It was here that the first instance of the critical vulnerability was uncovered.

Following the discovery in ExpressVPN, the researcher, suspecting a broader pattern, extended the investigation to another popular VPN service, Proton VPN. To their surprise, the exact same vulnerability, exhibiting identical characteristics and behavior, was found within Proton VPN's TAP driver. This replication of the bug strongly suggested that it wasn't an isolated incident but rather a systemic flaw. Driven by this realization, the speaker developed a rule-based search methodology—likely leveraging static analysis tools or pattern matching—to scan for similar code constructs across a wider array of drivers. This effort yielded approximately 50 matches, confirming the widespread nature of the vulnerability. The sheer volume of affected drivers pointed towards a common origin, leading the speaker to consult AI tools like ChatGPT for suggestions on widely used VPN components. The immediate and obvious answer was OpenVPN.

OpenVPN, a highly popular open-source software application, is renowned for implementing virtual private network techniques for creating secure point-to-point or site-to-site connections. It's often conceptualized in two ways: as the OpenVPN binary part—the executable software that manages VPN connections—and as the OpenVPN protocol, which defines the tunneling mechanism itself. Many commercial VPN providers build their services upon the OpenVPN framework, often incorporating its tap-windows6 repository, which provides the generic TAP driver for Windows systems. This widespread adoption meant that a vulnerability within this core component would have far-reaching consequences, impacting millions of users globally.

Key Findings

▶ Watch: Discovering the same vulnerability in ProtonVPN (2:50)

The central finding of this research is the identification of a pervasive kernel vulnerability rooted in a classic integer overflow within the TAP drivers utilized by numerous VPN services. This flaw, consistently present across ExpressVPN, Proton VPN, and the foundational tap-windows6 driver from OpenVPN, manifests as a kernel buffer overflow during memory operations. The speaker's subsequent rule-based search further revealed around 50 additional drivers exhibiting the exact same vulnerability pattern, underscoring its significant prevalence across the VPN ecosystem.

The core of the vulnerability lies within the TapAdapterTransmit function, which is invoked by the MiniportSendNetBufferLists callback to handle incoming network data. This function is responsible for allocating memory to store the incoming data and then moving the data into the newly allocated buffer. The critical error occurs due to an inconsistency between the size calculated for memory allocation and the size used during the subsequent data transfer operation. Specifically, the allocation size is determined by data_length + 24, where data_length is derived from an offset (RX + 18) and then cast into a short integer type, potentially leading to an integer overflow if the original data_length is sufficiently large. While the memory is allocated based on this potentially truncated or overflowed size, the subsequent memory move operation (akin to memcpy) attempts to transfer data using the original, potentially much larger, data_length.

This mismatch results in a kernel buffer overflow, where a larger chunk of data is written into a smaller, allocated buffer within the kernel's memory space. The speaker specifically noted that a "big chunk of memory" would be moved "onto the 70 allocated bytes" in an overflow scenario. Such an overflow within the kernel is exceptionally dangerous. It allows an attacker to overwrite arbitrary kernel memory, which can lead to a range of severe consequences.

The implications of this kernel buffer overflow are profound:

• Local Privilege Escalation (LPE): An unprivileged attacker who can load the vulnerable driver (a common scenario in Bring Your Own Vulnerable Driver (BYOVD) attacks) can trigger this bug to execute arbitrary code in kernel mode, thereby escalating their privileges to NT AUTHORITY\SYSTEM.
• Kernel Code Execution (KCE): The ability to overwrite kernel memory provides a pathway to full kernel code execution, granting an attacker complete control over the operating system. While the speaker noted the complexity of achieving full KCE exploit primitives, the underlying vulnerability clearly provides the necessary foundation.
• Denial of Service (DoS): As demonstrated by the speaker's initial proof-of-concept, triggering the buffer overflow immediately leads to a system crash (Blue Screen of Death on Windows), making it a reliable DoS vector.
• Widespread Impact: Given that OpenVPN is an industry standard and its TAP drivers are widely integrated into numerous commercial VPN products, this single vulnerability pattern affects millions of endpoints globally. This highlights a significant supply chain security risk, where a flaw in a shared component can have exponential downstream consequences.

The identification of this widespread vulnerability underscores a critical gap in the security posture of many VPN solutions and the broader software ecosystem relying on shared driver components.

Technical Deep Dive

▶ Watch: Automated search finds over 50 affected VPN drivers (3:20)

The technical core of the vulnerability resides within the Windows TAP driver architecture, specifically within the MiniportSendNetBufferLists callback and its subsequent call to the TapAdapterTransmit function. This function is instrumental in how the VPN driver processes and forwards network data.

Let's dissect the TapAdapterTransmit function's execution flow as described by the speaker:

1. Function Entry and Verification: The MiniportSendNetBufferLists callback receives network buffer lists and, after some initial verification steps, enters a loop to process these buffers, ultimately calling TapAdapterTransmit for each.
2. Memory Allocation (ExAllocatePoolWithTag equivalent): Inside TapAdapterTransmit, the driver first attempts to allocate a buffer in kernel memory. The speaker describes this as "got and dislocate memory with tech priority," which strongly implies the use of a kernel memory allocation function such as ExAllocatePoolWithTag. This function is typically used by kernel-mode drivers to allocate memory from a specified pool.
3. Size Calculation for Allocation: The crucial vulnerability lies in how the size for this allocation is determined. The intended size for the buffer is calculated as data_length + 24. However, the value of data_length is extracted from an offset within a register, specifically RX + 18. Critically, this data_length value is then cast into a short integer type, referred to as EP by the speaker, before being used in the final size calculation.

• The Integer Overflow: If the original data_length (which can be a larger 32-bit or 64-bit integer) exceeds the maximum value that a short integer can hold (typically 32,767 for a signed short or 65,535 for an unsigned short), the cast to EP will result in an integer overflow. This means that a large positive data_length could become a much smaller, potentially negative, or wrapped-around positive value when stored in EP. Consequently, the calculated allocation size (EP + 24) would be significantly smaller than the size actually required to hold the incoming data. For example, if data_length is 0xFFFF (65535) and EP is a signed short, it could become -1, leading to an incorrect small allocation size. If EP is an unsigned short, a large value might wrap around, still resulting in a smaller-than-expected allocation.

1. Data Movement (memory move): After the buffer is allocated using the potentially overflowed size, the driver proceeds to move the actual network data into this buffer. The speaker notes, "it will be moved with the data length, the original data length not the plus 24." This is the second critical component of the vulnerability. The memory move operation (analogous to memcpy or RtlCopyMemory in kernel context) uses the original, un-overflowed data_length as the source size for the copy.
2. The Kernel Buffer Overflow: The discrepancy between the allocated size and the size of the data being moved is the direct cause of the kernel buffer overflow. A large amount of data (determined by the original data_length) is written into a much smaller buffer (allocated based on the overflowed EP + 24 size). The speaker specifically mentioned that a "big chunk of memory" would be moved "onto the 70 allocated bytes," implying that in a typical overflow scenario, the allocated buffer might be extremely small due to the integer overflow. This overwrites adjacent kernel memory regions, leading to system instability, crashes, or, more maliciously, allowing an attacker to manipulate kernel data structures or inject malicious code.

The fact that this identical sequence of operations and the resulting vulnerability were found in ExpressVPN, Proton VPN, and OpenVPN's tap-windows6 driver, along with 50 other drivers, strongly suggests a common origin. This could be due to:

• Shared Codebase: Many VPN providers might be directly or indirectly using the tap-windows6 driver from OpenVPN or a slightly modified version of it.
• Common Development Practices/Templates: The bug might stem from a widespread pattern of handling network buffer lists and size calculations within the Windows driver development community, where this specific integer overflow scenario was overlooked.

Exploiting a wild kernel overflow to achieve Kernel Code Execution (KCE) is a sophisticated task. It typically involves techniques like:

• Overwriting function pointers in kernel data structures.
• Manipulating page tables to execute arbitrary code.
• Leveraging specific kernel objects to achieve arbitrary read/write primitives.
• Bypassing exploit mitigations like Kernel Address Space Layout Randomization (KASLR) and Supervisor Mode Execution Prevention (SMEP).

While the speaker explicitly stated that they would not delve into the specifics of achieving KCE, the presence of such a fundamental memory corruption vulnerability at the kernel level provides a powerful primitive for a determined attacker. The ability to trigger a system crash (DoS) is a clear indicator of the bug's severity and direct impact on system stability.

Demo / Proof of Concept

▶ Watch: ChatGPT suggests OpenVPN as the widespread commonality (3:40)

The speaker provided a clear, albeit brief, description of their proof of concept (PoC) for the discovered kernel vulnerability. After identifying the integer overflow and subsequent kernel buffer overflow in the TAP drivers, the researcher "just wrote a fast PC to crash the system." This indicates that the initial PoC was designed to reliably trigger the vulnerability and demonstrate its immediate impact, which in this case was a Denial of Service (DoS), typically manifested as a Blue Screen of Death (BSOD) on Windows systems.

The process would involve crafting a malicious network packet or input that, when processed by the vulnerable TapAdapterTransmit function, would cause the data_length to trigger the integer overflow during the allocation size calculation. Subsequently, the memory move operation, using the original large data_length, would attempt to write beyond the bounds of the much smaller allocated buffer, corrupting critical kernel memory and leading to an immediate system crash.

It is important to note that the speaker explicitly stated, "Exploiting wild kernel overflow and achieving code execution, it's a hard task. It's not something I will talk about it today." Therefore, while the title of the talk includes "RCE, LPE and KCE," the presented demonstration was limited to a system crash, confirming the existence and severity of the kernel buffer overflow. The path from a reliable DoS to full Kernel Code Execution (KCE) typically requires significant additional research and exploit development techniques to achieve controlled memory corruption and bypass operating system mitigations. However, the demonstrated system crash serves as irrefutable evidence of a critical and exploitable kernel vulnerability.

Defensive Implications

▶ Watch: Confirming the vulnerability within OpenVPN's tap-windows6 driver (4:20)

The discovery of this widespread kernel vulnerability in TAP drivers necessitates immediate and comprehensive defensive measures across the ecosystem. The implications extend beyond merely patching a single product, touching upon secure development practices, supply chain security, and robust system hardening.

1. Immediate Patching and Updates:

• User Action: All users of ExpressVPN, Proton VPN, and any VPN client that relies on OpenVPN's tap-windows6 driver or similar TAP driver implementations should immediately ensure their VPN software and underlying drivers are updated to the latest, patched versions.
• Vendor Responsibility: VPN providers and software developers utilizing these drivers must prioritize the release and distribution of patches. This includes clearly communicating the severity of the vulnerability and guiding users through the update process.

1. Supply Chain Security Audits:

• This incident highlights a critical vulnerability in the software supply chain. A single bug in a widely adopted open-source component (like tap-windows6) can propagate across numerous commercial products.
• Organizations and developers must implement rigorous security audits, not just of their own code, but critically of all third-party libraries, drivers, and open-source components they integrate. This includes static analysis, dynamic analysis, and manual code reviews for common vulnerabilities like integer overflows and buffer overflows, especially in low-level, high-privilege components like kernel drivers.

1. Secure Coding Practices for Kernel Development:

• The vulnerability is a classic integer overflow followed by a buffer overflow. This points to fundamental issues in how memory allocation sizes are calculated and handled, particularly when dealing with user-controlled input and type conversions (e.g., casting a large integer to a short).
• Developers of kernel-mode drivers must adopt extremely cautious coding practices:
• Input Validation: Thoroughly validate all input sizes and lengths, especially those derived from user space or external sources, before performing memory allocations or copies.
• Safe Integer Operations: Use safe integer libraries or explicit checks for overflow conditions when performing arithmetic operations that determine buffer sizes. Avoid implicit type conversions that can lead to truncation or overflow.
• Consistent Size Management: Ensure that the size used for memory allocation precisely matches the maximum possible size of data that will be moved into that buffer.
• Fuzzing: Employ robust fuzzing techniques specifically targeting driver interfaces and input parameters to uncover edge cases and overflow conditions.

1. Mitigating BYOVD (Bring Your Own Vulnerable Driver) Attacks:

• This vulnerability facilitates a BYOVD attack, where an attacker with local user privileges can load a known vulnerable driver (if the system allows it) and then exploit its flaws to achieve Local Privilege Escalation (LPE).
• Driver Signing and Whitelisting: Organizations should enforce strict driver signing policies, only allowing digitally signed drivers from trusted vendors to be loaded. Furthermore, implementing driver whitelisting can prevent the loading of any unauthorized or known-vulnerable drivers.
• Endpoint Detection and Response (EDR): EDR solutions can help detect suspicious driver loading activity, unusual kernel crashes, or attempts to exploit kernel vulnerabilities, providing an additional layer of defense, though detecting the exploit itself at the kernel level is challenging.

1. Principle of Least Privilege:

• While not directly preventing the bug, adhering to the principle of least privilege for driver components and related services can minimize the blast radius if an exploit is successful.
• Regularly review the necessity of kernel-mode components and ensure they only operate with the minimum required privileges.

The widespread nature of this vulnerability serves as a stark reminder that even well-established and widely trusted software components require continuous scrutiny. A single, seemingly simple coding error in a critical component can have cascading security consequences, affecting millions of users globally.

Key Takeaways

• A widespread kernel vulnerability (integer overflow leading to buffer overflow) was discovered in TAP drivers used by popular VPN clients.
• The vulnerability affects ExpressVPN, Proton VPN, and the tap-windows6 driver from OpenVPN, with evidence suggesting over 50 other drivers share the same flaw.
• The root cause is a classic integer overflow during memory allocation size calculation, where data_length is cast to a short before adding 24 bytes, leading to an undersized buffer.
• A subsequent memory move operation then uses the original, larger data_length, causing a kernel buffer overflow and overwriting critical kernel memory.
• This vulnerability enables Denial of Service (DoS) (system crashes) and has the potential for Local Privilege Escalation (LPE) and Kernel Code Execution (KCE), posing a severe security risk.
• The widespread nature highlights significant supply chain security risks associated with shared codebases and the urgent need for rigorous security auditing of core components like kernel drivers.
• Defenders must prioritize patching, implement robust secure coding practices for kernel components, and enforce strict driver loading policies to mitigate BYOVD (Bring Your Own Vulnerable Driver) attacks.

About the Speaker(s)

The speaker for this insightful and technically detailed talk remains anonymous, with the provided metadata listing them as "Unknown." No specific biographical details, affiliations, or titles were shared during the presentation. The speaker's expertise is evident through their ability to reverse engineer kernel drivers, identify a complex integer overflow vulnerability, and demonstrate its widespread impact across multiple major VPN products.