Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 592070 (CVE-2016-6329)

Summary: <net-misc/openvpn-2.3.12: Birthday attack against 64 bit block ciphers including Blowfish (BF-CBC) used by default (SWEET32)
Product: Gentoo Security Reporter: Agostino Sarubbo <ago>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: minor CC: jer, mrueg
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://sweet32.info
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1369386
Whiteboard: B3 [glsa cve]
Package list:
Runtime testing required: ---

Description Agostino Sarubbo gentoo-dev 2016-08-25 09:16:19 UTC
From ${URL} :

Ciphers with 64-bit block sizes used in CBC mode were found to be vulnerable to birthday attack when key 
renegotiation doesn't happen frequently or at all in long running connections. Blowfish cipher as used in 
OpenVPN by default is vulnerable to this attack, that allows remote attacker to recover partial plaintext 
information (XOR of two plaintext blocks).

External References:

https://community.openvpn.net/openvpn/wiki/SWEET32
https://sweet32.info/


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Manuel RĂ¼ger (RETIRED) gentoo-dev 2016-08-25 13:04:58 UTC
I added 2.3.12 which includes this commit https://github.com/OpenVPN/openvpn/commit/610fdbbdb0abf65c1e7620143afccd62cd162a8f

@arches please get 2.3.12 stable
Comment 2 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-08-25 19:24:11 UTC
Is an upgrade sufficient in this case? The referenced commit changes the list output of --show-ciphers, but as there doesn't seem to be cipher negotiation or transport of such in the data channel, it still use blowfish after upgrade. Seems a change away from this requires config change both on server and clients simultaneously
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2016-08-25 20:10:19 UTC
Stable for HPPA PPC64.

(In reply to Kristian Fiskerstrand from comment #2)
> Is an upgrade sufficient in this case? The referenced commit changes the
> list output of --show-ciphers, but as there doesn't seem to be cipher
> negotiation or transport of such in the data channel, it still use blowfish
> after upgrade. Seems a change away from this requires config change both on
> server and clients simultaneously

Correct. I've been having a lovely evening setting up additional openvpn servers with alternative ciphers.

The new version would help setting up new servers and clients, though.
Comment 4 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-08-25 21:11:00 UTC
Also good writeup at http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html
Comment 5 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-08-28 19:54:16 UTC
https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible mitigants and confirms that cipher change in stable versions (<2.4) requires both server and client config change. It also mentions; 2. Renegotiate more often: If changing the cipher is not possible, for example because you don't control the server, or can not update all client configs on a short notice, you can renegotiate new keys more often. For example, add --reneg-bytes 64000 to your config to renegatiate after every 64 megabytes.

I haven't seen any performance metrics on how this might affect things though.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2016-08-29 03:51:52 UTC
(In reply to Kristian Fiskerstrand from comment #5)
> https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible
> mitigants

...and then you quoted a lot of it.

> For example, add --reneg-bytes
> 64000 to your config to renegatiate after every 64 megabytes.
> 
> I haven't seen any performance metrics on how this might affect things
> though.

Well, for one thing, it temporarily blocks the connection after every 64 kilobytes of data during renegotiation. Not 64 megabytes as the advice suggests.
Comment 7 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-08-30 13:30:42 UTC
(In reply to Jeroen Roovers from comment #6)
> (In reply to Kristian Fiskerstrand from comment #5)
> > https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible
> > mitigants

..

> 
> Well, for one thing, it temporarily blocks the connection after every 64
> kilobytes of data during renegotiation. Not 64 megabytes as the advice
> suggests.

Yeah, that likely won't work too well. So basically only way to solve it properly is setting up a secondary VPN server with changed config and do a rollout of clients to the new cipher whenever possible...
Comment 8 Tobias Klausmann (RETIRED) gentoo-dev 2016-09-02 19:21:44 UTC
Stable on alpha.
Comment 9 Agostino Sarubbo gentoo-dev 2016-09-10 12:50:03 UTC
amd64 stable
Comment 10 Markus Meier gentoo-dev 2016-09-24 19:20:08 UTC
arm stable
Comment 11 Agostino Sarubbo gentoo-dev 2016-09-29 08:43:06 UTC
x86 stable
Comment 12 Agostino Sarubbo gentoo-dev 2016-09-29 09:38:03 UTC
sparc stable
Comment 13 Agostino Sarubbo gentoo-dev 2016-09-29 12:38:49 UTC
ppc stable
Comment 14 Agostino Sarubbo gentoo-dev 2016-09-29 13:31:16 UTC
ia64 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 15 Yury German Gentoo Infrastructure gentoo-dev 2016-10-31 05:48:28 UTC
Maintainer(s), please drop the vulnerable version(s).
Version: 2.3.11

Added to an existing GLSA Request.
Comment 16 GLSAMaker/CVETool Bot gentoo-dev 2016-11-01 13:26:43 UTC
This issue was resolved and addressed in
 GLSA 201611-02 at https://security.gentoo.org/glsa/201611-02
by GLSA coordinator Aaron Bauman (b-man).