Hi Daniel,
Thank you for your response.
From what I see, RAND_load_file might be called via:
https_connecting=>Curl_ssl_connect_nonblocking=>curlssl_connect/Curl_ossl_connect=>ossl_connect_common=>ossl_connect_step1=>Curl_ossl_seed=>ossl_seed=>RAND_load_file
Does this make sense? However, I think there might be some other possible
callchains.
Here are different ssl packages that we have installed:
root@vc1:~# dpkg -l | grep ssl
ii libgnutls-openssl27 2.12.14-5ubuntu3.9 GNU
TLS library - OpenSSL wrapper
ii libssl-dev 1.0.1-4ubuntu5.31 SSL
development libraries, header files and documentation
ii libssl1.0.0 1.0.1-4ubuntu5.31 SSL
shared libraries
ii libsslcommon2 0.14-2
enterprise messaging system - common SSL libraries
ii openssl 1.0.1-4ubuntu5.31
Secure Socket Layer (SSL) binary and related cryptographic tools
ii python-openssl 0.12-1ubuntu2
Python wrapper around the OpenSSL library
Thanks,
Alex.
On Tue, 6 Oct 2015, Alex Lyakas wrote:
#13 0x00007f6b82d2fe0f in RAND_load_file () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f6b85488a85 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
I don't think I've ever seen this. But RAND_load_file there is interesting.
You figured out why that was called?
What OpenSSL version is this?
Without more debugging info it really isn't possible for us to do much,
especially since you're using a version that's slowly turning old and you
only
had since once. We have actually done over 700 recorded bugfixes since that
version was released - and we know of no less than 13 security problems in
7.35.0.
-----Original Message-----
From: Alex Lyakas
Sent: 06 October, 2015 1:13 PM
To: [email protected]
Subject: libcurl segfaults in curl_multi_perform
Greetings,
we had the following segfault:
(gdb) bt
#0 0x00007f6b82cb14d0 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1 0xca62c1d6ca62c1d6 in ?? ()
#2 0xca62c1d6ca62c1d6 in ?? ()
#3 0xca62c1d6ca62c1d6 in ?? ()
#4 0xca62c1d6ca62c1d6 in ?? ()
#5 0xca62c1d6ca62c1d6 in ?? ()
#6 0xca62c1d6ca62c1d6 in ?? ()
#7 0xca62c1d6ca62c1d6 in ?? ()
#8 0xca62c1d6ca62c1d6 in ?? ()
#9 0x00007f6b8301c929 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f6b341e8b30 in ?? ()
#11 0x0000000000000016 in ?? ()
#12 0x00007f6b82cad900 in SHA1_Update () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f6b82d2fe0f in RAND_load_file () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f6b85488a85 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
More details:
libcurl version is 7.35.0, with the following patch manually applied:
multi: fix *getsock() with CONNECT
https://gitlab.pluribusgames.com/mirrors/curl/commit/c19349951df1fde96c31d68e054e3a36a3b03860
This patch allows us to work with proxies via https.
The multi-handle had a single easy handle added to it at the time of the
crash. This easy handle was a DELETE OBJECT request to Amazon S3 service.
This request was to be performed via https through the proxy of type
CURLPROXY_HTTP, and the following proxy-related parameters were set:
CURLOPT_PROXY "10.20.2.118"
CURLOPT_PROXYPORT 3128
CURLOPT_PROXYTYPE – was not set at all
CURLOPT_PROXYUSERNAME, CURLOPT_PROXYPASSWORD were set
For now we have seen this crash only once.
Thanks,
Alex.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
