Skip Menu |
 

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 107432
Status: open
Priority: 0/
Queue: Net-SSLeay

People
Owner: Nobody in particular
Requestors: Marcin.Kasperski [...] mekk.waw.pl
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.72
Fixed in: (no value)



Subject: No null pointer check in connect
Download (untitled) / with headers
text/plain 1.2k
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.
Download (untitled) / with headers
text/plain 362b
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)); }
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>
Download (untitled) / with headers
text/plain 1.1k
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
Download (untitled) / with headers
text/plain 561b
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…


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.