RE: Bug in libwww-ssl -- can I fix?

Hi Gordon,

Yes that is definitely a problem. The Reader should set "disconnected" flag and
the Writer should check it (and the way around). 

I think that sending the patch to the mailing list wouldn't violate any export
regulations.

So you are trying to use ssl with library's POST (that means with nonblocking
sockets and event loops!). Could you please let me know if it works - I have
never tried that.

--------------

In my code I actually moved the management of htssl to the Channel since
managing htssl (for reader and writer of the same connection) in HTSSL.c
practically duplicates the channel management. Reference counting is semaphore
decrease-increade in HTChannl.c, when channel is cleared - htssl is also
deleted. This will also allow to keep persistent ssl connections which improves
performance a lot. With management of htssl structs in HTSSL.c the new htssl is
 created for each request (I tried to change that but w/o success, so I moved
htssl to channel). 

Also I found out that some of the accesses to streams read-writes do not check 
the return codes and consequesntly the "broken pipe" errors (when HTSSLReader
and HTSSLWriter should return HT_CLOSED) go undetected and unhandled.

Olga.

On 16-Sep-99 Gordon Prioreschi wrote:
> Greetings all,
> 
> Found the following bug in libwww-ssl:
> 
> I'm connecting to a secure server that unexpectedly closes its connection
> in the middle of a POST operation (which is the primary bug I'm hunting).
> 
> HTSSL_read() returns an error to HTSSLReader_read(), which causes it to:
> 
> - HTSSL_close(me->htssl)
>   which deallocates *me->htssl->ssl, then sets me->htssl->ssl to NULL.
> - HTSSL_free(me->htssl)
>   which DOESN'T deallocate the htssl object, as it's ALSO referenced in the
>   output stream -- it merely decrements the ref count
> - me->htssl = NULL
>   which causes subsequent calls to HTSSLReader_read() to establish a new 
>   SSL connection
> 
> ... so, after all the pipe recovery stuff in libwww, we end up calling
> HTSSLWriter_write(), whose output stream still references the htssl object
> that references a deallocated SSL connection (me->htssl->ssl == NULL). 
> 
> Note that the checks for a valid SSL connection in HTSSLReader_read() and
> HTSSLWriter_write() check me->htssl, but neither me->htssl->ssl nor
> me->htssl->connected are checked along this code path. So, we end up
> calling SSL_write with s == NULL, causing a seg fault.
> 
> 
> 
> So... How are we working the export restrictions on libwww-ssl? Do I
> correctly surmise from its distribution on an export-secured server that
> it's already had U.S.-based development, and thus that I (a U.S. citizen
> and resident) wouldn't be further compromising its exportability by
> submitting a patch?
> 
> Otherwise, I'm sure the description of the problem I've provided is enough
> to let somebody outside the U.S. write the actual fix...  :->
> 
> 
>                                        Later,
> 
>                                           -g
> 
> 
> OBgripe: $#@%$#@% export restrictions... !@#%$!#@$ Department of Commerce...

Received on Friday, 17 September 1999 11:13:14 UTC