RDRAND used directly when default engines loaded in openssl-1.0.1-beta1 through openssl-1.0.1e
as per the FreeBSD announcement[0] and others[1][2] direct use of RDRAND as sole entropy source is not recommended. from Westmere onward you could use AES-NI to make crypto fast in OpenSSL. a common theme is to initialize OpenSSL via ENGINE_load_builtin_engines() which lets OpenSSL take advantage of this acceleration. with Sandy Bridge you also got RDRAND. now load_builtin_engines results in the application using RDRAND directly for all entropy, in addition to accelerating AES. if you are using an application linked with openssl-1.0.1-beta1 through openssl-1.0.1e you should do one of the following: a.) rebuild your OpenSSL with OPENSSL_NO_RDRAND defined. b.) call RAND_set_rand_engine(NULL) after ENGINE_load_builtin_engines(). c.) git pull latest openssl with commit: "Don't use rdrand engine as default unless explicitly requested." - Dr. Stephen Henson the OPENSSL_NO_RDRAND option is recommended; an inadvertent call to load engines elsewhere could re-enable this bad rng behavior. best regards, 0. "FreeBSD Developer Summit: Security Working Group, /dev/random" https://wiki.freebsd.org/201309DevSummit/Security 1. "Surreptitiously Tampering with Computer Chips" https://www.schneier.com/blog/archives/2013/09/surreptitiously.html 2. "How does the NSA break SSL? ... Weak random number generators" http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html
On Sat, Dec 14, 2013 at 4:33 AM, coderman <coderman@gmail.com> wrote:
... if you are using an application linked with openssl-1.0.1-beta1 through openssl-1.0.1e you should do one of the following: ... b.) call RAND_set_rand_engine(NULL) after ENGINE_load_builtin_engines().
correction: this won't leave you vulnerable, but it will crash your app. not broken convention: /* If we are using a version of OpenSSL that supports native RDRAND make sure that we force disable its use as sole entropy source. See https://trac.torproject.org/projects/tor/ticket/10402 */ if (SSLeay() > OPENSSL_V_SERIES(1,0,0)) { t = ENGINE_get_default_RAND(); if (t && (strcmp(ENGINE_get_id(t), "rdrand") == 0)) { log_warn(LD_CRYPTO, "OpenSSL is using RDRAND by default." " Attempting to force disable."); ENGINE_unregister_RAND(t); ENGINE_register_all_complete(); } } see https://peertech.org/dist/tor-latest-rdrand-disable.patch best regards,
On Sat, Dec 14, 2013 at 4:33 AM, coderman <coderman@gmail.com> wrote:
... if you are using an application linked with openssl-1.0.1-beta1 through openssl-1.0.1e you should do one of the following:
updated list with env suggestion: a.) rebuild your OpenSSL with OPENSSL_NO_RDRAND defined b.) call ENGINE_unregister_RAND() on "rdrand" engine followed by ENGINE_register_all_complete() to unregister rdrand as default c.) set OPENSSL_ia32cap="~0x4000000000000000" in global environment (this is poor fix) d.) git pull latest openssl with commit: "Don't use rdrand engine as default unless explicitly requested." - Dr. Stephen Henson "what is affected??" - someone sorry, i am not your distro maintainer. but the list includes, potentially (depending on configure opts / runtime / etc): RHEL 6.5, 7.0 Centos 6.5 Fedora 18,19,rawhide Ubuntu 12.04, 12.10, 13.04, 13.10, trusty Debian 7.0, jessie, sid Gentoo stable&unstable Knoppix 7.0.5, 7.2.0 Kali 1.0.5 Slackware 14, 14.1, current ... if ssh built with --with-ssl-engine. these all use OpenSSL 1.0.1+. (remember both ssh client and server may use engines!) and other libs, like: M2Crypto libpam-sshagent-auth encfs ... which appear to use OpenSSL default engines. but really, you should go check your shit. best regards, P.S. if anyone is aware of RDRAND engine backports to OpenSSL 1.0.0* or 0.9.8* in any distros i'd like to know about it!
On Mon, Dec 16, 2013 at 7:27 PM, coderman <coderman@gmail.com> wrote:
... "what is affected??"
fortunately impacts are less than anticipated! nickm devised most concise fix: RAND_set_rand_method(RAND_SSLeay()); always after ENGINE_load_builtin_engines(). https://gitweb.torproject.org/tor.git/commitdiff/7b87003957530427eadce36ed03... --- full write up is here including a BADRAND engine patch for testing: https://peertech.org/goodrand --- last but not least, notable omissions on NSA role in reqs for random number sources in Appendix E: US Government Role in Current Encryption Standards.: http://cryptome.org/2013/12/nsa-usg-crypto-role.pdf can we get a do-over?
participants (1)
-
coderman