Find this: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=987158 http://openssl.6102.n7.nabble.com/AES-cbc-encrypt-amp-aesni-cbc-encrypt-length-parameter-td52370.html http://www.hardening-consulting.com/en/posts/20140512openssl-and-valgrind.html
2014-11-22 15:09 GMT+03:00 Вячеслав Бадалян <[email protected]>: > We fix all leaks in asteris and libsrtp.... many calls have one leak path > > ==44910== Use of uninitialised value of size 8 > ==44910== at 0x4A08DEF: memcpy (mc_replace_strmem.c:882) > ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) > ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) > ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) > ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) > ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) > ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) > ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) > ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) > ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) > ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) > ==44910== by 0x38E42222FC: ssl3_accept (s3_srvr.c:357) > ==44910== Uninitialised value was created by a stack allocation > ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni-x86_64.s:2149) > > ==44910== Conditional jump or move depends on uninitialised value(s) > ==44910== at 0x4A08DF1: memcpy (mc_replace_strmem.c:882) > ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) > ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) > ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) > ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) > ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) > ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) > ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) > ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) > ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) > ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) > ==44910== by 0x38E42222FC: ssl3_accept (s3_srvr.c:357) > ==44910== Uninitialised value was created by a stack allocation > ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni-x86_64.s:2149) > > > > 2014-11-13 2:58 GMT+03:00 Matt Caswell via RT <[email protected]>: > >> On Thu Nov 06 10:38:23 2014, [email protected] wrote: >> > HI all >> > >> > CentOS x86_64 release 6.6 (Final) >> > >> > OpenSSL> version >> > OpenSSL 1.0.1e-fips 11 Feb 2013 >> > >> > # rpm -qa | grep openssl >> > openssl-devel-1.0.1e-30.el6_6.2.x86_64 >> > openssl-debuginfo-1.0.1e-30.el6_6.2.x86_64 >> > openssl-1.0.1e-30.el6_6.2.x86_64 >> > >> > >> > Please look to >> > https://issues.asterisk.org/jira/browse/ASTERISK-24472 >> > >> > Again bug in DTLS in OpenSSL? >> >> Hmmm...tricky. >> >> The crashes you are seeing appear to occur in a number of different places >> rather than the same place everytime. This might suggest some kind of >> memory >> issues?? The valgrind output is showing some significant problems...some >> of >> which seem to be in OpenSSL and some of which seem to be in your >> application. >> You should focus on trying to resolve those. The OpenSSL issues seem to be >> largely (but not exclusively) occuring in the handling of session >> tickets. I've >> run some tests locally with session tickets using valgrind and >> s_server/s_client, and valgrind is not reporting any problems. >> >> Is it possible for you to use standard OpenSSL rather than rpms for >> further >> testing? Ideally you should use the latest standard 1.0.1 version, as >> there >> have been a number of DTLS related issues that have been fixed in recent >> months. Also can you rerun the valgrind tests having ensured that you >> configure >> OpenSSL with -DPURIFY. Without that defined you will get false positives >> reported from valgrind. The version that you are using is also quite >> difficult >> to track against the source because it (probably) has some distro specific >> patches so line numbers are not matching up. It would also be useful to >> run >> valgrind with --track-origins=yes >> >> Matt >> >> > > > -- > С уважением, > Бадалян Вячеслав Борисович > > ООО "Открытые бизнес-решения" > Технический директор > +7 (495) 666-0-111 > http://www.open-bs.ru > -- С уважением, Бадалян Вячеслав Борисович ООО "Открытые бизнес-решения" Технический директор +7 (495) 666-0-111 http://www.open-bs.ru ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
