Bug 585276 – <dev-libs/openssl-1.0.2h-r2: Non-constant time codepath followed for certain operations in DSA implementation (CVE-2016-2178)

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Agostino Sarubbo 2016-06-07 11:55:44 UTC]

From ${URL} :

Operations in the DSA signing algorithm should run in constant time in order to avoid side channel 
attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is 
followed for certain operations. This has been demonstrated through a cache-timing attack to be 
sufficient for an attacker to recover the private DSA key.

Upstream fix:

https://git.openssl.org/?p=openssl.git;a=commit;h=399944622df7bd81af62e67ea967c470534090e2


@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 GLSAMaker/CVETool Bot 2016-06-20 09:10:46 UTC]

CVE-2016-2178 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2178):
  The dsa_sign_setup function in crypto/dsa/dsa_ossl.c in OpenSSL through
  1.0.2h does not properly ensure the use of constant-time operations, which
  makes it easier for local users to discover a DSA private key via a timing
  side-channel attack.

[Comment 2 Patrick McLean 2016-06-25 02:20:59 UTC]

Fixed in openssl-1.0.2h-r2

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b4bfc10ce01e37a79da48f2f8349200c7eca78ed

[Comment 3 Aaron Bauman (RETIRED) 2016-06-25 09:44:00 UTC]

(In reply to Patrick McLean from comment #2)
> Fixed in openssl-1.0.2h-r2
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=b4bfc10ce01e37a79da48f2f8349200c7eca78ed

@base-system, shall we wait on stabilization or proceed?

[Comment 4 SpanKY 2016-06-26 02:40:46 UTC]

(In reply to Aaron Bauman from comment #3)

fine to stabilize

[Comment 5 Aaron Bauman (RETIRED) 2016-06-26 04:15:06 UTC]

@arches, please stabilize:

=dev-libs/openssl-1.0.2h-r2

[Comment 6 Agostino Sarubbo 2016-06-27 08:25:25 UTC]

amd64 stable

[Comment 7 Agostino Sarubbo 2016-06-27 08:50:54 UTC]

x86 stable

[Comment 8 Jeroen Roovers (RETIRED) 2016-06-30 07:53:52 UTC]

Stable for HPPA.

[Comment 9 Tobias Klausmann (RETIRED) 2016-06-30 09:26:34 UTC]

Stable on alpha.

[Comment 10 Jeroen Roovers (RETIRED) 2016-07-02 11:08:53 UTC]

Stable for PPC64.

[Comment 11 Markus Meier 2016-07-05 20:56:08 UTC]

arm stable

[Comment 12 Steev Klimaszewski (RETIRED) 2016-07-07 02:29:14 UTC]

arm64 stable

[Comment 13 Agostino Sarubbo 2016-07-08 07:59:07 UTC]

ppc stable

[Comment 14 Agostino Sarubbo 2016-07-08 10:07:39 UTC]

sparc stable

[Comment 15 Agostino Sarubbo 2016-07-08 12:06:50 UTC]

ia64 stable.

Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.

[Comment 16 Aaron Bauman (RETIRED) 2016-07-19 12:28:25 UTC]

Removing unstable arches.

@maintainer(s), please proceed with cleanup.

[Comment 17 SpanKY 2016-07-19 14:37:10 UTC]

(In reply to Aaron Bauman from comment #16)

unstable arches still stabilize core packages needed to build the system

[Comment 18 Aaron Bauman (RETIRED) 2016-07-20 01:07:50 UTC]

(In reply to SpanKY from comment #17)
> (In reply to Aaron Bauman from comment #16)
> 
> unstable arches still stabilize core packages needed to build the system

We should consider that their stabilization efforts are done in separate bugs then.  Security does not support unstable arches.

[Comment 19 Thomas Deutschmann (RETIRED) 2016-09-22 14:12:23 UTC]

Cleanup happened via https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/openssl?id=33f48e56748dc9d6c40326f7654653b6dc49dab5

[Comment 20 GLSAMaker/CVETool Bot 2016-12-07 10:27:32 UTC]

This issue was resolved and addressed in
 GLSA 201612-16 at https://security.gentoo.org/glsa/201612-16
by GLSA coordinator Aaron Bauman (b-man).