One more OpenVPN vulnerability (CVE-2017-12166)

This concerns a remote buffer overflow vulnerability in OpenVPN. It has been fixed in OpenVPN 2.4.4 and 2.3.18. It is suspected that only a small number of users is vulnerable to this issue, because it requires having explicitly enabled the outdated ‘key method 1’.

The advisory can be found here:

If you appreciate my discovery, you may donate some BTC to address 1BnLyXN2QwdMZLZTNqKqY48bU4hN2A3MwZ

In ssl.c, key_method_1_read() calls read_key() which doesn’t perform adequate
bounds checks. cipher_length and hmac_length are specified by the

1643 uint8_t cipher_length;
1644 uint8_t hmac_length;
1646 CLEAR(*key);
1647 if (!buf_read(buf, &cipher_length, 1))
1648 {
1649 goto read_err;
1650 }
1651 if (!buf_read(buf, &hmac_length, 1))
1652 {
1653 goto read_err;
1654 }

And this many bytes of data are then read into key->cipher and key->hmac:

1656 if (!buf_read(buf, key->cipher, cipher_length))
1657 {
1658 goto read_err;
1659 }
1660 if (!buf_read(buf, key->hmac, hmac_length))
1661 {
1662 goto read_err;
1663 }

In other words, it’s a classic example of lack of a bounds check resulting in a buffer overflow.

2 thoughts on “One more OpenVPN vulnerability (CVE-2017-12166)

  1. hi,Guido,when I reproduce this vulnerability, I found that, while the read_key() has this potential stack overflow, however, the cipher_length and hmac_length is read from buf which is received from the peer who use write_key. I found in the write_key, there is a ASSERT(kt->cipher_lengthhmac_length<=MAX_YYY), this means it will not cause the receiver's cipher_length more than MAX_XXX and MAX_YYY, is it right???
    Hope your response, thank you very much!

    1. Hi,

      Yes, read_key() on the server reads data that passed to write_key() on the client. In order to trigger the bug, you need to modify the client OpenVPN code to send a wrong key size.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.