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
signature.asc
Description: OpenPGP digital signature
