[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] OpenVPN CVE-2017-12166: remote buffer overflow
From:       Guido Vranken <guidovranken () gmail ! com>
Date:       2017-09-28 10:06:51
Message-ID: CAO5O-ELKaUKMBBvYHN5rC5WYM7Z0qVHhsWL6zbqAXUpVcThoZA () mail ! gmail ! com
[Download RAW message or body]

This concerns a remote buffer overflow vulnerability in OpenVPN. It
has been fixed in OpenVPN 2.4.4 and 2.3.18, released on 26 Sept 2017.
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 OpenVPN advisory can be found here:
https://community.openvpn.net/openvpn/wiki/CVE-2017-12166

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
peer:

1643 uint8_t cipher_length;
1644 uint8_t hmac_length;
1645
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 bounds check resulting in a
buffer overflow.

Like my previous set of OpenVPN vulnerabilities, this issue was also
found with fuzzing.

Guido
[prev in list] [next in list] [prev in thread] [next in thread]