W3C home > Mailing lists > Public > www-lib@w3.org > July to September 1999

Bug in libwww-ssl -- can I fix?

From: Gordon Prioreschi <gpriores@ix.netcom.com>
Date: Thu, 16 Sep 1999 11:57:10 -0700
Message-Id: <199909161902.OAA03960@dfw-ix4.ix.netcom.com>
To: www-lib@w3.org
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...  :->



OBgripe: $#@%$#@% export restrictions... !@#%$!#@$ Department of Commerce...
Received on Thursday, 16 September 1999 15:02:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:52 UTC