CVE-2014-0076 and OpenSSL 0.9.8
It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based distributions as well, correct? It doesn't appear that the fix has been applied to the OpenSSL_0_9_8-stable branch yet though. I suppose it might need a few tweaks to apply there cleanly... Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RSA [FIPS 186-4] issue
Hi all, We use the OpenSSL FIPS Object Module v.2.0, but are not allowed anymore (as of the start of this year) to submit new product for validation because the RSA implementation is only FIPS 186-2 compliant. Based on extensive review and research it seems to be possible to patch the RSA key generation to be FIPS 186-4 compliant and apparently (correct me if I am wrong) the sign/verify is close enough to FIPS 186-4 to pass. I am in no way capable of writing such a patch and was hoping that someone is willing to share. To be more specific I need a patch that will change the key generation from: d = e-1 mod((p-1)(q-1)) to this: d = e-1 mod(LCM(p-1, q-1)) I would appreciate any comment about the statement that the RSA implementation for sign and verify will pass the CAVP testing for FIPS 186-4. As usual thanks for your help Regards, LJB
Re: CVE-2014-0076 and OpenSSL 0.9.8
On Wed, 26 Mar 2014 06:55:41 + geoff_l...@mcafee.com wrote: It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based distributions as well, correct? Yes, 0.9.8y also uses the same Lopez/Dahab algo when computing elliptic scalar mult on curves defined over binary fields (i.e. GF(2^m)). It doesn't appear that the fix has been applied to the OpenSSL_0_9_8-stable branch yet though. I suppose it might need a few tweaks to apply there cleanly... The tweaks are minimal and I've placed a backport here: http://sf.net/projects/mancha/files/sec/openssl-0.9.8y_CVE-2014- 0076.diff (.sig in same dir) Note: all 0.9.8y ecdsa regression tests passed post-patch. --mancha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0076 and OpenSSL 0.9.8
On Tue, Mar 25, 2014, geoff_l...@mcafee.com wrote: It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based distributions as well, correct? Yes that's correct but we weren't planning on making any more 0.9.8 releases. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0076 and OpenSSL 0.9.8
On Tue, Mar 25, 2014 at 09:23:58PM +, geoff_l...@mcafee.com wrote: It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based distributions as well, correct? Isn't this an ECDSA issue? I thought that EC algorithms are by default disabled in OpenSSL 0.9.8 (require explicit ECCdraft in cipherlist to enable and do not appear in either DEFAULT or ALL). Perhaps given the number of post-0.9.8y commits pending on the OpenSSL_0_9_8-stable branch, one final z release could be issued, no more commits made after that, and plans to not make any further releases announced? d471adf Remove duplicate statement. (cherry picked from commit 5a7652c3e585e970e5b778074c92e617e48fde38) 2fb8642 Clarify docs. c44d95c fix shell syntax PR#3216 (cherry picked from commit 080ae6843299c873808c04487d4ccf51624fe618) 0da40f0 Restore SSL_OP_MSIE_SSLV2_RSA_PADDING 7f722c9 remove obsolete STATUS file 4268216 Add release dates to NEWS 17540b7 Simplify and update openssl.spec b70e4d3 Fixes for no-static-engine and Windows builds. d9519a4 Update CHANGES. 5ac9786 Fix compilation with this branch's definition of SSL_CIPHER. 0b05204 Remove empty line. a4bfeff Tidy up comments. 43433b3 Use TLS version supplied by client when fingerprinting Safari. 020a478 Backport TLS 1.1/1.2 #defines cadbbd5 Don't prefer ECDHE-ECDSA ciphers when the client appears to be Safari on OS X. OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers. ff7b021 Fix overly lenient comparisons: e7e4d50 Correct ECDSA example. (cherry picked from commit 3a918ea2bbf4175d9461f81be1403d3781b2c0dc) 9204e7e DTLS message_sequence number wrong in rehandshake ServerHello 257df40 DTLS handshake fix. a44c9b9 Set s-d1 to NULL after freeing it. (cherry picked from commit 04638f2fc335a6dc2af8e5d556d36e29c261dcd2) 1cbd745 Print out DSA key if parameters absent. e1e39a2 Disable compression for DTLS. 01de6e2 x86cpuid.pl: make it work with older CPU. 05689a1 Avoid unnecessary fragmentation. (cherry picked from commit 80ccc66d7eedb2d06050130c77c482ae1584199a) 1643edc Encode INTEGER correctly. 1546fb7 Typo. b7d222c Merge branch 'OpenSSL_0_9_8-stable' of /home/steve/src/git/openssl into OpenSSL_0_9_8-stable a93cc7c Use orig_len, not rec-orig_len 8988407 Fix POD errors to stop make install_docs dying with pod2man 2.5.0+ b2afc0a cms-test.pl: make it work with not-so-latest perl. (cherry picked from commit 9c437e2faded18b4ef6499d7041c65d6e216955b) a8655eb Check DTLS_BAD_VER for version number. f751dc4 Fix for SSL_get_certificate fbe621d Fix in ssltest is no-ssl2 configured (cherry picked from commit cbf9b4aed3e209fe8a39e1d6f55aaf46d1369dc4) 2e9fd43 use 10240 for tar record size 1638ce7 FAQ/README: we are now using Git instead of CVS (cherry picked from commit f88dbb8385c199a2a28e9525c6bba3a64bda96af) 7ecd974 Set next version. db731da ssl/s3_[clnt|srvr].c: fix warning and linking error. 5864fd2 s3_cbc.c: make CBC_MAC_ROTATE_IN_PLACE universal. (cherry picked from commit f93a41877d8d7a287debb7c63d7b646abaaf269c) ff58eaa s3_cbc.c: get rid of expensive divisions [from master]. (cherry picked from commit e9baceab5a385e570706ca98dec768b2d89d1ac6) 76c61a5 ssl/s3_enc.c: remove artefact. 4ea7019 ssl/[d1|s3]_pkt.c: harmomize orig_len handling. (cherry picked from commit 8545f73b8919770a5d012fe7a82d6785b69baa27) 59b1129 Fix IV check and padding removal. fb092ef ssl/*: remove SSL3_RECORD-orig_len to restore binary compatibility. 6351ade Fix for EXP-RC2-CBC-MD5 -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0076 and OpenSSL 0.9.8
On Wed, Mar 26, 2014, Viktor Dukhovni wrote: On Tue, Mar 25, 2014 at 09:23:58PM +, geoff_l...@mcafee.com wrote: It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based distributions as well, correct? Isn't this an ECDSA issue? I thought that EC algorithms are by default disabled in OpenSSL 0.9.8 (require explicit ECCdraft in cipherlist to enable and do not appear in either DEFAULT or ALL). Certainly for TLS ECC ciphersuites are disabled by default in OpenSSL 0.9.8 though applications might use ECC for other purposes. Perhaps given the number of post-0.9.8y commits pending on the OpenSSL_0_9_8-stable branch, one final z release could be issued, no more commits made after that, and plans to not make any further releases announced? That sounds reasonable to me. Though it would be version 0.9.8za. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL-FIPS - incore and ia32
On 03/26/2014 12:30 PM, Mark Hatle wrote: Looking at the fips_canister.c I see that ia32 (32-bit and 64-bit) systems are not enabled with the cross compiling when using 'Linux'. But ia32 (32-bit) is enabled on Android systems. This is preventing me from cross compiling and using the fipsld with the incore script to link my applications. I modified fips_canister.c as shown in the attached patch. So far in my testing (building various applications and running them on the target system), the incore script is working correctly. Would it be possible to add this change to the fips_canister in a future version, or would this require a full re-validation of the openssl-fips? A change letter update would suffice. That's still a non-trivial expense, in both time and money, but not nearly as expensive as a full validation. Until then, my only other option is to use something like qemu to run the linked application to get the necessary checksum, in order to recompile/relink the final binary. Is modifying the fipsld script in such a way acceptable for FIPS compliance? You can't modify the fipsld present within the openssl-fips-2.0.N.tar.gz source distribution (*no* such modifications are allowed), but you can use *another* external modified fipsld script that respects the requirements of the Security Policy (i.e., verify the *.sha1 digests as you go). That point is a little confusing. When the FIPS module was first validated only native compilation was supported. Later we worked out how to support cross-compilation, and the precedent of using an external fipsld (and/or incore) utility for building the FIPS module has since been well established. Fipsld and incore (and some other files) are really part of the build environment, like the compiler and linker, and don't need to be in the source distribution tarball proper. If/when we ever do another open source based validation we'll probably leave those build utilities out of the FIPS module tarball entirely. Until then any change to the tarball contents means (at best) a change letter update, even something as trivial as a change to a comment. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0076 and OpenSSL 0.9.8
Dr. Stephen Henson steve at openssl.org writes: On Wed, Mar 26, 2014, Viktor Dukhovni wrote: Perhaps given the number of post-0.9.8y commits pending on the OpenSSL_0_9_8-stable branch, one final z release could be issued, no more commits made after that, and plans to not make any further releases announced? That sounds reasonable to me. Though it would be version 0.9.8za. Steve. It sounds like good news if 0.9.8 released one more update but would sound even better if it adopted my fix for its broken alert handling (see http://marc.info/?t=13676007772r=1w=2 for details). --mancha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL-FIPS - incore and ia32
On 3/26/14, 2:41 PM, Steve Marquess wrote: On 03/26/2014 12:30 PM, Mark Hatle wrote: Looking at the fips_canister.c I see that ia32 (32-bit and 64-bit) systems are not enabled with the cross compiling when using 'Linux'. But ia32 (32-bit) is enabled on Android systems. This is preventing me from cross compiling and using the fipsld with the incore script to link my applications. I modified fips_canister.c as shown in the attached patch. So far in my testing (building various applications and running them on the target system), the incore script is working correctly. Would it be possible to add this change to the fips_canister in a future version, or would this require a full re-validation of the openssl-fips? A change letter update would suffice. That's still a non-trivial expense, in both time and money, but not nearly as expensive as a full validation. Do you have an idea of the potential expense and time it would take to do this? We're certainly interested in getting this done in the community. I can ask my management to help pay for this change, but I need some idea as to a reasonable cost. (We don't want to do it ourselves, we want everything we do to come from the openssl.org.) Until then, my only other option is to use something like qemu to run the linked application to get the necessary checksum, in order to recompile/relink the final binary. Is modifying the fipsld script in such a way acceptable for FIPS compliance? You can't modify the fipsld present within the openssl-fips-2.0.N.tar.gz source distribution (*no* such modifications are allowed), but you can use *another* external modified fipsld script that respects the requirements of the Security Policy (i.e., verify the *.sha1 digests as you go). What I am doing right now: * build a target system (x86_64) that includes a compiler * boot that system * download (and verify) openssl-fips-2.0.5.tar.gz, openssl-1.0.1f.tar.gz * extract, build, install, openssl-fips (no modifications) using the rules from the UserGuide. * extract, build, install openssl (with appropriate system config) * (run test cases, verify it's all working) * copy the incore script as well * tar up the results of the build and transfer it back to the host On the host system (where we cross compile our apps) * extract the build, and install the components into their final location * modify the fipsld script to NOT call the 'fips_standalone_sha1' [since it's for the target, not host] * modify the fipsld script to call 'openssl sha1 -hmac ' from the host * [likely will have to add the qemu hooks here until the change is made] * build my app, using my custom fipsld script to do the link So -my- interpretation is that I didn't modify the openssl-fips sources, I modified the install location and fipsld script -after- it was built.. but I ensure that the steps performed are technically the same. So this is OK. Does this seem reasonable? That point is a little confusing. When the FIPS module was first validated only native compilation was supported. Later we worked out how to support cross-compilation, and the precedent of using an external fipsld (and/or incore) utility for building the FIPS module has since been well established. Fipsld and incore (and some other files) are really part of the build environment, like the compiler and linker, and don't need to be in the source distribution tarball proper. If/when we ever do another open source based validation we'll probably leave those build utilities out of the FIPS module tarball entirely. Until then any change to the tarball contents means (at best) a change letter update, even something as trivial as a change to a comment. That makes sense to me. Thanks for the help! --Mark -Steve M. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
