Bug #107432 for Net-SSLeay: No null pointer check in connect

Wed Sep 30 17:59:38 2015 Marcin.Kasperski [...] mekk.waw.pl - Ticket created

Subject:

No null pointer check in connect

Short story: I am getting coredumps. Not sure who is guilty (maybe some caller, Net::SSLeay itself), but XS_Net__SSLeay_connect gladly passess null pointer to OpenSSL. Please provide reasonable perl-side backtrace instead. Longer story: a few mail and web scrapers I wrote years ago and used for years started to repeatably crash after some system update. The C-side backtrace is short, but fairly self-explaining: (gdb) bt #0 SSL_connect (s=0x0) at ssl_lib.c:945 #1 0x00007f55448265ca in XS_Net__SSLeay_connect (my_perl=<optimized out>, cv=<optimized out>) at SSLeay.c:2045 #2 0x00007f554709d866 in Perl_pp_entersub () from /usr/lib/libperl.so.5.18 #3 0x00007f5547095e86 in Perl_runops_standard () from /usr/lib/libperl.so.5.18 #4 0x00007f554702e844 in perl_run () from /usr/lib/libperl.so.5.18 #5 0x0000000000400dd9 in main () As one can see, SSL_connect is getting null pointer as parameter (which should be SSL*). And here is the critical snippet of XS_Net__SSLeay_connect: SSL * s = INT2PTR(SSL *,SvIV(ST(0))) ; int RETVAL; dXSTARG; RETVAL = SSL_connect(s); It would be nice if instead of dumping core if XS_Net__SSLeay_connect happens to get 0 as parameter, this routine (or sth wrapping it) croak-ed on perl side.

Wed Sep 30 18:04:14 2015 Marcin.Kasperski [...] mekk.waw.pl - Correspondence added

For the sake of completeness, here is SSL_connect from openssl 1.0.1f (which my Ubuntu uses). In no way it may work reasonably on null pointer: int SSL_connect(SSL *s) { if (s->handshake_func == 0) /* Not properly initialized yet */ SSL_set_connect_state(s); return(s->method->ssl_connect(s)); }

Thu Oct 01 00:12:44 2015 mikem [...] airspayce.com - Correspondence added

Subject:	Re: [rt.cpan.org #107432] No null pointer check in connect
Date:	Thu, 01 Oct 2015 14:12:33 +1000
To:	bug-Net-SSLeay [...] rt.cpan.org
From:	Mike McCauley <mikem [...] airspayce.com>

Hello, Thanks for your suggestion. NetSSLeay is intended to be a lightweight wrapper around the existing OpenSSL functions, with a little as possible intervening code, and exposing exactly the same interface as OpenSSL wherever possible. Therfore I do not think its appropriate to add the test you ask for to SSL_connect, nor to the hundreds of other NetSSLeay functions that are passed an SSL pointer. Cheers. On Wednesday, September 30, 2015 06:04:14 PM Marcin Kasperski via RT wrote: Show quoted text

> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=107432 > > > For the sake of completeness, here is SSL_connect from openssl 1.0.1f (which > my Ubuntu uses). In no way it may work reasonably on null pointer: > > int SSL_connect(SSL *s) > { > if (s->handshake_func == 0) > /* Not properly initialized yet */ > SSL_set_connect_state(s); > > return(s->method->ssl_connect(s)); > }

-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474

Thu Oct 01 00:12:46 2015 The RT System itself - Status changed from 'new' to 'open'

Sat Oct 03 04:41:23 2015 Marcin.Kasperski [...] mekk.waw.pl - Correspondence added

The problem is, the „bug-case” interface is definitely not the same. In case you provide null pointer: - from C or C++ code to openssl → you get coredump with rather clear backtrace showhing who called what. - from perl code to SSLeay → you get coredump with backtrace showing absolutely no hint of who provided bad pointer (Perl_pp_entersub called XS_Net__SSLeay_connect which caled SSL_open which coreduped) At the moment the only way to diagnose those cases is to monkeypatch SSLeay, replacing it's functions with parameter-checking versions…

Sun May 05 09:26:10 2019 chrisn [...] cpan.org - Status changed from 'open' to 'rejected'