Re: SSL Renogotation failure
Thanks for the reply. I am currently resetting the below flag by resetting using SSL_CTX_clear_options(). Still the handshake fails. SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION Any inputs ? On Wed, Jun 4, 2014 at 6:57 PM, Salz, Rich rs...@akamai.com wrote: Ø Can you please elaborate? Ø One side of your connection, and it could be either the client or the server, is doing the old-style (OpenSSL calls it LEGACY) renegotiation and the other side is rejecting it. One use for renegotiation is to get a client cert, for example. For information about that, google: https://www.google.com/search?q=tls+insecure+renegotiation or perhaps just ‘feeling lucky’ and go here: http://www.digicert.com/news/2011-06-03-ssl-renego.htm -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: SSL Renogotation failure
You must ensure that the option is set, not cleared. -Kyle H On Wed, Jun 4, 2014 at 11:37 PM, Mithun Kumar mithunsi...@gmail.com wrote: Thanks for the reply. I am currently resetting the below flag by resetting using SSL_CTX_clear_options(). Still the handshake fails. SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION Any inputs ? On Wed, Jun 4, 2014 at 6:57 PM, Salz, Rich rs...@akamai.com wrote: Ø Can you please elaborate? Ø One side of your connection, and it could be either the client or the server, is doing the old-style (OpenSSL calls it LEGACY) renegotiation and the other side is rejecting it. One use for renegotiation is to get a client cert, for example. For information about that, google: https://www.google.com/search?q=tls+insecure+renegotiation or perhaps just ‘feeling lucky’ and go here: http://www.digicert.com/news/2011-06-03-ssl-renego.htm -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
SSL_Connect() invalid write
Hi, I'm getting the following error when using SSL_Connect on a non-blocking socket. I've included some debug output that shows POLLOUT was set after the socket successfully connected. SSL_Connect then returns SSL_ERROR_WANT_READ, so the program waits for a POLLIN to be set at which point it calls SSL_Connect again and then the error occurs. It would appear OpenSSL is writing past the 100 Bytes allocated for work with an HMAC: _thread: POLLOUT (src/thread.c, line 1005) _sock_connected: attempting ssl connect... (src/sock.c, line 603) _sock_connected: SSL_ERROR_WANT_READ (src/sock.c, line 619) _thread: POLLIN (src/thread.c, line 375) _sock_connected: attempting ssl connect... (src/sock.c, line 603) ==21614== Thread 14: ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F879: HMAC_Final (hmac.c:174) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F8E2: HMAC_Final (hmac.c:180) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== Here's the openssl version I'm running: OpenSSL 1.0.1e 11 Feb 2013 built on: Mon May 12 20:22:52 UTC 2014 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: /usr/lib/ssl Thanks for your help, Brandon __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Wed, Jun 4, 2014 at 4:49 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: Sounds like the requested feature is already implemented. That's some fast work. :-) Indeed, it is some fast work. That's all that about the itching feature, low priority, and many years... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
Hi Steve, That is exactly what I needed. I've just tried it out with OpenSSL-1.0.2-beta1 and it works perfectly. Do you have any ETA on when the 1.0.2 will be released? Thank you! On Wed, Jun 4, 2014 at 4:29 PM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jun 04, 2014, DEXTER wrote: Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. That's the problem. I'm asking kindly the devs of openssl to make this feature exist. Now that Openssl has two full time developers, is there an official way to request such a feature? (The request is about supporting a way for mitm proxies to be able to get the servername from the client, suspend the handshake with it, and continue later when you have the proper certificate.) I'm not sure if this will do precisely what you want but OpenSSL 1.0.2+ supports certificate callbacks for both client and server certificates. In the server case the callback is called when the server certificate is required. It has a feature where the callback can return -1 and this then sets a special state SSL_ERROR_WANT_X509_LOOKUP and you can retry in the same way as other SSL_ERROR_WANT_* conditions. See: http://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Jüri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Gröbert and Ivan FratriÄ at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux)
How to decrypt smime.p7m file in DER format using OpenSSL in C code.
Hi All, I am trying to decrypt emails using openssl. I am getting smime.p7m file from the server. But it is in DER format. I can decrypt this file using command prompt, with the command openssl smime -decrypt -in openssl_working_smime.p7m -inform DER -inkey mycert.pem dec_mail.eml But now I want to do this using C code. Right now I am trying to do using - SMIME_read_PKCS7() But this returns null with SMIME_read_ASN1:no content type:asn_mime.c:451: error Any ideas how to do it?
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG
RE: SSL Renogotation failure
It must therefore be that the *other side* is trying to do unsafe renegotiation. Someone posted a note about PostGres issues, IIRC. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz
Re: How to decrypt smime.p7m file in DER format using OpenSSL in C code.
Hi, To load a DER-encoded PKCS7 structure from the file you have to use d2i_PKCS7_bio() function. 2014-06-05 15:51 GMT+04:00 Yash Dosi yashd...@gmail.com: Hi All, I am trying to decrypt emails using openssl. I am getting smime.p7m file from the server. But it is in DER format. I can decrypt this file using command prompt, with the command openssl smime -decrypt -in openssl_working_smime.p7m -inform DER -inkey mycert.pem dec_mail.eml But now I want to do this using C code. Right now I am trying to do using - SMIME_read_PKCS7() But this returns null with SMIME_read_ASN1:no content type:asn_mime.c:451: error Any ideas how to do it?
Conflicting information regarding non-blocking sockets
Hello, I have implemented an SSL server on the ecos platform and it seems to be working well however I am a tiny bit unclear about the requirements around whether or not calls to SSL_read and SSL_write need to be syncrhonized and I want to avoid doing something incorrect. The specific question I have is this: If I call SSL_read() and openSSL tells me that it NEEDS_WRITE or NEEDS_READ, do I need to then hold off calls to SSL_write until I have called SSL_read again and it is succeeds? And then same question but with SSL_write. I am asking because I have seen conflicting information. Here is where I'm getting the conflicting information: From the calls must be synchronized camp: In chapter 5, pages 159-166 of Network Security with OpenSSL by John Viega, Matt Messier Pravir Chandra, 2002 they state very clearly that once we've made a call to an SSL I/O function, and it requires a retry, we should not call other I/O functions until the original call has succeeded. It even gives a code example that achieves this synchronization. From the calls to SSL_read and SSL_write can be treated independently camp: In this thread from the openssl-dev mailing list: http://marc.info/?l=openssl-devm=124308191325560w=2 A gentleman named David Schwartz states, I'm not sure where you see that, but that is obviously bogus. Suppose we have a protocol that permits either side to read or write at any time. We call SSL_read in case the other side sent something, it returns WANT_READ, because the other side didn't send anything. Are you seriously arguing that we now can't send anything until the other side does? Isn't that obviously an impossible requirement? In response to this statement by somebody else Because the documentation appears in several places to state that when I receive WANT_X from _any_ OpenSSL API operation in non-blocking mode, the next API operation I issue on that SSL * must be the exact same API operation, with the same parameters. Can somebody please tell me which of these two sources are correct or if I am mis-reading them? Thanks! CHAD __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_Connect() invalid write
Please ignore. Turned out another library I was linking against had a function called MD5_Final and the linker was using this one instead of OpenSSL's. On 6/4/2014 4:12 PM, Brandon W Yuille wrote: Hi, I'm getting the following error when using SSL_Connect on a non-blocking socket. I've included some debug output that shows POLLOUT was set after the socket successfully connected. SSL_Connect then returns SSL_ERROR_WANT_READ, so the program waits for a POLLIN to be set at which point it calls SSL_Connect again and then the error occurs. It would appear OpenSSL is writing past the 100 Bytes allocated for work with an HMAC: _thread: POLLOUT (src/thread.c, line 1005) _sock_connected: attempting ssl connect... (src/sock.c, line 603) _sock_connected: SSL_ERROR_WANT_READ (src/sock.c, line 619) _thread: POLLIN (src/thread.c, line 375) _sock_connected: attempting ssl connect... (src/sock.c, line 603) ==21614== Thread 14: ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F879: HMAC_Final (hmac.c:174) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F8E2: HMAC_Final (hmac.c:180) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== Here's the openssl version I'm running: OpenSSL 1.0.1e 11 Feb 2013 built on: Mon May 12 20:22:52 UTC 2014 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: /usr/lib/ssl Thanks for your help, Brandon __ OpenSSL Project http://www.openssl.org User Support Mailing List
Re: Windows CE (VC-CE) Compilation problem !
hello karan, i am built wcecompat but when i try to compile openssl i can not compiled it. so can you gave me the steps for compiling openssl. and if you don't mind then gave me the step to compile wcecompat as well so i check my compiled libs have any problem or not. so please help me out because i am stuck in for several days. -- View this message in context: http://openssl.6102.n7.nabble.com/Windows-CE-VC-CE-Compilation-problem-tp45909p50599.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
In 0.9.8za at least, there is a missing directive to include limits.h. Without it, compilation fails on SPARC Solaris 10 with INT_MAXbeing undefined on line 536, which looks like: OPENSSL_assert(s-s3-wnum INT_MAX); It appears that 1.0.0m has the same problem. I haven't looked at 1.0.1h as yet. OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval
Re: OpenSSL Security Advisory
Hi Steve, That’s quite a few in one go - is this due to greater testing of OpenSSL and more scrutiny of the code by the community? Of the flaws listed, which is the one of most concern? This kind of begs the question what to do with all those embedded systems that run older versions of OpenSSL. Thanks — Juha On 5/06/2014, at 11:54 pm, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za
DTLS path MTU issues
I am developing an application similar to a VPN which uses OpenSSL for DTLS and am trying to sort out path MTU discovery. The first issue I am having is that the man pages for SSL_write and SSL_read provide the following warning: When an SSL_write() [or SSL_read()] operation has to be repeated because of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments. I would expect the reason for this is that the operation may have been partially completed but can't be fully completed until the socket is ready for read or write. So this should not apply to DTLS because it should only be sending complete datagrams, is that correct? Otherwise there seems to be a rather serious problem with UDP sockets that set the don't fragment bit: A call to SSL_write() may return WANT_READ or WANT_WRITE (e.g. because of a renegotiation), and then when the renegotiation completes and SSL_write() is called again the data could be too big for the MTU and the OS could return EMSGSIZE. Any subsequent call with the same arguments would then have the same result so calling SSL_write with those arguments will never succeed, but calling with different arguments is prohibited by the documentation. And clearing the don't fragment bit is no solution because DF may be required, e.g. because the payload itself is a IP packet with DF set, or the peer device can't reassemble large datagrams, or the firewall is known to drop fragmented packets. So is it safe to assume that the warning applies only to TLS and not DTLS? The second issue is that I'm trying to figure out how to determine the DTLS protocol overhead in order to calculate the path MTU of the connection. I can determine the path MTU of the underlying transport and only need to add to it the DTLS overhead. The trouble is that this depends on the ciphersuite negotiated because that determines the size of the HMAC, whether the data must be padded to a block boundary, etc. So I need some way to get OpenSSL to tell me this information, but I don't see anything like “int SSL_get_dtls_overhead(SSL* ssl)” unless I'm missing it somewhere. The ideal would be something like “int SSL_get_connection_mtu(SSL* ssl, int transport_mtu)” which would provide the MTU of the TLS connection given the MTU of the socket, that way OpenSSL could provide the exact number instead of assuming the worst-case amount of block padding. How do I get this information out of OpenSSL?
CVE-2014-0224
CVE-2014-0224 looks like an interesting issue (https://www.openssl.org/news/secadv_20140605.txt): An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. Can anyone explain the vulnerability? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CVE-2014-0224
Can anyone explain the vulnerability? A handful of links Here's the timeline, a public document: https://plus.google.com/u/0/+MarkJCox/posts/L8i6PSsKJKs And this blog entry from the guy who found the bug. BTW, it's 16 years old. http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html Adam Langley's writeup full of technical and protocol details https://www.imperialviolet.org/2014/06/05/earlyccs.html -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
CVE-2014-0195
CVE-2014-0195 is a buffer overflow (https://www.openssl.org/news/secadv_20140605.txt): A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. I'm fairly certain that most (all?) Linux distros use stack guards by default (via GCC spec file) and OpenSSL uses NX stacks. Does that mean this RCE is a heap based overflow? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0224
I am also quite curious. Also, how long has this exploit been around, and could hackers have exploited this already? 2014-06-05 22:46 GMT+02:00 Jeffrey Walton noloa...@gmail.com: CVE-2014-0224 looks like an interesting issue (https://www.openssl.org/news/secadv_20140605.txt): An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. Can anyone explain the vulnerability? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Security Advisory
Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to be missing the symbol BN_consttime_swap. Woody Gatewood C Green Jr (Woody) Principal Software Engineer, Product Security Champion SIEM Engineering McAfee. Part of Intel Security. Direct: 208.552.8269 Mobile: 208.206.7455 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of OpenSSL Sent: Thursday, June 05, 2014 5:54 AM To: openssl-...@openssl.org; openssl-users@openssl.org; openssl-annou...@openssl.org Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix
Re: CVE-2014-0224
On Thu, Jun 5, 2014 at 4:49 PM, Salz, Rich rs...@akamai.com wrote: Can anyone explain the vulnerability? A handful of links Here's the timeline, a public document: https://plus.google.com/u/0/+MarkJCox/posts/L8i6PSsKJKs And this blog entry from the guy who found the bug. BTW, it's 16 years old. http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html Adam Langley's writeup full of technical and protocol details https://www.imperialviolet.org/2014/06/05/earlyccs.html Thanks Rich. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: CVE-2014-0195
Does that mean this RCE is a heap based overflow? I/O buffers in openssl are generally (always?) from the heap, not on the stack. So yes in general, and yes in this specific case. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: CVE-2014-0224
I've also added these into the wiki at http://wiki.openssl.org/index.php/SECADV_20140605 - so that others looking back through the issues can find a handy reference to the additional information from various locations - the link at http://wiki.openssl.org/index.php/Security_Advisories basically notes when there is additional information available beyond the advisory details for a given issue. If there are other useful references to this item or to other items in the security vulnerability announcement then updating the wiki to note them there would be helpful. Thanks, Tim. On 6/06/2014 9:42 AM, Jeffrey Walton wrote: On Thu, Jun 5, 2014 at 4:49 PM, Salz, Rich rs...@akamai.com wrote: Can anyone explain the vulnerability? A handful of links Here's the timeline, a public document: https://plus.google.com/u/0/+MarkJCox/posts/L8i6PSsKJKs And this blog entry from the guy who found the bug. BTW, it's 16 years old. http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html Adam Langley's writeup full of technical and protocol details https://www.imperialviolet.org/2014/06/05/earlyccs.html Thanks Rich. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES-GCM
Thanks for the info! I looked at the demos programs in the given link http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=demos/evp/aesgcm.c;h=324d8a55b1481c507c7754fa7f33c30a02bdb737;hb=HEAD . I have a question in encrypt: ... /* Finalise: note get no output for GCM */ 63 http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=demos/evp/aesgcm.c;h=324d8a55b1481c507c7754fa7f33c30a02bdb737;hb=HEAD#l63 EVP_EncryptFinal_ex(ctx, outbuf, outlen); ... What does this mean? That we shouldn't expect any output from this call and/or that we should ignore it? Thanks! On Tue, May 27, 2014 at 12:33 AM, Jens Hiller jens.hiller.c...@hotmail.de wrote: On 05/27/2014 09:00 AM, Anant Rao wrote: Hi, I have ciphertext encrypted in Java (using BouncyCastle - BC) with AES/GCM/NoPadding cipher. When I tried to decrypt it using OpenSSL in a 'c' program, the last call 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not printing anything either. I do have the IV that is used in the Java's encrypt. However, I don't know where BC stores the tag in the ciphertext. I tried it at the beginning and the end of the ciphertext, but it didn't help. That is, I tried both of the following in the decrypt: |IV|TAG|Ciphertext |IV|Ciphertext|TAG Both didn't work. I tried both of the following as well with the same failure: EVP_aes_256_gcm EVP_aes_128_gcm I have run out of ideas what else to try. Any help would be greatly appreciated. Thanks in advance! Have a look at https://www.openssl.org/docs/crypto/EVP_EncryptInit.html#GCM_Mode and at the example in 'openssl/demos/evp/aesgcm.c' of the current master branch (git://git.openssl.org/openssl.git). Regards Jens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- *Anant* *Rao* Server Lead D / a...@noknok.com *Nok Nok Labs Inc.* 4151 Middlefield Road, Suite 200 Palo Alto, CA 94303 T +1 650 433 1300 i...@noknok.com *www.noknok.com* http://www.noknok.com http://www.linkedin.com/company/nok-nok-labs http://www.twitter.com/noknoklabs https://plus.google.com/108217184383559859585 http://www.facebook.com/NokNokLabs
Re: AES-GCM
On Tue, May 27, 2014 at 3:00 AM, Anant Rao a...@noknok.com wrote: Hi, I have ciphertext encrypted in Java (using BouncyCastle - BC) with AES/GCM/NoPadding cipher. When I tried to decrypt it using OpenSSL in a 'c' program, the last call 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not printing anything either. ... I don't know about Bouncy Castle, but I believe Matt Caswell provided an example of AES/GCM on the OpenSSL wiki at http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
