[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201407161732.s6GHW2eO018214@linus.mitre.org>
Date: Wed, 16 Jul 2014 13:32:02 -0400 (EDT)
From: cve-assign@...re.org
To: hanno@...eck.de
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: libressl before 2.0.2 under linux PRNG failure
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux
> forking a process can create repeated random numbers
> Please assign CVE.
The existence of a popular blog post discussing a number of
interrelated LibreSSL and OpenSSL issues doesn't mean that we have a
good way to proceed by assigning a single CVE ID.
It's not yet clear whether zero or more CVE IDs are needed. Here's a
series of quotes from the blog post and its comments, with some
initial thoughts about why we didn't immediately assign a CVE ID.
"OpenSSL faces the same issue [...] The difference is that OpenSSL
provides a way to explicitly reseed the PRNG"
It's possible that some people accept a security principle roughly
like "the design of code surrounding a PRNG must anticipate that any
number of fork calls may occur, and must (without requiring any extra
step within an application) guarantee that the random-number stream
isn't duplicated." If this is the security principle, then maybe there
should be separate CVE IDs for OpenSSL (requires an extra step) and
LibreSSL before 2.0.2 (cannot guarantee this at all).
"LibreSSL aims to be a drop-in replacement for OpenSSL"
We didn't immediately find any statement on www.libressl.org or in a
libressl-2.0.x.tar.gz README stating that the useful functionality of
LibreSSL is supposed to exactly match OpenSSL. One could assert that
the above security principle is false, and instead accept a security
principle of "the best behavior of a random-number stream after a fork
is undefined; different choices might be preferred by different
applications." In other words, a behavior that is surprising to former
OpenSSL users isn't inherently wrong unless the LibreSSL documentation
ruled out any surprises.
Also, for example, a CVE ID probably can't be assigned for the general
concept of "unfortunately, has turned RAND_poll into a no-op"
(especially because the blog post suggests that this no-op change was
intentional and will remain in place).
More generally, both of these:
"OpenSSL is safer for two reasons ... 1. If OpenSSL can't open
/dev/urandom, RAND_bytes returns an error code."
"OpenSSL is safer for two reasons ... 2. OpenSSL allows you to
explicitly seed the PRNG by calling RAND_poll."
are apparently closer to the level of a "possibly controversial design
decision" than an "implementation error."
Possibly the combination of
"Their fix is to use pthread_atfork to register a callback that
reseeds the PRNG when fork() is called."
and
"The fix is a huge step in the right direction but is not perfect - a
program that invokes the clone syscall directly will bypass the atfork
handlers."
would require two CVE IDs, if the vendor decided to describe their
code change specifically as a vulnerability fix, and then an
incomplete fix was asserted because of this clone scenario.
"Comment 23634 ... a very common privilege separation technique is
[...] OpenSSL has the API to make this work (as do other crypto
libraries such as libsodium); LibreSSL does not."
In most cases, a missing API does not qualify for a CVE ID.
"LibreSSL provides no good way to use the PRNG from a process running
inside a chroot jail. ... Unfortunately, /dev/urandom usually doesn't
exist inside chroot jails."
and
"I see no reason why /dev/urandom cannot be made available inside
containers: ... If it is not there, the container is likely
misconfigured."
This one seems to be different perspectives about what Linux
configurations are common or correct, and what Linux configurations
are uncommon or incorrect.
"it falls back to a truly scary-looking function (lines 306-517) that
attempts to get entropy from sketchy sources such as the PID, time of
day, memory addresses, and other properties of the running process."
This may be another example of a design tradeoff. Some applications
might prefer "sketchy sources" as an alternative to reporting an error
about lack of good sources. Other applications definitely would not
prefer this.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTxrZPAAoJEKllVAevmvmspQYIAKFg+GDqTZpNVec2aLARp0aa
YM8VjTaA1XMKlkcOGNoc+Qx7RBC9qtRX0MQqUbl5bW/8taktcTlsNs7J+FEKR11b
2hT2u5IRmr55ghznoRDadffptAxhqSL1eeWlAg5OJjvtqvJBvbD2GXTSDol2dqtJ
5Eav8hAsQx7pnWxtYuuL7mDQwgCobB/jgaEu2QJFMK0KyLsCOo80cQSvxsx/tbvw
OHnvO8OeqOXjVnaK0zs0LeWq1gyQMdwDwNQ9sjFaPnvvPIjXPJQKDQJWiAnOnV4T
JFhSzMbWrm8XochCS8ql2nmcZ6X5XzocWehd7DuM3R18F3LPu+oxwB+8mS319SM=
=1h5L
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
