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.