OpenVPN is one of the most trusted virtual private network (VPN) solutions out there. Many companies and users depend on it every day to protect their private traffic. But late in 2023, security researchers found a bug in the way OpenVPN 3 Core Library parses a special kind of data called PKCS#7. This bug, tracked as CVE-2023-6247, could let an attacker crash your VPN app — instantly disconnecting you from your private network.

In this article, we’ll break down what happened, explain the code behind the bug, and see how it could be exploited. This isn't just a story for developers — anyone who relies on OpenVPN should know how this bug worked and why patches matter.

What is CVE-2023-6247?

- Short summary: OpenVPN 3 Core Library (everything up to and including version 3.8.3) did not properly validate parsed PKCS#7 data. That means an attacker could send you a weirdly crafted certificate, and your OpenVPN client could crash.

PKCS#7 In a Nutshell

PKCS#7 is part of a set of cryptography standards. It’s used for signing/verifying, encrypting/decrypting, and packaging digital data — often certificates. OpenVPN uses this when doing smart card/token authentication with cryptography.

Where Was the Error?

It was in the PKCS#7 parsing code. When OpenVPN received a PKCS#7 certificate (like during authentication), it would parse the content, but didn’t check whether what it found made sense.

If an attacker could control what PKCS#7 data was sent to OpenVPN, they could feed it invalid, unexpected, or even malicious data, and OpenVPN’s parser wouldn’t notice. This could make OpenVPN crash (because it assumes its data structures are valid, but they're not).

The Vulnerable Code

Below is a simplified snippet showing what went wrong. (Disclaimer: This is not the *exact* code, but an illustration to help understanding.)

// Vulnerable code in pkcs7.cpp

Pkcs7Data* data = parse_pkcs7(buffer, size);
if (data) {
    // Assume data is always valid (problem)
    process_pkcs7(data);
    // ...
}
free_pkcs7(data);

The parse_pkcs7() function could return a Pkcs7Data object that wasn’t actually filled out correctly (fields might be null, unexpected length, or missing required parts). But the code *assumed* anything passed to process_pkcs7() was safe.

All it would take is for buffer to be a PKCS#7 message with certain missing or malformed fields, and process_pkcs7() might access a NULL pointer or corrupt memory — crash!

The Patch

The OpenVPN developers fixed it by robustly validating the parsed PKCS#7 data. Here’s a simplified version of what that looks like:

Pkcs7Data* data = parse_pkcs7(buffer, size);
if (!data || !is_pkcs7_data_valid(data)) {
    log("Error: PKCS#7 data invalid");
    return FAILURE;
}
process_pkcs7(data);
free_pkcs7(data);

This added validation stops the crash. If the PKCS#7 message is malformed, OpenVPN ignores it and keeps running.

Exploit Details: How Could This Be Used?

- Requirement: Attacker must be able to provide a PKCS#7 structure to your OpenVPN client. This can happen in some *client authentication* setups, or if you use OpenVPN with an external authentication service.
- Attack scenario: They send a malformed PKCS#7 certificate. Your OpenVPN 3.x client parses it and crashes. Game over — you’re knocked offline.
- What the attacker doesn’t get: They don’t “hack” your computer. They just crash the VPN client service, logging you out.

DIY (Do NOT misuse): Crafting a Bad PKCS#7

With tools like python-pkcs7 or OpenSSL, you could create an incomplete or incorrect PKCS#7 structure to send to a VPN server or client.

from cryptography.hazmat.primitives.serialization import pkcs7

# Create a PKCS#7 structure with missing required fields
builder = pkcs7.PKCS7SignatureBuilder()
# Do not add certificates, signatures, etc.
data = b"invalid pkcs7 content"
pkcs7_bytes = builder.sign(
    data,
    [private_key],  # incomplete list or bad key
    hashes.SHA256()
)
with open("crashme.p7b", "wb") as f:
    f.write(pkcs7_bytes)

Then, you’d need some way for OpenVPN to process this — maybe tricking a system into accepting it as a client certificate.

Includes Linux, Windows, Mac, Android apps using openvpn3

- Not at risk: OpenVPN 2.x users, or OpenVPN installations that don’t use PKCS#7 processing (many home users, but not all enterprises!)

Update immediately: Get OpenVPN 3 Core Library version 3.8.4 or newer.

- OpenVPN Community Downloads
- Check your environment: If you use smart cards, tokens, or PKI authentication, double check you’re not stuck on an old OpenVPN 3.x version.

Original advisory:

OpenVPN Security: CVE-2023-6247

NVD Entry:

https://nvd.nist.gov/vuln/detail/CVE-2023-6247

Patch commit:

GitHub Patch Link (openvpn3)

Final Thoughts

This bug in OpenVPN 3’s PKCS#7 parser is a classic tale: never trust untrusted data, always validate before acting. The bug didn’t let attackers “hack” you, but it could let them easily *crash* your VPN, cutting you off. Thankfully, the fix is simple — update your OpenVPN apps/manual builds as soon as you can.

If you want to keep your network safe, it pays to learn about these “little” bugs before they become big problems.


*Thanks for reading! Share this post with anyone managing OpenVPN 3.x — don’t let a crash take you offline!*

Timeline

Published on: 02/29/2024 01:42:34 UTC
Last modified on: 10/28/2024 00:35:00 UTC