Memory leak Using OpenSSL APIs

Question

I am running a DTLS Server which handles more than 500 connections, every time some connections are closed i see there is some RAM memory utilization increases.

I wonder there is a leak in memory from my below approach of Initialize_Sever_Context , create_connexion and close_connexion. The exact code is too big to create actual scenario, so i just outlined the step.

Pls let me know if any extra information is required?

I am using OpenSSL version 1.1.1k on Linux.

//connect_info structure user defined
{
 void* sll;
 void* bio;
 ....
}array_of_connections

*connect_info = &array_of_connections;
// global
SSL_CTX* server_ctx;

Initialize_Sever_Context()
{
    // server_ctx is global 
    server_ctx = SSL_CTX_new(DTLS_server_method());
    X509_VERIFY_PARAM *local_vpm = X509_VERIFY_PARAM_new()

    //setting verify flags, cookie flags and cypher lists etc..
    //....
    SSL_CTX_set1_param(server_ctx, local_vpm);
}

create_connexion(connect_info)
{
    // server_ctx is global
    ssl = SSL_new(server_ctx);
    
    bio = BIO_new_dgram(handler, BIO_NOCLOSE);
    ..
    ..
    SSL_set_bio(ssl, bio, bio);
    
    connect_info->ssl = ssl;
    connect_info->bio = bio;

}

handle_closed_connexions()
{
    for(conn = 1; conn<MAX_CONN;conn++)
    {
        close_connexion(connect_info[conn]);
    }
}

close_connexion(connect_info)
{
    // store prev ssl objects
    SLL *local_ssl = connect_info -> ssl;
    
    // make setup ready for the next connexions
    // and start listening
    create_connexion(connect_info)

    // free the previous closed connections
    SSL_free(local_ssl);
}

Inside SSL_free we have BIO_free_all(s->rbio), BIO_free_all(s->rbio) and BIO_CTX_free(s->ctx) and finally OPENSSL_free(s)

As far as i understand when we do SSL_free, all the members(pointers) inside SLL object are freed. But inside OpenSSL non of pointers are set to NULL after free(), so i expect the application to crash.

But my application is working even after the pointers are freed.

Why does not OpenSSL set the pointers to NULL after they are freed or Can i assume that my application is Safe with the above approach?

I have checked posts 1 2 and others, but none of them satisfy my requirement, so i am asking a new question.

Fyi, your leaking your param object. `X509_VERIFY_PARAM *local_vpm = X509_VERIFY_PARAM_new()` will create a new param object with a reference count of 1. `SSL_CTX_set1_param(server_ctx, local_vpm);` will add the parameter to the context *and* increment the reference count by 1 (so now it's 2). Fyi, the `set1` functions bump the reference count of the intended object; `set0` does not (e.g. it assumes ownership takeover). — WhozCraig, Apr 06 '22 at 19:56
@WhozCraig, I don't see `set0` functions in OpenSSL code, we have `get0` functions.., could you pls point me at the full function name — Chandra, Apr 07 '22 at 03:51
Short version: once you configure your param object and attach it to the context, free it . Long version: Some api's don't have one or the other. Turns out there aren't any `0` functions for setting SSL_CTX parameters. You need to set the parameter object, then free it locally. the reference count should retain it in single-ownership within the context (and cleaned up when *that* is cleaned up). An example of configuration can be seen at the [code snippet here](https://www.openssl.org/docs/man1.1.1/man3/X509_VERIFY_PARAM_set_flags.html) on the OpenSSL site (scroll near the bottom). — WhozCraig, Apr 07 '22 at 04:47
Thanks @WhozCraig, that is a good suggestion and that is taken care, but unfortunately `Initialize_Sever_Context()` happens only once during the init, but in my case i believe `close_connexion` and `create_connexion` are causing more memory leak.., is the apporach i followed `handle_closed_connexions()` ==> `close_connexion` ==>`create_connexion` is right approach, can we have any better approach. — Chandra, Apr 08 '22 at 05:49

score 0 · Answer 1 · answered Apr 06 '22 at 20:02

0

Why does not OpenSSL set the pointers to NULL after they are freed or Can i assume that my application is Safe with the above approach?

99.99% of the time, the pointers aren't going to be accessed again, so setting them to NULL serves no purpose. If you do happen to need them set to NULL, then you can set them to NULL.

answered Apr 06 '22 at 20:02

David Schwartz

179,497
17
214
278

Eventhough the pointers are not going to accessed again is it not a good coding practice to set them to `NULL`, to avoid accidental usage of same pointers? In case of OpenSSL when i call `SSL_free(s)`, i need to track the definition of `SSL_free` to find out what other objects its freeing, since its internal pointers are `free`d accessing any pointers inside `SSL` object with out allocating new memory again is wrong , but i dont see any abnormal behavior with my code.(since `server_ctx` is `free`d through `SSL_free` and i am using it again with out allocation new memory). – Chandra Apr 08 '22 at 06:01
@Chandra No, that's actually a terrible coding practice for several reasons. Two key reasons: 1) The usual good coding practice is not to use the pointer again, so setting the value of a variable that your coding practice says not to check serves no purpose. 2) It can't provide "belt and suspenders" protection because it's perfectly normal and reasonable to have more than one pointer to the same allocated block and pointers to the middle of allocated blocks. Do you tediously write pointless code to `NULL` them all at the free point? – David Schwartz Apr 08 '22 at 19:18

Memory leak Using OpenSSL APIs

1 Answers1