Hi Daniel,

We upgraded the libcurl to 7.45.0. After several weeks, the same or very
similar problem happened 3 times within 24 hours, unfortunately.

#0 0x00007f4a322284d0 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 0x00007f4a3259392a in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f49e50988b0 in ?? ()
#11 0x0000000000000015 in ?? ()
#12 0x00007f4a32224900 in SHA1_Update () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f4a322a6e0f in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f4a31519a05 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#15 0x00007f4a3150f712 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#16 0x00007f4a3150fb04 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#17 0x00007f4a34a1998e in ossl_send () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#18 0x00007f4a349e38c2 in Curl_write () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#19 0x00007f4a349f9a3f in Curl_readwrite () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#20 0x00007f4a34a01ebc in multi_runsingle () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#21 0x00007f4a34a02c55 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4

Alex.

-----Original Message-----
From: Alex Lyakas
Sent: 06 October, 2015 4:52 PM
To: curl-library_at_cool.haxx.se ; daniel_at_haxx.se
Subject: Re: libcurl segfaults in curl_multi_perform

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_at_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: curl-library_at_cool.haxx.se
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: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-03-24