Security specialist Guido Vranken has found four serious OpenVPN security vulnerabilities with his fuzzer. Interestingly, this happened after the recently conducted two full security audits of the source code of this program. This suggests that the source audit does not give an absolute guarantee of the absence of bugs.

Guido Vranken himself believes that in some cases, human auditing is not the best option at all. He says that OpenVPN audit sponsors (money raised through crowdfunding) should not have been paid for a manual audit, but it was necessary to hire experts who would be interested in finding vulnerabilities by any means (through the same fuzzing). Such a strategy would bring the greatest dividends. At least now we see that fuzzing turned out to be more efficient than manual analysis.

OpenVPN is a free open source implementation of virtual private network (VPN) technology for creating encrypted channels between PCs. Created by James Yonan and distributed under the GNU GPL license.

Already released patches for OpenVPN. It is necessary to upgrade to versions 2.4.3 and 2.3.17 as soon as possible in order to feel safe. Still, the holes found Guido, really very serious.
')
Guido Vranken says that in this case automatic analysis turned out to be more efficient than the labor of paid auditors, so that in the future it is worth considering what to spend on the budget. According to his scenario, an ideal audit should begin with fuzzing, and only after automatic analysis of the code should experts analyze it.

Yes, experts can find vulnerabilities where fuzzing is ineffective. For example, people can check cryptographic operations and procedures, check application-level logic, assess dependencies on certain versions of libraries, estimate the likelihood of personal information leaks through various third-party channels, and other ways to show their expertise. But forcing people to look for the same memory errors is a completely irrational use of resources, Guido said. This is much faster and more efficiently done by automatic means.

Vulnerabilities

CVE-2017-7521

Several errors were found in the extract_x509_extension() function in the extract_x509_extension() file ssl_verify_openssl.c once, including the incorrect procedure for freeing memory and the incorrect use of the GENERAL_NAMES structure.

 GENERAL_NAMES *extensions; int nid = OBJ_txt2nid(fieldname); extensions = (GENERAL_NAMES *)X509_get_ext_d2i(cert, nid, NULL, NULL); 

Guido Vranken writes that because of this implementation, different NIDs require different storage structures. That is, using the GENERAL_NAMES structure for each NID will result in spectacular drops for some NIDs.

Accordingly, this vulnerability is classified as a remote server crash / memory leak / double memory free (double-free, the same chunk of memory is released twice).

CVE-2017-7520

Remote client failure (including MiTM), data leakage.

This vulnerability threatens only those who use OpenVPN to connect to the NTLM version 2 proxy.

The following code was found ntlm_phase_3() in ntlm.c file:

 if (( *((long *)&buf2[0x14]) & 0x00800000) == 0x00800000) /* Check for Target Information block */ { tib_len = buf2[0x28]; /* Get Target Information block size */ if (tib_len > 96) { tib_len = 96; } { char *tib_ptr = buf2 + buf2[0x2c]; /* Get Target Information block pointer */ memcpy(&ntlmv2_blob[0x1c], tib_ptr, tib_len); /* Copy Target Information block into the blob */ } } 

The array buf2 here contains data obtained by a peer (proxy).

Fuzzing showed a few bugs. First, if buf[0x28] contains a value of 080 or more, then tib_len will become negative, which will destroy memcpy. Secondly, buf[0x2c] used as an index for the array buf2 . If it takes a value of 080 or more, then tib_len will again become negative and in this case will indicate in front of buf2 , which will lead to data leakage. The memory from this address is then copied to ntlmv2_blob , which is then sent to the feast. There is a data leak and the potential for attack MiTM. The user's password, by the way, is also stored on the stack, and will also be sent to the peer in clear text. Such an attack can be triggered by an attacker in remote mode.

Damaged client stack buffer and MITM (no CVE)

This type of attack is extremely unrealistic, it requires a combination of a number of conditions, including the user must choose a username that ends with a backslash, and NTLM version 2 should be used.

CVE-2017-7508

Vulnerability allows remote crash of the server on which OpenVPN is running, if an attacker sends specially compiled data to it.

The point is that the mss_fixup_dowork() function in the mss_fixup_dowork() file contains the following code:

 ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr)); 

Guido Vranken writes that it is possible to construct such a package for the server so that the specified statement is not executed and the server stops.

CVE-2017-7522

The mbed TLS / PolarSSL server –x509-track requires that the –x509-track configuration option be installed on the server for its success. Vulnerabilities are subject to OpenVPN 2.4 (not 2.3) compiled with mbed TLS / PolarSSL cryptographic backend.

Another bug was found (no CVE) with a stack buffer overflow in the case of an exceptionally long –tls-cipher option, but this was not classified as a real vulnerability, because operation is possible only with unreliable settings, and then the attack is available through other channels.

To search for vulnerabilities, Vranken used the libFuzzer fuzzer along with AddressSanitizer (ASAN), UndefinedBehaviorSanitizer (UBSAN) and MemorySanitizer (MSAN).