wiki:VulnerabilitiesFixedInOpenVPN243

Introduction

In May/June 2017 Guido Vranken threw a fuzzer at OpenVPN 2.4.2. In the process he found several vulnerabilities and reported them to the OpenVPN project. The OpenVPN Git branches were patches as follows:

  • master: 7 patches
  • release/2.4: 7 patches
  • release/2.3: 5 patches (no mbedtls patches)
  • release/2.2: 1 patch (only the NTLM patch)

The first releases to have these fixes are OpenVPN 2.4.3 and 2.3.17. These releases also include a bunch of fixes not related to Guido's findings.

PLEASE NOTE We have noticed that the Cloudflare front have been serving out the wrong contents for several users. See this page for more information.

Vulnerabilities

Remotely-triggerable ASSERT() on malformed IPv6 packet

This vulnerability is of serious nature: it can be used to remotely shutdown an openvpn server or client if IPv6 and --mssfix are enabled and the IPv6 networks used inside the VPN are known.

This issue was found by Guido Vranken and has been assigned CVE-2017-7508. It has been fixed in commit "Fix remotely-triggerable ASSERT() on malformed IPv6 packet":

  • master: c3f47077a7
  • release/2.4: ed28cde3d8
  • release/2.3: fc61d1bda1

Pre-authentication remote crash/information disclosure for clients

If clients use a HTTP proxy with NTLM authentication (i.e. "--http-proxy <server> <port> [<authfile>|'auto'|'auto-nct'] ntlm2"), a man-in-the-middle attacker between the client and the proxy can cause the client to crash or disclose at most 96 bytes of stack memory. The disclosed stack memory is likely to contain the proxy password.

If the proxy password is not reused, this is unlikely to compromise the security of the OpenVPN tunnel itself. Clients who do not use the --http-proxy option with ntlm2 authentication are not affected.

This issue has been assigned CVE-2017-7520. It has been fixed in commit "Prevent two kinds of stack buffer OOB reads and a crash for invalid input data":

  • master: 7718c8984f
  • release/2.4: 043fe32787
  • release/2.3: f38a4a1059
  • release/2.2: 4bec9d25d5

Potential double-free in --x509-alt-username

OpenVPN did not check the return value of ASN1_STRING_to_UTF8() in extract_x509_extension(). Ignoring such a failure could result in buf being free'd twice. An error in ASN1_STRING_to_UTF8() can be caused remotely if the peer can make the local process run out of memory.

The problem can only be triggered for configurations that use the --x509-alt-username option with an x509 extension (i.e. the option parameter starts with "ext:"). Extensive testing by Guido Vranken gives confidence that this function is very unlikely to fail in real-world usage (using subjectAltName or issuerAltName extensions) for other reasons than memory exhaustion.

This issue was found by Guido Vranken and has been assigned CVE-2017-7521. It has been fixed in commit "Fix potential double-free in --x509-alt-username (CVE-2017-7521)":

  • master: cb4e35ece4
  • release/2.4: 0400840671
  • release/2.3: 1dde0cd6e5

Remote-triggerable memory leaks

Several of our OpenSSL-specific certificate-parsing code paths did not always clear all allocated memory. Since a client can cause a few bytes of memory to be leaked for each connection attempt, a client can cause a server to run out of memory and thereby kill the server. That makes this a (quite inefficient) DoS attack.

In particular when using the --x509-alt-username option on openssl builds with an extension (argument prefixed with "ext:", e.g. "ext:subjectAltName"), the code would not free all allocated memory.

This issue was found by Guido Vranken and has been assigned CVE-2017-7521. It has been fixed in commit "Fix remote-triggerable memory leaks (CVE-2017-7521)":

  • master: 2d032c7fcd
  • release/2.4: 2341f71619
  • release/2.3: 84e1775961

Post-authentication remote DoS when using the --x509-track option

asn1_buf_to_c_string() returned a literal string if the input ASN.1 string contained a NUL character, while the caller expects a mutable string. The caller will attempt to change this string, which allows a client to crash a server by sending a certificate with an embedded NUL character.

The other way around is not interesting, as servers are allowed to stop a client by design.

Impact analysis:

  • applies to mbedtls builds only
  • introduced in 2.4 (so 2.3 is not affected)
  • can only be exploited if the --x509-track option is used
  • requires the CA to sign a certificate with an embedded NUL in the certificate subject

This issue was found by Guido Vranken and has been assigned CVE-2017-7522. It has been fixed in commit "mbedtls: fix --x509-track post-authentication remote DoS (CVE-2017-7522)":

  • master: 426392940c
  • release/2.4: 67edada0be

Null-pointer dereference in establish_http_proxy_passthru()

Client could crashes if the peer did not specify the 'realm' and/or 'nonce' values. These pointers are dereferenced in DigestCalcHA1() and DigestCalcResponse?(); hence, if not set, a null-pointer dereference would occur.

This problem has been fixed in commit "Fix a null-pointer dereference in establish_http_proxy_passthru()":

  • master: 14865773ad
  • release/2.4: bf547b8ac7
  • release/2.3: 479b6d13d8

Issues with little to no practical security impact

Many of the findings were such that they don't have a practical security impact. Nevertheless they are bugs and were fixed in the following Git commits:

  • Restrict --x509-alt-username extension types
  • Fix potential 1-byte overread in TCP option parsing
  • Fix mbedtls fingerprint calculation
  • openssl: fix overflow check for long --tls-cipher option
  • Ensure option array p[] is always NULL-terminated
  • Pass correct buffer size to GetModuleFileNameW() (Quarkslabs finding 5.6)
Last modified 3 months ago Last modified on 06/22/17 16:18:40

Attachments (1)

Download all attachments as: .zip