From nobody@FreeBSD.org  Fri Apr 18 03:51:49 2014
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTPS id 97EB242C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 18 Apr 2014 03:51:49 +0000 (UTC)
Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 84F2F180A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 18 Apr 2014 03:51:49 +0000 (UTC)
Received: from cgiserv.freebsd.org ([127.0.1.6])
	by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s3I3pmkl016939
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 18 Apr 2014 03:51:48 GMT
	(envelope-from nobody@cgiserv.freebsd.org)
Received: (from nobody@localhost)
	by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s3I3pm4l016901;
	Fri, 18 Apr 2014 03:51:48 GMT
	(envelope-from nobody)
Message-Id: <201404180351.s3I3pm4l016901@cgiserv.freebsd.org>
Date: Fri, 18 Apr 2014 03:51:48 GMT
From: Kenji Rikitake <kenji@k2r.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: FreeBSD base OpenSSL puts private keys to RNG seeds
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         188745
>Category:       kern
>Synopsis:       [openssl] FreeBSD base OpenSSL puts private keys to RNG seeds
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    secteam
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 18 04:00:00 UTC 2014
>Closed-Date:    
>Last-Modified:  Sat Apr 19 00:50:01 UTC 2014
>Originator:     Kenji Rikitake
>Release:        10.0-STABLE
>Organization:
>Environment:
FreeBSD minimax.priv.k2r.org 10.0-STABLE FreeBSD 10.0-STABLE #33 r264285: Wed Apr  9 09:25:02 JST 2014     root@minimax.priv.k2r.org:/usr/obj/usr/src/sys/K2RKERNEL  amd64
>Description:
OpenBSD devs report OpenSSL puts RSA private keys as they are for seeding the PRNG. See http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf for the details.

On 10.0-STABLE, I've found the same practice under /usr/src/crypto/openssl/crypto at:

rsa/rsa_crpt.c
229:         RAND_add(rsa->d->d, rsa->d->dmax * sizeof rsa->d->d[0], 0.0);

