Re: [Openvpn-devel] Windows build fix for CVE-2015-4000

[David S. <ope...@to...>]

On 25/06/15 17:42, Joseph S. Testa II wrote:
> On 06/25/2015 10:46 AM, Jan Just Keijser wrote:
>> Joseph S. Testa II wrote:
>>> Hi all,
>>>
>>>     I was wondering if an updated Windows build is being planned for
>>> release soon to fix CVE-2015-4000, et. al, as described in
>>> http://www.openssl.org/news/secadv_20150611.txt.
>>>
>>>     I haven't seen anyone talk about this on the mailing list since
>>> the advisory came out two weeks ago, so I thought I'd ask.

[...snip...]

> Thanks for the info.  How about the other CVE's listed in that OpenSSL 
> advisory?  I'm not able to tell if they're an issue in conjunction with 
> OpenVPN.  Has anyone done a review on them as well?

I'm no security expert, so bear that in mind.  But I believe I have been
poking long enough in the OpenVPN code base to have a certain overview
of the SSL/TLS stack used by OpenVPN.


* Malformed ECParameters causes infinite loop (CVE-2015-1788)
Elliptic curves support is very limited in OpenVPN and not widely used,
so I doubt this will be an issue on the client side.  Use of --tls-auth
should at least reduce the attack vector to one of your own users.


* Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789)
This might be an issue on OpenVPN on the server side.  However,
--tls-auth will reduce the attack vector to one of your own users.

On the client side, I don't see how it could get a bad CRL file
installed and configured, and I don't recall any authentication
callbacks being used on the client side.  In addition, if the client got
a problem - there is an even bigger problem how the client managed to
connect to a faulty OpenVPN server.


* PKCS7 crash with missing EnvelopedContent (CVE-2015-1790)
AFAIR, we don't do much PKCS#7 handling, so most likely not an issue for
OpenVPN.  But this one should be double checked.


* CMS verify infinite loop with unknown hash function (CVE-2015-1792)
I haven't studied how OpenVPN verifies signed data, so this is unknown
at the moment - unless Steffan or James have investigated this.


* Race condition handling NewSessionTicket (CVE-2015-1791)
This is not an issue for OpenVPN in normal situations.  However, if an
attacker writes a special attack client using the OpenVPN protocol and
it uses multiple connections in parallel to the server, this might be an
issue.  But again, --tls-auth to the rescue, which reduces the possible
attacker to one of your own users.


* Invalid free in DTLS (CVE-2014-8176)
OpenVPN does not implement DTLS, so this isn't an issue for OpenVPN.


Bottom line:  --tls-auth is a fairly good protection layer against
OpenSSL (or PolarSSL/mbedTLS) issues.  And I would sleep quite well at
night if clients aren't updated to openssl 1.0.2b or 1.0.1n.


-- 
kind regards,

David Sommerseth