Hide Forgot
Created attachment 492018 [details] Patch that addresses this issue Description of problem: An ASN1_STRING function uses a variable that has not been initialised Version-Release number of selected component (if applicable): openssl-1.0.0-4.el6_0.2.x86_64 How reproducible: Run under valgrind a simple application that establishes an ssl connection Steps to Reproduce: 1. build attached c++ sample app (requires boost c++ libraries): g++ ssltest.cpp -o ssltest -lboost_system-mt -lssl 2. run under valgrind, (needs certificate authority of server in a file located in current dir at ca.pem) valgrind ./ssltest $ip $port Actual results: Conditional jump or move depends on uninitialised value(s) at 0x60A1B7C: ASN1_STRING_set (in /usr/lib64/libcrypto.so.1.0.0) by 0x608F73C: ASN1_mbstring_ncopy (in /usr/lib64/libcrypto.so.1.0.0) by 0x608F933: ASN1_mbstring_copy (in /usr/lib64/libcrypto.so.1.0.0) by 0x608FAE0: ASN1_STRING_to_UTF8 (in /usr/lib64/libcrypto.so.1.0.0) by 0x6091C5F: ??? (in /usr/lib64/libcrypto.so.1.0.0) by 0x60921B6: ??? (in /usr/lib64/libcrypto.so.1.0.0) by 0x6098782: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0) by 0x6099298: ??? (in /usr/lib64/libcrypto.so.1.0.0) by 0x609959B: ??? (in /usr/lib64/libcrypto.so.1.0.0) by 0x6098CC9: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0) by 0x6099298: ??? (in /usr/lib64/libcrypto.so.1.0.0) by 0x609959B: ??? (in /usr/lib64/libcrypto.so.1.0.0) Amongst other errors if openssl was not built with -DPURIFY, and some leaks due to the ASIO ssl implementation Expected results: With openssl built with -DPURIFY option, and attached patch, no use of uninitialised variables, although ASIO issues remain. Additional info: The offending line is: openssl-1.0.0/crypto/asn1/asn1_lib.c:382 (ASN1_STRING_set) The object at the root of the problem is a stack based instance of ASN1_STRING at: openssl-1.0.0/crypto/asn1/a_strex.c:554 (ASN1_STRING_to_UTF8) In my patch, I fix the issue by initialising the length field of the stack based object in ASN1_STRING_to_UTF8, immediately after the existing initialisation of the corresponding data field.
Created attachment 492019 [details] Small ssl test program
This issue is a pure code cleanness problem. If you look at the condition where the uninitialized memory is read you can see that as the str->data is initialized to NULL. The condition always succeeds in this case regardless of the contents of the uninitialized str->length.
Nevertheless it would be a good idea to report the problem upstream into their bug tracker rt
This bug has already been raised upstream: http://rt.openssl.org/Ticket/Display.html?id=2400&user=guest&pass=guest I'll keep our patch for our own use until an update obsoletes it. Of course, please feel free to use the patch as you like.