[openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
Hi,
in my process, I expecienced too many SSL_accept() crashed when processing
SSLv3 client request.
(gdb) info stack
#0 0xb76e3f7a in SSL_accept () from /lib/libssl.so.1.0.0
#1 0x in ?? ()
#2 0xb76e3f56 in SSL_accept () from /lib/libssl.so.1.0.0
#3 0xbfc2ff23 in ?? ()
#4 0x08049d57 in do_ssl_accept (client_cb=0x9f79790) at rhttpd.cc:823
$12 = {version = 768, type = 8192, method = 0x0, rbio = 0x9f799e0, wbio =
0x9f799e0, bbio = 0x0, rwstate = 1, in_handshake = 0, handshake_func =
0xb76d5d00 ssl23_accept, server = 1, new_session = 0, quiet_shutdown = 0,
shutdown = 0, state = 8720, rstate = 240,
init_buf = 0x9f79a28, init_msg = 0x0, init_num = 0, init_off = 0, packet =
0x9fa3e30 \026\003, packet_length = 11, s2 = 0x0, s3 = 0x9f9e4a8, d1 = 0x0,
read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0, param =
0x9f78288, cipher_list = 0x0,
cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx = 0x0, read_hash = 0x0,
expand = 0x0, enc_write_ctx = 0x0, write_hash = 0x0, compress = 0x0, cert =
0x9f79948, sid_ctx_length = 0, sid_ctx = '\0' repeats 31 times, session =
0x0, generate_session_id = 0,
verify_mode = 0, verify_callback = 0, info_callback = 0, error = 0,
error_code = 0, psk_client_callback = 0, psk_server_callback = 0, ctx =
0x9f77e60, debug = 0, verify_result = 0, ex_data = {sk = 0x0, dummy = 0},
client_CA = 0x0, references = 1,
options = 2147486719, mode = 0, max_cert_list = 102400, first_packet = 0,
client_version = 771, max_send_fragment = 16384, tlsext_debug_cb = 0,
tlsext_debug_arg = 0x0, tlsext_hostname = 0x0, servername_done = 0,
tlsext_status_type = -1, tlsext_status_expected = 0,
tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0, tlsext_ocsp_resp = 0x0,
tlsext_ocsp_resplen = -1, tlsext_ticket_expected = 0,
tlsext_ecpointformatlist_length = 0, tlsext_ecpointformatlist = 0x0,
tlsext_ellipticcurvelist_length = 0, tlsext_ellipticcurvelist = 0x0,
tlsext_opaque_prf_input = 0x0, tlsext_opaque_prf_input_len = 0,
tlsext_session_ticket = 0x0, tls_session_ticket_ext_cb = 0,
tls_session_ticket_ext_cb_arg = 0x0, tls_session_secret_cb = 0,
tls_session_secret_cb_arg = 0x0, initial_ctx = 0x9f77e60,
next_proto_negotiated = 0x0, next_proto_negotiated_len = 0 '\0',
srtp_profiles = 0x0, srtp_profile = 0x0, tlsext_heartbeat = 0,
tlsext_hb_pending = 0, tlsext_hb_seq = 153, renegotiate = 167221624, srp_ctx =
{SRP_cb_arg = 0x0, TLS_ext_srp_username_callback = 0,
SRP_verify_param_callback = 0, SRP_give_srp_client_pwd_callback = 0, login
= 0x0, N = 0x0, g = 0x0, s = 0x0, B = 0x0, A = 0x0, a = 0x0, b = 0x9f786d0, v =
0x9f7b2f8, info = 0xb76b52e8 @, strength = 0, srp_Mask = 0}}
Somehow the method became 0x0 when processing SSLv3. for now all crashes
occured with SSLv3 client requests. We have to disable SSLv2 and SSLv3 support
in the process.
Could anyone help check what happened to make the method become 0x0 when
processing SSLv3?
Thanks,
Murphy.zhao
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
The first place to look is to see if your program has any pointers errors that are overwriting memory. Try something like valgrind or ASAN. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
On Fri Jul 24 07:18:37 2015, murphy.z...@qq.com wrote: Somehow the method became 0x0 when processing SSLv3. for now all crashes occured with SSLv3 client requests. We have to disable SSLv2 and SSLv3 support in the process. Could anyone help check what happened to make the method become 0x0 when processing SSLv3? What openssl version/platform are you using? Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method
On Thu, Jul 23, 2015 at 11:09:40PM +, Viktor Dukhovni wrote: Any chance you have a standalone test program that works with TLSv1_client_method(), but not with SSLv23_client_method() (and SSLv2 disabled). Such code if added to make test might ensure the problem does not come back after is is fixed. What would be excellent is a program that is both the client and the server (talking to itself over a socketpair perhaps, though that might not be portable to Windows, but perhaps it suffices for the test to run on Unix-like systems...). While I do have a fully automated test setup (http://buildbot.w1.fi/hwsim/) that runs on a single server and can be used with OpenSSL 0.9.8 through 1.0.2, it would be quite a stretch to claim that to be standalone in this context.. :-) I do have an example program that comes much closer, though. eap_example in hostap.git is a single process that runs EAP server and peer and runs through one authentication round. By default, it is not built with OpenSSL or for EAP-FAST, but it is straightforward to modify that to do so. Here's a step-by-step example of running this test: git clone git://w1.fi/hostap.git cd hostap/ wget http://w1.fi/p/eap-example-openssl-eap-fast.patch patch -p1 eap-example-openssl-eap-fast.patch cd eap_example/ make ./eap_example run1 ls -l eap-fast.pac ./eap_example run2 grep SessionTicket run2 The eap-example-openssl-eap-fast.patch comments out the EAP-FAST workaround where I force TLSv1_method() to be used. In other words, with this patch, SSLv23_method() is used instead. The workaround can be re-enabled by reverting the change in src/crypto/tls_openssl.c (#if 0 -- #if 1). The first execution of eap_example goes through the EAP-FAST provisioning step. This works with SSLv23_method() since no SessionTicket is used here. As a result of that provisioning round, eap-fast.pac file is created with the information that the peer can use to establishing connections afterwards. On the second run (and all following runs with the PAC file present for that matter), we'll hit the issue with SSLv23_method(). That grep for SessionTicket in run2 shows this type of output in the failed case: OpenSSL: ClientHello SessionTicket extension - hexdump(len=0): EAP-FAST: SessionTicket callback EAP-FAST: SessionTicket (PAC-Opaque) - hexdump(len=0): EAP-FAST: Ignore invalid SessionTicket EAP-FAST: SessionTicket callback EAP-FAST: SessionTicket - hexdump(len=0): [NULL] OpenSSL: ClientHello SessionTicket extension - hexdump(len=0): While the workaround with TLSv1_method() shows this: OpenSSL: ClientHello SessionTicket extension - hexdump(len=60): 00 02 00 38 93 ac a7 0f 32 75 a3 88 dc b1 e4 b0 83 84 04 bd 63 ed 55 a5 37 0d 69 c9 05 a2 b4 1c f0 43 b4 d5 9b e2 2c 67 74 cf c9 3d bc 82 56 97 79 1d 03 59 5e 86 d3 e3 bd d7 a4 ca EAP-FAST: SessionTicket callback EAP-FAST: SessionTicket (PAC-Opaque) - hexdump(len=60): 00 02 00 38 93 ac a7 0f 32 75 a3 88 dc b1 e4 b0 83 84 04 bd 63 ed 55 a5 37 0d 69 c9 05 a2 b4 1c f0 43 b4 d5 9b e2 2c 67 74 cf c9 3d bc 82 56 97 79 1d 03 59 5e 86 d3 e3 bd d7 a4 ca EAP-FAST: SessionTicket callback EAP-FAST: SessionTicket - hexdump(len=0): [NULL] This may still be quite a bit too much for OpenSSL make test purposes, i.e., something without the full EAP-FAST implementation is likely to be sufficient there. I don't have such an example available, though. Anyway, I hope this eap_example code is useful for anyone who might be able to make SSLv23_method() case in OpenSSL support this use case. I'm trying to run the full hostapd/wpa_supplicant test suite with all OpenSSL releases, so I should at least notice regressions in the relevant areas pretty quickly. In theory, I could also do this on snapshot builds (or repository snapshots in general). -- Jouni MalinenPGP id EFC895FA ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3955] [PATCH] Reduce stack usage in PKCS7_verify()
On Thu, 2015-07-23 at 20:33 +, Salz, Rich via RT wrote:
How about 256 on the stack?
Sure.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 57aa658b429b1962e2811c30e2b77edb85d134d3 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 24 Jul 2015 10:15:04 +0100
Subject: [PATCH] RT3955: Reduce stack usage in PKCS7_verify() and
PKCS7_decrypt()
Some environments, such as 32-bit UEFI, have strict limits on stack size.
Using a 4KiB buffer on the stack for reading from the bio is somewhat
excessive, so reduce it to 256 bytes. This might incur a slight performance
penalty but it should be negligible.
---
crypto/pkcs7/pk7_smime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/pkcs7/pk7_smime.c b/crypto/pkcs7/pk7_smime.c
index e52e746..c3afc96 100644
--- a/crypto/pkcs7/pk7_smime.c
+++ b/crypto/pkcs7/pk7_smime.c
@@ -253,7 +253,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
PKCS7_SIGNER_INFO *si;
X509_STORE_CTX cert_ctx;
-char buf[4096];
+char buf[256];
int i, j = 0, k, ret = 0;
BIO *p7bio;
BIO *tmpin, *tmpout;
@@ -519,7 +519,7 @@ int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags)
{
BIO *tmpmem;
int ret, i;
-char buf[4096];
+char buf[256];
if (!p7) {
PKCS7err(PKCS7_F_PKCS7_DECRYPT, PKCS7_R_INVALID_NULL_POINTER);
--
2.4.3
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3955] [PATCH] Reduce stack usage in PKCS7_verify()
On Thu, 2015-07-23 at 20:33 +, Salz, Rich via RT wrote:
How about 256 on the stack?
Sure.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 57aa658b429b1962e2811c30e2b77edb85d134d3 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 24 Jul 2015 10:15:04 +0100
Subject: [PATCH] RT3955: Reduce stack usage in PKCS7_verify() and
PKCS7_decrypt()
Some environments, such as 32-bit UEFI, have strict limits on stack size.
Using a 4KiB buffer on the stack for reading from the bio is somewhat
excessive, so reduce it to 256 bytes. This might incur a slight performance
penalty but it should be negligible.
---
crypto/pkcs7/pk7_smime.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/pkcs7/pk7_smime.c b/crypto/pkcs7/pk7_smime.c
index e52e746..c3afc96 100644
--- a/crypto/pkcs7/pk7_smime.c
+++ b/crypto/pkcs7/pk7_smime.c
@@ -253,7 +253,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
PKCS7_SIGNER_INFO *si;
X509_STORE_CTX cert_ctx;
-char buf[4096];
+char buf[256];
int i, j = 0, k, ret = 0;
BIO *p7bio;
BIO *tmpin, *tmpout;
@@ -519,7 +519,7 @@ int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags)
{
BIO *tmpmem;
int ret, i;
-char buf[4096];
+char buf[256];
if (!p7) {
PKCS7err(PKCS7_F_PKCS7_DECRYPT, PKCS7_R_INVALID_NULL_POINTER);
--
2.4.3
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
What openssl version/platform are you using? $ openssl version OpenSSL 1.0.1j 15 Oct 2014 Embedded environment based on x86 Regards, Murphy.zhao ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
This transaction appears to have no content binYAdydlKAnq.bin Description: Binary data bin67zpiQwKdm.bin Description: Binary data ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
On Fri, Jul 24, 2015 at 10:25:04AM +, ice via RT wrote: What openssl version/platform are you using? $ openssl version OpenSSL 1.0.1j 15 Oct 2014 You seem to be affected by CVE-2014-3569 that only affects the 1.0.1j version. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing
On Fri, Jul 24, 2015 at 10:25:04AM +, ice via RT wrote: What openssl version/platform are you using? $ openssl version OpenSSL 1.0.1j 15 Oct 2014 You seem to be affected by CVE-2014-3569 that only affects the 1.0.1j version. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Self-initialization of locking/threadid callbacks and auto-detection of features
On 06/15/2015 06:02 PM, Nico Williams wrote: On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote: Detecting things in libcrypto is very difficult on GNU/Linux due to the way dynamic linking works. Details? Detection based on weak symbols can break due to linking order (if the main executable is not linked against libpthread). Merely linking against libpthread, without ever creating any threads, is also not an indicator of thread usage (libcrypto, for instance, currently does this unconditionally). Perhaps OpenSSL should have several configuration flavors for Linux then. If you want to statically link a non-threaded program with OpenSSL, then you should use the libpthread static link meant for it. I have not considered the static linking case at all, to be honest. It should be used only very rarely. If the lack of stubs is a problem for static linking, glibc could be enhanced to provide them in a separate archive. A workaound for libraries may be to use a private copy (as if by static linking) of OpenSSL with distinct SONAME/symbols and initialize that copy properly. This is generally safe (we've tried it) but also a bit troublesome. On the plus side this means that ABI incompatibilities betwee OpenSSL releases become a non-issue. We can't do that because too much would need to be recompiled and relinked for updates. Or indeed, libpthread should move into libc (which I gather would take a long time and is beyond what we can do here). See my offer to add more stubs as needed. (Moving the implementation of a library to another requires support for shared object filters, at least on Solaris, so that dynamically-linked dependents of libpthread and such will find the symbols they need there, though the RTLD knows to go look in the object they moved to. We say that libpthread is a filter of libc because only the pthread-related symbols of libc appear in libpthread. IIUC the Linux RTLD does not support filters.) If I understand you correctly, we emulate them with IFUNCs in glibc. There is no additional indirection at run time, calls go directly through the libc implementation even if it is called through the libpthread symbol. Linking -lpthread has a real performance hit for unthreaded applications, so core libraries should avoid it. It shouldn't. We can get rid of the performance overhead for single-threaded case, but it's a multi-year effort, and we haven't even started. What you as a library author can do: do not link against libpthread. Most functionality you might need is available from libc proper, and where it is not, ask for advice on the libc-help list. In any case, the initialization problems when OpenSSL is used by *libraries* are simply unacceptable. Right. -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] compile error
And I use both gcc and clang with command “cc -g -Wall -I../../include -lcrypto aesgcm.c to compile the source code. Long version: Note that the linker processes its libraries from left to right, e.g. if you have an object file object.o and to libraries liba.a and libb.a, then cc object.o -la -lb will first collect all unresolved symbols in the object files, then it will resolve whatever it can resolve with the files in liba.a, possibly adding new unresolved symbols and finally it will try to resolve the remaining symbols with libb.a. If you do cc object.o -lb -la, it will again start with the symbols from object.o, resolve what it can against libb.a, then resolve the reamaining stuff against liba.a and if it adds any symbol from liba.a that needs something from libb.a you get an error. If you do cc -lb -la object.o, it will start with no symbols, add whatever it needs to resolve the symbols from libb.a (i.e. nothing), then adds whatever it needs from liba.a (i.e. nothing), then add object.o and complain about everything that remains unresolved. In short: try cc ... aesgcm.c -lcrypto, that should work. Regards, Stefan___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 0.9.8 support after 31 Dec 2015
On 07/21/2015 01:16 PM, Brad House wrote: I'm sure you're not the only one that will be needing to support 0.9.8 after the official EOL. RedHat Enterprise Linux 5 comes to mind (supported until 3/2017), so there will definitely be others providing security related patches. On the other hand, Red Hat will only backport critical security fixes to Red Hant Enterprise Linux 5 because it is in Production Phase 3. This is considerably narrower than what is currently provided by OpenSSL upstream 0.9.8. (The main problem people have with 0.9.8 right now is lack of TLS 1.1/1.2 support, and fixing that while preserving binary compatibility with 0.9.8 is quite a challenge.) -- Florian Weimer / Red Hat Product Security ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