evp/evp_pkey.c
153: RAND_add(p8->pkey->value.octet_string->data,

pem/pem_lib.c
391:         RAND_add(data,i,0);/* put in the RSA key. */
>How-To-Repeat:
Recompile the userland. (Note: the similar source code may exist in the Port OpenSSL too)
>Fix:
OpenBSD team has already removed the problematic code as described in http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf

I think the same security audit on FreeBSD is seriously required.

>Release-Note:
>Audit-Trail:

From: Eitan Adler <lists@eitanadler.com>
To: Kenji Rikitake <kenji@k2r.org>
Cc: bug-followup <bug-followup@freebsd.org>
Subject: Re: bin/188745: FreeBSD base OpenSSL puts private keys to RNG seeds
Date: Fri, 18 Apr 2014 14:58:17 -0700

 On 17 April 2014 20:51, Kenji Rikitake <kenji@k2r.org> wrote:
 >>Environment:
 > FreeBSD minimax.priv.k2r.org 10.0-STABLE FreeBSD 10.0-STABLE #33 r264285: Wed Apr  9 09:25:02 JST 2014     root@minimax.priv.k2r.org:/usr/obj/usr/src/sys/K2RKERNEL  amd64
 >>Description:
 > OpenBSD devs report OpenSSL puts RSA private keys as they are for seeding the PRNG. See http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bf for the details.
 >
 > On 10.0-STABLE, I've found the same practice under /usr/src/crypto/openssl/crypto at:
 
 Please see: http://blog.ngas.ch/archives/2014/04/17/what_is_this_private_key_doing_in_my_random_pool/index.html
 
 In particular: "So the patch which was committed by the OpenBSD people
 actually has the potential to weaken the entropy of the OpenSSL random
 pool, but it was never a security or privacy concern,"
 
 
 -- 
 Eitan Adler
Responsible-Changed-From-To: freebsd-bugs->secteam 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Apr 18 23:22:54 UTC 2014 
Responsible-Changed-Why:  
over to secteam for analysis. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=188745 

From: Kenji Rikitake <kenji@k2r.org>
To: Eitan Adler <lists@eitanadler.com>
Cc: bug-followup <bug-followup@freebsd.org>
Subject: Re: bin/188745: FreeBSD base OpenSSL puts private keys to RNG seeds
Date: Sat, 19 Apr 2014 09:48:15 +0900

 --047d7bdc17d822a66b04f75a9fa8
 Content-Type: text/plain; charset=UTF-8
 
 Thanks for the reference. I've read the article by Tonnerre Lombard.
 
 I'm still not convinced, however, why processing private keys
 just for seeding a PRNG is a safe practice, regardless of the
 safety of RAND_add() function.
 
 
 
 On Sat, Apr 19, 2014 at 6:58 AM, Eitan Adler <lists@eitanadler.com> wrote:
 
 > On 17 April 2014 20:51, Kenji Rikitake <kenji@k2r.org> wrote:
 > >>Environment:
 > > FreeBSD minimax.priv.k2r.org 10.0-STABLE FreeBSD 10.0-STABLE #33
 > r264285: Wed Apr  9 09:25:02 JST 2014     root@minimax.priv.k2r.org:/usr/obj/usr/src/sys/K2RKERNEL
 >  amd64
 > >>Description:
 > > OpenBSD devs report OpenSSL puts RSA private keys as they are for
 > seeding the PRNG. See
 > http://freshbsd.org/commit/openbsd/e5136d69ece4682e6167c8f4a8122270236898bffor the details.
 > >
 > > On 10.0-STABLE, I've found the same practice under
 > /usr/src/crypto/openssl/crypto at:
 >
 > Please see:
 > http://blog.ngas.ch/archives/2014/04/17/what_is_this_private_key_doing_in_my_random_pool/index.html
 >
 > In particular: "So the patch which was committed by the OpenBSD people
 > actually has the potential to weaken the entropy of the OpenSSL random
 > pool, but it was never a security or privacy concern,"
 >
 >
 > --
 > Eitan Adler
 >
 
 --047d7bdc17d822a66b04f75a9fa8
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"ltr">Thanks for the reference. I&#39;ve read the article by Ton=
 nerre Lombard.<div><br><div>I&#39;m still not convinced, however, why proce=
 ssing private keys</div><div>just for seeding a PRNG is a safe practice, re=
 gardless of the</div>
 </div><div>safety of RAND_add() function.</div><div><br></div></div><div cl=
 ass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Apr 19, 2014=
  at 6:58 AM, Eitan Adler <span dir=3D"ltr">&lt;<a href=3D"mailto:lists@eita=
 nadler.com" target=3D"_blank">lists@eitanadler.com</a>&gt;</span> wrote:<br=
 >
 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
 x #ccc solid;padding-left:1ex">On 17 April 2014 20:51, Kenji Rikitake &lt;<=
 a href=3D"mailto:kenji@k2r.org">kenji@k2r.org</a>&gt; wrote:<br>
 &gt;&gt;Environment:<br>
 &gt; FreeBSD <a href=3D"http://minimax.priv.k2r.org" target=3D"_blank">mini=
 max.priv.k2r.org</a> 10.0-STABLE FreeBSD 10.0-STABLE #33 r264285: Wed Apr =
 =C2=A09 09:25:02 JST 2014 =C2=A0 =C2=A0 root@minimax.priv.k2r.org:/usr/obj/=
 usr/src/sys/K2RKERNEL =C2=A0amd64<br>
 
 &gt;&gt;Description:<br>
 &gt; OpenBSD devs report OpenSSL puts RSA private keys as they are for seed=
 ing the PRNG. See <a href=3D"http://freshbsd.org/commit/openbsd/e5136d69ece=
 4682e6167c8f4a8122270236898bf" target=3D"_blank">http://freshbsd.org/commit=
 /openbsd/e5136d69ece4682e6167c8f4a8122270236898bf</a> for the details.<br>
 
 &gt;<br>
 &gt; On 10.0-STABLE, I&#39;ve found the same practice under /usr/src/crypto=
 /openssl/crypto at:<br>
 <br>
 Please see: <a href=3D"http://blog.ngas.ch/archives/2014/04/17/what_is_this=
 _private_key_doing_in_my_random_pool/index.html" target=3D"_blank">http://b=
 log.ngas.ch/archives/2014/04/17/what_is_this_private_key_doing_in_my_random=
 _pool/index.html</a><br>
 
 <br>
 In particular: &quot;So the patch which was committed by the OpenBSD people=
 <br>
 actually has the potential to weaken the entropy of the OpenSSL random<br>
 pool, but it was never a security or privacy concern,&quot;<br>
 <span class=3D"HOEnZb"><font color=3D"#888888"><br>
 <br>
 --<br>
 Eitan Adler<br>
 </font></span></blockquote></div><br></div>
 
 --047d7bdc17d822a66b04f75a9fa8--
>Unformatted:
