I'm currently using openssl to provide TLS support for our software. We have
our own networking implemtation using the Linux (unix) networking commands.
This deos error handling, buffering, blocking etc.
The TLS implimentation uses the networking implimentation to communicate with
remote hosts. It does not have direct access to the socket (fd) so it uses a
bio pair to send data to and from the network implimentation.
We have our own memory management and tracking library which we have hooked
into open ssl. When the a program is shutting down our memory will display
the memory leaked and stack trace for its allocation. Using this I have
found two memory leaks for every connection that I can't seem to clean up.
This was observed in 0.9.7a and 0.9.7b versions of openssl.
//the code for creation of the ssl object is as follows.
ConnectionInfo->ssl = SSL_new(ctx);
//create BIO pair
size_t bufsize = BIOPAIRBUFFSIZE;
BIO_new_bio_pair(&(ConnectionInfo->internal_IO), bufsize,
&(ConnectionInfo->external_IO), bufsize)
//set input/output BIOs for ssl object
SSL_set_bio(ConnectionInfo->ssl,
ConnectionInfo->internal_IO,
ConnectionInfo->internal_IO);
//set connect/accept state
if(ConnectionInfo->isserver == true)
{
SSL_set_accept_state(ConnectionInfo->ssl);
}
else
{
SSL_set_connect_state(ConnectionInfo->ssl);
}
//start handshake
int ret = SSL_do_handshake(ConnectionInfo->ssl);
The code for clean up of the object after shutdown has been sent and recivied
is as follows.
//free SSL structures
SSL_free(conninfo->ssl);
BIO_free(conninfo->external_IO);
>From reading the documentation all other structures and memory should be
implicitly cleaned up when I free the ssl object.
One leak has to do with the bio pair. Both bios in the pair are deallocated
when the TLS interaction is complete. The implimentation is the same as that
described in the example on man page for BIO_new_bio_pair.
Stack trace is as follows.
//our memory allocator
(mymalloc__FUi+0x1e) [0x80b2c5a]
[0x8104b76]
(CRYPTO_malloc+0x6d) [0x81050e5]
(sk_new+0x3d) [0x8112311]
(sk_new_null+0x10) [0x81122c4]
[0x8106771]
[0x8106a5e]
(CRYPTO_new_ex_data+0x2e) [0x810718a]
(BIO_set+0xa6) [0x810ba4a]
(BIO_new+0x56) [0x810b976]
(BIO_new_bio_pair+0x2b) [0x8111e27]
//Our program stack
The second memory leak is in the handshake. It is usually 16 bytes in size.
stack trace is as follows.
//our memory allocator
(mymalloc__FUi+0x1e) [0x80b2c5a]
[0x8104b76]
(CRYPTO_malloc+0x6d) [0x81050e5]
(sk_new+0x3d) [0x8112311]
(sk_new_null+0x10) [0x81122c4]
[0x8106771]
[0x8106a5e]
(CRYPTO_new_ex_data+0x2e) [0x810718a]
(SSL_SESSION_new+0xdf) [0x80f0533]
(ssl_get_new_session+0x1a) [0x80f05c6]
[0x80fbe1f]
(ssl3_connect+0x406) [0x80fb60a]
(SSL_do_handshake+0x9f) [0x80ee3f3]
//Our program stack
Is there any way to clean up these memory leaks? Is there something that I
missed or forgot to do?
In addition there are a number of onetime initilization memory leaks. They
all appear to be data that is associated with the ctxs when they are
initilized. Certtificates, Certificate authorities and Private Keys. Each
ctx is freed at during cleanup before the program completes.
--
Walter Proseilo
Bycast Inc.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
