Bug in libwww-ssl -- can I fix?

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 Thursday, 16 September 1999 15:02:48 UTC