Memory leak in application when we use ECDH

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Memory leak in application when we use ECDH

Mody, Darshan (Darshan)

Hi,

 

We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. 

 

Further checking the Openssl implementation in the s3_srvr.c file (openssl version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from the application or EC_KEY_new being called.

 

I suspect the below code.

 

if (type & SSL_kEECDH) {

            const EC_GROUP *group;

 

            ecdhp = cert->ecdh_tmp;

            if (s->cert->ecdh_tmp_auto) {

                /* Get NID of appropriate shared curve */

                int nid = tls1_shared_curve(s, -2);

                if (nid != NID_undef)

                    ecdhp = EC_KEY_new_by_curve_name(nid); ß Even memory allocated in this case is not de-allocated.

            } else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {

                ecdhp = s->cert->ecdh_tmp_cb(s,                                                           ß Application is responsible for the EC_KEY and its memory

                                             SSL_C_IS_EXPORT(s->s3->

                                                             tmp.new_cipher),

                                             SSL_C_EXPORT_PKEYLENGTH(s->

                                                                     s3->tmp.new_cipher));

            }

            if (ecdhp == NULL) {

                al = SSL_AD_HANDSHAKE_FAILURE;

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_MISSING_TMP_ECDH_KEY);

                goto f_err;

            }

 

            if (s->s3->tmp.ecdh != NULL) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       ERR_R_INTERNAL_ERROR);

                goto err;

            }

 

            /* Duplicate the ECDH structure. */

            if (ecdhp == NULL) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

            if (s->cert->ecdh_tmp_auto)

                ecdh = ecdhp;

            else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {                                                    ß Once the key is duplicated the memory for the application should be released?

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            s->s3->tmp.ecdh = ecdh;

            if ((EC_KEY_get0_public_key(ecdh) == NULL) ||

                (EC_KEY_get0_private_key(ecdh) == NULL) ||

                (s->options & SSL_OP_SINGLE_ECDH_USE)) {

                if (!EC_KEY_generate_key(ecdh)) {

                    SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                           ERR_R_ECDH_LIB);

                    goto err;

                }

            }

 

            if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||

                (EC_KEY_get0_public_key(ecdh) == NULL) ||

                (EC_KEY_get0_private_key(ecdh) == NULL)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&

                (EC_GROUP_get_degree(group) > 163)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);

                goto err;

            }

 

            /*

             * XXX: For now, we only support ephemeral ECDH keys over named

             * (not generic) curves. For supported named curves, curve_id is

             * non-zero.

             */

            if ((curve_id =

                 tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))

                == 0) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);

                goto err;

            }

 

            /*

             * Encode the public key. First check the size of encoding and

             * allocate memory accordingly.

             */

            encodedlen = EC_POINT_point2oct(group,

                                            EC_KEY_get0_public_key(ecdh),

                                            POINT_CONVERSION_UNCOMPRESSED,

                                            NULL, 0, NULL);

 

            encodedPoint = (unsigned char *)

                OPENSSL_malloc(encodedlen * sizeof(unsigned char));

            bn_ctx = BN_CTX_new();

            if ((encodedPoint == NULL) || (bn_ctx == NULL)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       ERR_R_MALLOC_FAILURE);

                goto err;

            }

 

            encodedlen = EC_POINT_point2oct(group,

                                            EC_KEY_get0_public_key(ecdh),

                                            POINT_CONVERSION_UNCOMPRESSED,

                                            encodedPoint, encodedlen, bn_ctx);

 

            if (encodedlen == 0) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            BN_CTX_free(bn_ctx);

            bn_ctx = NULL;

 

            /*

             * XXX: For now, we only support named (not generic) curves in

             * ECDH ephemeral key exchanges. In this situation, we need four

             * additional bytes to encode the entire ServerECDHParams

             * structure.

             */

            n = 4 + encodedlen;

 

            /*

             * We'll generate the serverKeyExchange message explicitly so we

             * can set these to NULLs

             */

            r[0] = NULL;

            r[1] = NULL;

            r[2] = NULL;

            r[3] = NULL;

        } else

 

 

Thanks for your help in advance

 

Regards

Darshan

 

 

 


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)

Hi,

 

Can anyone in the developer forum clarify whether there is an issue here?

 

Thanks

Darshan

 

From: openssl-dev [mailto:[hidden email]] On Behalf Of Mody, Darshan (Darshan)
Sent: Wednesday, March 15, 2017 11:15 AM
To: [hidden email]
Cc: Bahr, William G (Bill); Vaquero, Alejandro (Alejandro)
Subject: [openssl-dev] Memory leak in application when we use ECDH

 

Hi,

 

We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. 

 

Further checking the Openssl implementation in the s3_srvr.c file (openssl version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from the application or EC_KEY_new being called.

 

I suspect the below code.

 

if (type & SSL_kEECDH) {

            const EC_GROUP *group;

 

            ecdhp = cert->ecdh_tmp;

            if (s->cert->ecdh_tmp_auto) {

                /* Get NID of appropriate shared curve */

                int nid = tls1_shared_curve(s, -2);

                if (nid != NID_undef)

                    ecdhp = EC_KEY_new_by_curve_name(nid); ß Even memory allocated in this case is not de-allocated.

            } else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {

                ecdhp = s->cert->ecdh_tmp_cb(s,                                                           ß Application is responsible for the EC_KEY and its memory

                                             SSL_C_IS_EXPORT(s->s3->

                                                             tmp.new_cipher),

                                             SSL_C_EXPORT_PKEYLENGTH(s->

                                                                     s3->tmp.new_cipher));

            }

            if (ecdhp == NULL) {

                al = SSL_AD_HANDSHAKE_FAILURE;

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_MISSING_TMP_ECDH_KEY);

                goto f_err;

            }

 

            if (s->s3->tmp.ecdh != NULL) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       ERR_R_INTERNAL_ERROR);

                goto err;

            }

 

            /* Duplicate the ECDH structure. */

            if (ecdhp == NULL) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

            if (s->cert->ecdh_tmp_auto)

                ecdh = ecdhp;

            else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {                                                    ß Once the key is duplicated the memory for the application should be released?

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            s->s3->tmp.ecdh = ecdh;

            if ((EC_KEY_get0_public_key(ecdh) == NULL) ||

                (EC_KEY_get0_private_key(ecdh) == NULL) ||

                (s->options & SSL_OP_SINGLE_ECDH_USE)) {

                if (!EC_KEY_generate_key(ecdh)) {

                    SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                           ERR_R_ECDH_LIB);

                    goto err;

                }

            }

 

            if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||

                (EC_KEY_get0_public_key(ecdh) == NULL) ||

                (EC_KEY_get0_private_key(ecdh) == NULL)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&

                (EC_GROUP_get_degree(group) > 163)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);

                goto err;

            }

 

            /*

             * XXX: For now, we only support ephemeral ECDH keys over named

             * (not generic) curves. For supported named curves, curve_id is

             * non-zero.

             */

            if ((curve_id =

                 tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))

                == 0) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);

                goto err;

            }

 

            /*

             * Encode the public key. First check the size of encoding and

             * allocate memory accordingly.

             */

            encodedlen = EC_POINT_point2oct(group,

                                            EC_KEY_get0_public_key(ecdh),

                                            POINT_CONVERSION_UNCOMPRESSED,

                                            NULL, 0, NULL);

 

            encodedPoint = (unsigned char *)

                OPENSSL_malloc(encodedlen * sizeof(unsigned char));

            bn_ctx = BN_CTX_new();

            if ((encodedPoint == NULL) || (bn_ctx == NULL)) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,

                       ERR_R_MALLOC_FAILURE);

                goto err;

            }

 

            encodedlen = EC_POINT_point2oct(group,

                                            EC_KEY_get0_public_key(ecdh),

                                            POINT_CONVERSION_UNCOMPRESSED,

                                            encodedPoint, encodedlen, bn_ctx);

 

            if (encodedlen == 0) {

                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);

                goto err;

            }

 

            BN_CTX_free(bn_ctx);

            bn_ctx = NULL;

 

            /*

             * XXX: For now, we only support named (not generic) curves in

             * ECDH ephemeral key exchanges. In this situation, we need four

             * additional bytes to encode the entire ServerECDHParams

             * structure.

             */

            n = 4 + encodedlen;

 

            /*

             * We'll generate the serverKeyExchange message explicitly so we

             * can set these to NULLs

             */

            r[0] = NULL;

            r[1] = NULL;

            r[2] = NULL;

            r[3] = NULL;

        } else

 

 

Thanks for your help in advance

 

Regards

Darshan

 

 

 


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2
In reply to this post by Mody, Darshan (Darshan)


On 15/03/17 05:44, Mody, Darshan (Darshan) wrote:

> Hi,
>
> We have observed memory leak when we register for ECDH
> callback(SSL_set_tmp_ecdh_callback). While performing negative testing
> with load we find that the applications starts leaking memory.  
>
> Further checking the Openssl implementation in the s3_srvr.c file
> (openssl version 1.0.2). I find that a pointer is not deleted after
> copying EC_KEY from the application or EC_KEY_new being called.
>
> I suspect the below code.

The code looks ok to me:

            if (s->cert->ecdh_tmp_auto)
                ecdh = ecdhp;
            else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }

            s->s3->tmp.ecdh = ecdh;

After the EC_KEY_dup() call, the result is immediately assigned to
"s->s3->tmp.ecdh". This will get freed when you call SSL_free().
Similarly in the non-callback case.

There is a potential leak in this case:

            if (s->s3->tmp.ecdh != NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
                       ERR_R_INTERNAL_ERROR);
                goto err;
            }

But this is a "should not happen" scenario - so there is another bug if
that is happening - and you would see "internal error" messages on the
error stack.

Another slight oddity in this code is the double check of ecdhp against
NULL which seems redundant (but otherwise harmless):

            if (ecdhp == NULL) {
                al = SSL_AD_HANDSHAKE_FAILURE;
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
                       SSL_R_MISSING_TMP_ECDH_KEY);
                goto f_err;
            }

            ...

            /* Duplicate the ECDH structure. */
            if (ecdhp == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }


Also note that SSL_set_tmp_ecdh_callback() has been removed from OpenSSL
1.1.0 with this commit description:

commit 6f78b9e824c053d062188578635c575017b587c5
Author:     Kurt Roeckx <[hidden email]>
AuthorDate: Fri Dec 4 22:22:31 2015 +0100
Commit:     Kurt Roeckx <[hidden email]>
CommitDate: Fri Dec 4 22:22:31 2015 +0100

    Remove support for SSL_{CTX_}set_tmp_ecdh_callback().

    This only gets used to set a specific curve without actually
checking that the
    peer supports it or not and can therefor result in handshake
failures that can
    be avoided by selecting a different cipher.

    Reviewed-by: Dr. Stephen Henson <[hidden email]>


Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2


On 21/03/17 09:46, Matt Caswell wrote:

>
> There is a potential leak in this case:
>
>             if (s->s3->tmp.ecdh != NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        ERR_R_INTERNAL_ERROR);
>                 goto err;
>             }
>
> But this is a "should not happen" scenario - so there is another bug if
> that is happening - and you would see "internal error" messages on the
> error stack.
>
> Another slight oddity in this code is the double check of ecdhp against
> NULL which seems redundant (but otherwise harmless):
>
>             if (ecdhp == NULL) {
>                 al = SSL_AD_HANDSHAKE_FAILURE;
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        SSL_R_MISSING_TMP_ECDH_KEY);
>                 goto f_err;
>             }
>
>             ...
>
>             /* Duplicate the ECDH structure. */
>             if (ecdhp == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://github.com/openssl/openssl/pull/3003

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Matt,

But openssl does not release the memory when it has duplicated the EC Key which comes from the application

           /* Duplicate the ECDH structure. */
            if (ecdhp == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }
            if (s->cert->ecdh_tmp_auto)
                ecdh = ecdhp;
            else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 21/03/17 09:46, Matt Caswell wrote:

>
> There is a potential leak in this case:
>
>             if (s->s3->tmp.ecdh != NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        ERR_R_INTERNAL_ERROR);
>                 goto err;
>             }
>
> But this is a "should not happen" scenario - so there is another bug
> if that is happening - and you would see "internal error" messages on
> the error stack.
>
> Another slight oddity in this code is the double check of ecdhp
> against NULL which seems redundant (but otherwise harmless):
>
>             if (ecdhp == NULL) {
>                 al = SSL_AD_HANDSHAKE_FAILURE;
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        SSL_R_MISSING_TMP_ECDH_KEY);
>                 goto f_err;
>             }
>
>             ...
>
>             /* Duplicate the ECDH structure. */
>             if (ecdhp == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= 

Matt

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Should not openssl release memory from app.

Some like below

            /* Duplicate the ECDH structure. */
            if (ecdhp == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }
            if (s->cert->ecdh_tmp_auto)
                ecdh = ecdhp;
            else {
                if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
                    SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                    goto err;
                }
                else {
                    /* Release memory from cb */
                    If (NULL !=ecdhp) {
                EC_KEY_free(ecdhp);
            }
                }
            }

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Mody, Darshan (Darshan)
Sent: Thursday, March 23, 2017 10:06 AM
To: [hidden email]
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Matt,

But openssl does not release the memory when it has duplicated the EC Key which comes from the application

           /* Duplicate the ECDH structure. */
            if (ecdhp == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }
            if (s->cert->ecdh_tmp_auto)
                ecdh = ecdhp;
            else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
                SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
                goto err;
            }

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 21/03/17 09:46, Matt Caswell wrote:

>
> There is a potential leak in this case:
>
>             if (s->s3->tmp.ecdh != NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        ERR_R_INTERNAL_ERROR);
>                 goto err;
>             }
>
> But this is a "should not happen" scenario - so there is another bug
> if that is happening - and you would see "internal error" messages on
> the error stack.
>
> Another slight oddity in this code is the double check of ecdhp
> against NULL which seems redundant (but otherwise harmless):
>
>             if (ecdhp == NULL) {
>                 al = SSL_AD_HANDSHAKE_FAILURE;
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>                        SSL_R_MISSING_TMP_ECDH_KEY);
>                 goto f_err;
>             }
>
>             ...
>
>             /* Duplicate the ECDH structure. */
>             if (ecdhp == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= 

Matt

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e=
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=ItYO5obXpUhcVAqtr-HAnmatrYOEJ-EpjZhn-eCTsyg&s=EYfD8Wpi4Eji8E2PwNF9obPY-g4EXP5FXF1AzbJtMGU&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2
In reply to this post by Mody, Darshan (Darshan)


On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
>
> But openssl does not release the memory when it has duplicated the EC Key which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no
"official" description of the memory management semantics of this
function (and like I said it has been removed from later versions of
OpenSSL altogether so it is unlikely to ever get documented). However my
interpretation of the way the code is written is that this is a
deliberate design choice, i.e. it is deliberately left to the the
application to mange this memory. Presumably multiple invocations across
multiple connections could return the same value so it would be
inappropriate for OpenSSL to free it.

Matt



>
>            /* Duplicate the ECDH structure. */
>             if (ecdhp == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }
>             if (s->cert->ecdh_tmp_auto)
>                 ecdh = ecdhp;
>             else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }
>
> Thanks
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
>
>
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>>             if (s->s3->tmp.ecdh != NULL) {
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>                        ERR_R_INTERNAL_ERROR);
>>                 goto err;
>>             }
>>
>> But this is a "should not happen" scenario - so there is another bug
>> if that is happening - and you would see "internal error" messages on
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp
>> against NULL which seems redundant (but otherwise harmless):
>>
>>             if (ecdhp == NULL) {
>>                 al = SSL_AD_HANDSHAKE_FAILURE;
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>                        SSL_R_MISSING_TMP_ECDH_KEY);
>>                 goto f_err;
>>             }
>>
>>             ...
>>
>>             /* Duplicate the ECDH structure. */
>>             if (ecdhp == NULL) {
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>>                 goto err;
>>             }
>
> Fix for the above issues (which is unlikely to solve your problem) is here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= 
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= 
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Matt,

Even after accounting for the EC_KEY we still observe some leak. The leak started after we started using supporting EC with callback SSL_set_tmp_ecdh_callback().

The core dump shows  the string data of the far-end certificates. I cannot pin point  the code in openssl with this regard.

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Thursday, March 23, 2017 3:31 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
>
> But openssl does not release the memory when it has duplicated the EC
> Key which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no "official" description of the memory management semantics of this function (and like I said it has been removed from later versions of OpenSSL altogether so it is unlikely to ever get documented). However my interpretation of the way the code is written is that this is a deliberate design choice, i.e. it is deliberately left to the the application to mange this memory. Presumably multiple invocations across multiple connections could return the same value so it would be inappropriate for OpenSSL to free it.

Matt



>
>            /* Duplicate the ECDH structure. */
>             if (ecdhp == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }
>             if (s->cert->ecdh_tmp_auto)
>                 ecdh = ecdhp;
>             else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>                 goto err;
>             }
>
> Thanks
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf
> Of Matt Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
>
>
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>>             if (s->s3->tmp.ecdh != NULL) {
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>                        ERR_R_INTERNAL_ERROR);
>>                 goto err;
>>             }
>>
>> But this is a "should not happen" scenario - so there is another bug
>> if that is happening - and you would see "internal error" messages on
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp
>> against NULL which seems redundant (but otherwise harmless):
>>
>>             if (ecdhp == NULL) {
>>                 al = SSL_AD_HANDSHAKE_FAILURE;
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>                        SSL_R_MISSING_TMP_ECDH_KEY);
>>                 goto f_err;
>>             }
>>
>>             ...
>>
>>             /* Duplicate the ECDH structure. */
>>             if (ecdhp == NULL) {
>>                 SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>>                 goto err;
>>             }
>
> Fix for the above issues (which is unlikely to solve your problem) is here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss
> l_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7I
> nzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuk
> i2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e=
>
> Matt
>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi
> -yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e=
>
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=jvDI18EtBUGVhF0dlpzP1E0w75ZPjyBprI47vr1-QlA&s=QwfWOZbsFqgCiO23c3Z6HmnkCgfsT94LaHQSoaQLIFM&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2


On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
>
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
>
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Can you further elaborate?

What we did is to create a TLS connection and with invalid certificates from the client and server on verification would reject the certificate. The cipher negotiated was ECDHE cipher between client and server.

This was done with load (multiple while 1 script trying to connect to server using invalid certificates and in course of time the memory was increasing).

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Thursday, March 23, 2017 4:09 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
>
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
>
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=bLfMhjtc7o6YlbbKPhSGSKPuhTJsYubiC_LV17YO3do&s=CIdcV48IKxBzbTWaEpB4zcKDD76FwUj3wuMFrxa50UY&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2


On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:

> Can you further elaborate?
>
> What we did is to create a TLS connection and with invalid
> certificates from the client and server on verification would reject
> the certificate. The cipher negotiated was ECDHE cipher between
> client and server.
>
> This was done with load (multiple while 1 script trying to connect to
> server using invalid certificates and in course of time the memory
> was increasing).

Without being able to recreate the problem its going to be very
difficult/impossible for us to fix it (assuming the problem is in
OpenSSl itself). We would need some simple reproducer code that
demonstrates the problem occurring.

Matt


>
> Thanks Darshan
>
> -----Original Message----- From: openssl-dev
> [mailto:[hidden email]] On Behalf Of Matt Caswell
> Sent: Thursday, March 23, 2017 4:09 PM To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use
> ECDH
>
>
>
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>>
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>>
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
>
> Are you able to create a simple reproducer demonstrating the problem
> with the callback?
>
> Matt
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Matt,

Below is the scenario.

1. Have server open a listen socket which always validates the client certificate and chain.
2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
3. Connect client with certificates that server does not trust.
4. The connections from client to server fails

In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.

Hope this helps

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Thursday, March 23, 2017 6:55 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:

> Can you further elaborate?
>
> What we did is to create a TLS connection and with invalid
> certificates from the client and server on verification would reject
> the certificate. The cipher negotiated was ECDHE cipher between client
> and server.
>
> This was done with load (multiple while 1 script trying to connect to
> server using invalid certificates and in course of time the memory was
> increasing).

Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.

Matt


>
> Thanks Darshan
>
> -----Original Message----- From: openssl-dev
> [mailto:[hidden email]] On Behalf Of Matt Caswell
> Sent: Thursday, March 23, 2017 4:09 PM To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
>
>
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>>
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>>
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
>
> Are you able to create a simple reproducer demonstrating the problem
> with the callback?
>
> Matt
>
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Richard Levitte - VMS Whacker-2
I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c,
and give us that patch.

The reason is that we can't know what assumptions you're going with in
your callback or application, so if we code an example together, it
will be with Our conditions, not yours, and therefore a pretty bad
method to figure this out.

Cheers,
Richard

In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:

darshanmody> Matt,
darshanmody>
darshanmody> Below is the scenario.
darshanmody>
darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody>
darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
darshanmody>
darshanmody> Hope this helps
darshanmody>
darshanmody> Thanks
darshanmody> Darshan
darshanmody>
darshanmody> -----Original Message-----
darshanmody> From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: [hidden email]
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
darshanmody>
darshanmody>
darshanmody>
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> >
darshanmody> > What we did is to create a TLS connection and with invalid
darshanmody> > certificates from the client and server on verification would reject
darshanmody> > the certificate. The cipher negotiated was ECDHE cipher between client
darshanmody> > and server.
darshanmody> >
darshanmody> > This was done with load (multiple while 1 script trying to connect to
darshanmody> > server using invalid certificates and in course of time the memory was
darshanmody> > increasing).
darshanmody>
darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
darshanmody>
darshanmody> Matt
darshanmody>
darshanmody>
darshanmody> >
darshanmody> > Thanks Darshan
darshanmody> >
darshanmody> > -----Original Message----- From: openssl-dev
darshanmody> > [mailto:[hidden email]] On Behalf Of Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: [hidden email]
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
darshanmody> >
darshanmody> >
darshanmody> >
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >>
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC with
darshanmody> >> callback SSL_set_tmp_ecdh_callback().
darshanmody> >>
darshanmody> >> The core dump shows  the string data of the far-end certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> >
darshanmody> > Are you able to create a simple reproducer demonstrating the problem
darshanmody> > with the callback?
darshanmody> >
darshanmody> > Matt
darshanmody> >
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= 
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
darshanmody>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Thanks Richard and Matt,

I will patch it and send the patch. It will take me couple of days.

Regards
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Richard Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch.

The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out.

Cheers,
Richard

In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:

darshanmody> Matt,
darshanmody>
darshanmody> Below is the scenario.
darshanmody>
darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody>
darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
darshanmody>
darshanmody> Hope this helps
darshanmody>
darshanmody> Thanks
darshanmody> Darshan
darshanmody>
darshanmody> -----Original Message-----
darshanmody> From: openssl-dev [mailto:[hidden email]]
darshanmody> On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: [hidden email]
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when
darshanmody> we use ECDH
darshanmody>
darshanmody>
darshanmody>
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> >
darshanmody> > What we did is to create a TLS connection and with
darshanmody> > invalid certificates from the client and server on
darshanmody> > verification would reject the certificate. The cipher
darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> >
darshanmody> > This was done with load (multiple while 1 script trying
darshanmody> > to connect to server using invalid certificates and in
darshanmody> > course of time the memory was increasing).
darshanmody>
darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
darshanmody>
darshanmody> Matt
darshanmody>
darshanmody>
darshanmody> >
darshanmody> > Thanks Darshan
darshanmody> >
darshanmody> > -----Original Message----- From: openssl-dev
darshanmody> > [mailto:[hidden email]] On Behalf Of
darshanmody> > Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To:
darshanmody> > [hidden email]
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application
darshanmody> > when we use ECDH
darshanmody> >
darshanmody> >
darshanmody> >
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >>
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC
darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
darshanmody> >>
darshanmody> >> The core dump shows  the string data of the far-end certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> >
darshanmody> > Are you able to create a simple reproducer demonstrating
darshanmody> > the problem with the callback?
darshanmody> >
darshanmody> > Matt
darshanmody> >
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe:
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf
darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e=
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe:
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q
darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
darshanmody>
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Matt, Richard,

I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run

openssl s_server -accept <port> -key <custom-key> -cert <custom-certificate signed by custom CA> -CAfile <custom self signed CA>  -verify <custom self signed CA>

On the client side I am running script below

#/bin/sh

while [ 1 ]
do
     openssl s_client -connect <server-ip>:<server-port> -cert <custom client certificate not trusted by server> -key <custom client certificate key> &>/dev/null
done

Running the client once and printing the results showed the cipher selected was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of openssl.

I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue.

top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3924288k total,  3757716k used,   166572k free,    78200k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl


top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   3924288k total,  3757856k used,   166432k free,    78208k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl


top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   3924288k total,  3757980k used,   166308k free,    78232k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3544 2740 S  7.0  0.1   0:00.34 openssl


top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.1%us,  1.1%sy,  0.0%ni, 96.5%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   3924288k total,  3757964k used,   166324k free,    78248k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl


top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   3924288k total,  3758212k used,   166076k free,    78264k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3572 2740 S  8.0  0.1   0:00.78 openssl


top - 10:16:52 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.2%sy,  0.0%ni, 94.8%id,  0.1%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3758212k used,   166076k free,    78288k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3592 2740 S 11.0  0.1   0:01.11 openssl


top - 10:16:55 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  1.3%sy,  0.1%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3758584k used,   165704k free,    78288k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3608 2740 S 11.3  0.1   0:01.45 openssl


top - 10:16:58 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  1.6%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   3924288k total,  3758864k used,   165424k free,    78296k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 39908 3628 2740 S 11.3  0.1   0:01.79 openssl


top - 10:17:01 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.4%us,  1.5%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   3924288k total,  3758956k used,   165332k free,    78312k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219740k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40016 3648 2740 S 10.7  0.1   0:02.11 openssl


top - 10:17:04 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.9%us,  1.9%sy,  0.0%ni, 91.9%id,  1.6%wa,  0.0%hi,  0.7%si,  0.0%st
Mem:   3924288k total,  3759708k used,   164580k free,    78328k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40016 3668 2740 S 11.0  0.1   0:02.44 openssl


top - 10:17:07 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.4%us,  1.2%sy,  0.1%ni, 93.8%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
Mem:   3924288k total,  3759336k used,   164952k free,    78360k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219900k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40016 3688 2740 R 10.7  0.1   0:02.76 openssl


top - 10:17:10 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.6%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Mem:   3924288k total,  3758584k used,   165704k free,    78360k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40016 3708 2740 S 11.3  0.1   0:03.10 openssl


top - 10:17:13 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  1.1%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  0.8%si,  0.0%st
Mem:   3924288k total,  3758476k used,   165812k free,    78376k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40016 3728 2740 S 10.7  0.1   0:03.42 openssl


top - 10:17:16 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  1.7%si,  0.0%st
Mem:   3924288k total,  3759824k used,   164464k free,    78384k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 40124 3748 2740 S 11.3  0.1   0:03.76 openssl

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

top - 10:23:10 up 46 days,  1:36,  2 users,  load average: 0.03, 0.05, 0.06
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  1.3%sy,  0.1%ni, 94.4%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3756048k used,   168240k free,    75888k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216576k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 42392 6048 2740 S 10.7  0.2   0:41.95 openssl


top - 10:23:13 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3756064k used,   168224k free,    75904k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 42392 6068 2740 S 10.7  0.2   0:42.27 openssl


top - 10:23:16 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.3%sy,  0.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   3924288k total,  3756188k used,   168100k free,    75912k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 42392 6088 2740 R 11.0  0.2   0:42.60 openssl


top - 10:23:19 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.1%us,  1.2%sy,  1.6%ni, 93.5%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3756528k used,   167760k free,    75920k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216584k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 42392 6108 2740 S 10.7  0.2   0:42.92 openssl


top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3756924k used,   167364k free,    75952k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216600k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27303 root      20   0 42500 6124 2740 S 10.3  0.2   0:43.23 openssl

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Mody, Darshan (Darshan)
Sent: Thursday, March 23, 2017 7:40 PM
To: [hidden email]
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Thanks Richard and Matt,

I will patch it and send the patch. It will take me couple of days.

Regards
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Richard Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch.

The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out.

Cheers,
Richard

In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:

darshanmody> Matt,
darshanmody>
darshanmody> Below is the scenario.
darshanmody>
darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody>
darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
darshanmody>
darshanmody> Hope this helps
darshanmody>
darshanmody> Thanks
darshanmody> Darshan
darshanmody>
darshanmody> -----Original Message-----
darshanmody> From: openssl-dev [mailto:[hidden email]]
darshanmody> On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: [hidden email]
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when
darshanmody> we use ECDH
darshanmody>
darshanmody>
darshanmody>
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> >
darshanmody> > What we did is to create a TLS connection and with
darshanmody> > invalid certificates from the client and server on
darshanmody> > verification would reject the certificate. The cipher
darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> >
darshanmody> > This was done with load (multiple while 1 script trying
darshanmody> > to connect to server using invalid certificates and in
darshanmody> > course of time the memory was increasing).
darshanmody>
darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
darshanmody>
darshanmody> Matt
darshanmody>
darshanmody>
darshanmody> >
darshanmody> > Thanks Darshan
darshanmody> >
darshanmody> > -----Original Message----- From: openssl-dev
darshanmody> > [mailto:[hidden email]] On Behalf Of
darshanmody> > Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To:
darshanmody> > [hidden email]
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application
darshanmody> > when we use ECDH
darshanmody> >
darshanmody> >
darshanmody> >
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >>
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC
darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
darshanmody> >>
darshanmody> >> The core dump shows  the string data of the far-end certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> >
darshanmody> > Are you able to create a simple reproducer demonstrating
darshanmody> > the problem with the callback?
darshanmody> >
darshanmody> > Matt
darshanmody> >
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe:
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf
darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e=
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe:
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q
darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
darshanmody>
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Richard Levitte - VMS Whacker-2
Are you confident this is the same leak that you have experienced?
Your original complaint was about keys created with the callback
that's added with SSL_set_tmp_ecdh_callback(), and I have to point out
that s_server doesn't provide such a callback.  In fact,
SSL_set_tmp_ecdh_callback() isn't called anywhere in the OpenSSL
source.

That doesn't mean you haven't found the same leak, if there is a leak
(I'm not going to rule out some other explanation), it might simply
clarify that targeting on the EC_KEY returned from the callback might
make us blind for something else that's related.

Cheers,
Richard

In message <[hidden email]> on Mon, 27 Mar 2017 08:40:30 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:

darshanmody> Matt, Richard,
darshanmody>
darshanmody> I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run
darshanmody>
darshanmody> openssl s_server -accept <port> -key <custom-key> -cert <custom-certificate signed by custom CA> -CAfile <custom self signed CA>  -verify <custom self signed CA>
darshanmody>
darshanmody> On the client side I am running script below
darshanmody>
darshanmody> #/bin/sh
darshanmody>
darshanmody> while [ 1 ]
darshanmody> do
darshanmody>      openssl s_client -connect <server-ip>:<server-port> -cert <custom client certificate not trusted by server> -key <custom client certificate key> &>/dev/null
darshanmody> done
darshanmody>
darshanmody> Running the client once and printing the results showed the cipher selected was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of openssl.
darshanmody>
darshanmody> I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue.
darshanmody>
darshanmody> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
darshanmody> Mem:   3924288k total,  3757716k used,   166572k free,    78200k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
darshanmody> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
darshanmody> Mem:   3924288k total,  3757856k used,   166432k free,    78208k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
darshanmody> Mem:   3924288k total,  3757980k used,   166308k free,    78232k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3544 2740 S  7.0  0.1   0:00.34 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  2.1%us,  1.1%sy,  0.0%ni, 96.5%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
darshanmody> Mem:   3924288k total,  3757964k used,   166324k free,    78248k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758212k used,   166076k free,    78264k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3572 2740 S  8.0  0.1   0:00.78 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:52 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.2%us,  1.2%sy,  0.0%ni, 94.8%id,  0.1%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758212k used,   166076k free,    78288k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3592 2740 S 11.0  0.1   0:01.11 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:55 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.3%us,  1.3%sy,  0.1%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758584k used,   165704k free,    78288k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3608 2740 S 11.3  0.1   0:01.45 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:16:58 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.3%us,  1.6%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758864k used,   165424k free,    78296k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 39908 3628 2740 S 11.3  0.1   0:01.79 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:01 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.4%us,  1.5%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758956k used,   165332k free,    78312k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219740k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40016 3648 2740 S 10.7  0.1   0:02.11 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:04 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.9%us,  1.9%sy,  0.0%ni, 91.9%id,  1.6%wa,  0.0%hi,  0.7%si,  0.0%st
darshanmody> Mem:   3924288k total,  3759708k used,   164580k free,    78328k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40016 3668 2740 S 11.0  0.1   0:02.44 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:07 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
darshanmody> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.4%us,  1.2%sy,  0.1%ni, 93.8%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
darshanmody> Mem:   3924288k total,  3759336k used,   164952k free,    78360k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219900k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40016 3688 2740 R 10.7  0.1   0:02.76 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:10 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.2%us,  1.6%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758584k used,   165704k free,    78360k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40016 3708 2740 S 11.3  0.1   0:03.10 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:13 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.6%us,  1.1%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  0.8%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758476k used,   165812k free,    78376k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40016 3728 2740 S 10.7  0.1   0:03.42 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:17:16 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  1.7%si,  0.0%st
darshanmody> Mem:   3924288k total,  3759824k used,   164464k free,    78384k buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 40124 3748 2740 S 11.3  0.1   0:03.76 openssl
darshanmody>
darshanmody> ---------------
darshanmody>
darshanmody> top - 10:23:10 up 46 days,  1:36,  2 users,  load average: 0.03, 0.05, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.6%us,  1.3%sy,  0.1%ni, 94.4%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756048k used,   168240k free,    75888k buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216576k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 42392 6048 2740 S 10.7  0.2   0:41.95 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:23:13 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.2%us,  1.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756064k used,   168224k free,    75904k buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 42392 6068 2740 S 10.7  0.2   0:42.27 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:23:16 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
darshanmody> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.2%us,  1.3%sy,  0.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756188k used,   168100k free,    75912k buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 42392 6088 2740 R 11.0  0.2   0:42.60 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:23:19 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s):  3.1%us,  1.2%sy,  1.6%ni, 93.5%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756528k used,   167760k free,    75920k buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216584k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 42392 6108 2740 S 10.7  0.2   0:42.92 openssl
darshanmody>
darshanmody>
darshanmody> top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
darshanmody> Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756924k used,   167364k free,    75952k buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216600k cached
darshanmody>
darshanmody>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
darshanmody> 27303 root      20   0 42500 6124 2740 S 10.3  0.2   0:43.23 openssl
darshanmody>
darshanmody> Thanks
darshanmody> Darshan
darshanmody>
darshanmody> -----Original Message-----
darshanmody> From: openssl-dev [mailto:[hidden email]] On Behalf Of Mody, Darshan (Darshan)
darshanmody> Sent: Thursday, March 23, 2017 7:40 PM
darshanmody> To: [hidden email]
darshanmody> Cc: Bahr, William G (Bill)
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
darshanmody>
darshanmody> Thanks Richard and Matt,
darshanmody>
darshanmody> I will patch it and send the patch. It will take me couple of days.
darshanmody>
darshanmody> Regards
darshanmody> Darshan
darshanmody>
darshanmody> -----Original Message-----
darshanmody> From: openssl-dev [mailto:[hidden email]] On Behalf Of Richard Levitte
darshanmody> Sent: Thursday, March 23, 2017 7:31 PM
darshanmody> To: [hidden email]
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
darshanmody>
darshanmody> I think that Matt is asking for example code that exhibits this leak.
darshanmody> You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch.
darshanmody>
darshanmody> The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out.
darshanmody>
darshanmody> Cheers,
darshanmody> Richard
darshanmody>
darshanmody> In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:
darshanmody>
darshanmody> darshanmody> Matt,
darshanmody> darshanmody>
darshanmody> darshanmody> Below is the scenario.
darshanmody> darshanmody>
darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
darshanmody> darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
darshanmody> darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> darshanmody> 4. The connections from client to server fails
darshanmody> darshanmody>
darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
darshanmody> darshanmody>
darshanmody> darshanmody> Hope this helps
darshanmody> darshanmody>
darshanmody> darshanmody> Thanks
darshanmody> darshanmody> Darshan
darshanmody> darshanmody>
darshanmody> darshanmody> -----Original Message-----
darshanmody> darshanmody> From: openssl-dev [mailto:[hidden email]]
darshanmody> darshanmody> On Behalf Of Matt Caswell
darshanmody> darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> darshanmody> To: [hidden email]
darshanmody> darshanmody> Subject: Re: [openssl-dev] Memory leak in application when
darshanmody> darshanmody> we use ECDH
darshanmody> darshanmody>
darshanmody> darshanmody>
darshanmody> darshanmody>
darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> darshanmody> > Can you further elaborate?
darshanmody> darshanmody> >
darshanmody> darshanmody> > What we did is to create a TLS connection and with
darshanmody> darshanmody> > invalid certificates from the client and server on
darshanmody> darshanmody> > verification would reject the certificate. The cipher
darshanmody> darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> darshanmody> >
darshanmody> darshanmody> > This was done with load (multiple while 1 script trying
darshanmody> darshanmody> > to connect to server using invalid certificates and in
darshanmody> darshanmody> > course of time the memory was increasing).
darshanmody> darshanmody>
darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
darshanmody> darshanmody>
darshanmody> darshanmody> Matt
darshanmody> darshanmody>
darshanmody> darshanmody>
darshanmody> darshanmody> >
darshanmody> darshanmody> > Thanks Darshan
darshanmody> darshanmody> >
darshanmody> darshanmody> > -----Original Message----- From: openssl-dev
darshanmody> darshanmody> > [mailto:[hidden email]] On Behalf Of
darshanmody> darshanmody> > Matt Caswell
darshanmody> darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To:
darshanmody> darshanmody> > [hidden email]
darshanmody> darshanmody> > Subject: Re: [openssl-dev] Memory leak in application
darshanmody> darshanmody> > when we use ECDH
darshanmody> darshanmody> >
darshanmody> darshanmody> >
darshanmody> darshanmody> >
darshanmody> darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> darshanmody> >> Matt,
darshanmody> darshanmody> >>
darshanmody> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> darshanmody> >> The leak started after we started using supporting EC
darshanmody> darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
darshanmody> darshanmody> >>
darshanmody> darshanmody> >> The core dump shows  the string data of the far-end certificates.
darshanmody> darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> darshanmody> >
darshanmody> darshanmody> > Are you able to create a simple reproducer demonstrating
darshanmody> darshanmody> > the problem with the callback?
darshanmody> darshanmody> >
darshanmody> darshanmody> > Matt
darshanmody> darshanmody> >
darshanmody> darshanmody> --
darshanmody> darshanmody> openssl-dev mailing list
darshanmody> darshanmody> To unsubscribe:
darshanmody> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf
darshanmody> darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e=
darshanmody> darshanmody> --
darshanmody> darshanmody> openssl-dev mailing list
darshanmody> darshanmody> To unsubscribe:
darshanmody> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
darshanmody> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
darshanmody> darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q
darshanmody> darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
darshanmody> darshanmody>
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= 
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
darshanmody>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Matt Caswell-2
In reply to this post by Mody, Darshan (Darshan)
Hi Darshan

The behaviour you are seeing is not particularly surprising and does not
indicate a memory leak. s_server maintains a cache of sessions from
previous connections to enable the resumption capability. Since your
s_client loop isn't resuming it creates a new session every time (which
contains the client certificate), so I would expect the memory to grow.

To confirm there are no leaks I ran s_server through valgrind and ran
your s_client loop. I actually *did* find a minor leak - but it does not
grow over time and is constant no matter how many connections are made.
It only affects the command line apps and is also quite small (64 bytes
on my machine). Fix here:

https://github.com/openssl/openssl/pull/3040

This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0
(probably because of the new auto-deinit capability).

Once the above patch was applied running s_server through valgrind with
your s_client loop gives me:


CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
  71 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
  70 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
==15312==
==15312== HEAP SUMMARY:
==15312==     in use at exit: 0 bytes in 0 blocks
==15312==   total heap usage: 230,141 allocs, 230,141 frees, 19,200,644
bytes allocated
==15312==
==15312== All heap blocks were freed -- no leaks are possible
==15312==
==15312== For counts of detected and suppressed errors, rerun with: -v
==15312== Use --track-origins=yes to see where uninitialised values come
from
==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0
from 0)


Matt



On 27/03/17 09:40, Mody, Darshan (Darshan) wrote:

> Matt, Richard,
>
> I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run
>
> openssl s_server -accept <port> -key <custom-key> -cert <custom-certificate signed by custom CA> -CAfile <custom self signed CA>  -verify <custom self signed CA>
>
> On the client side I am running script below
>
> #/bin/sh
>
> while [ 1 ]
> do
>      openssl s_client -connect <server-ip>:<server-port> -cert <custom client certificate not trusted by server> -key <custom client certificate key> &>/dev/null
> done
>
> Running the client once and printing the results showed the cipher selected was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of openssl.
>
> I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue.
>
> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   3924288k total,  3757716k used,   166572k free,    78200k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl
>
>
> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:   3924288k total,  3757856k used,   166432k free,    78208k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl
>
>
> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
> Mem:   3924288k total,  3757980k used,   166308k free,    78232k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3544 2740 S  7.0  0.1   0:00.34 openssl
>
>
> top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.1%us,  1.1%sy,  0.0%ni, 96.5%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
> Mem:   3924288k total,  3757964k used,   166324k free,    78248k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl
>
>
> top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
> Mem:   3924288k total,  3758212k used,   166076k free,    78264k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3572 2740 S  8.0  0.1   0:00.78 openssl
>
>
> top - 10:16:52 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.2%sy,  0.0%ni, 94.8%id,  0.1%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3758212k used,   166076k free,    78288k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3592 2740 S 11.0  0.1   0:01.11 openssl
>
>
> top - 10:16:55 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.3%us,  1.3%sy,  0.1%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3758584k used,   165704k free,    78288k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3608 2740 S 11.3  0.1   0:01.45 openssl
>
>
> top - 10:16:58 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.3%us,  1.6%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3758864k used,   165424k free,    78296k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3628 2740 S 11.3  0.1   0:01.79 openssl
>
>
> top - 10:17:01 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.4%us,  1.5%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3758956k used,   165332k free,    78312k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219740k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3648 2740 S 10.7  0.1   0:02.11 openssl
>
>
> top - 10:17:04 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.9%us,  1.9%sy,  0.0%ni, 91.9%id,  1.6%wa,  0.0%hi,  0.7%si,  0.0%st
> Mem:   3924288k total,  3759708k used,   164580k free,    78328k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3668 2740 S 11.0  0.1   0:02.44 openssl
>
>
> top - 10:17:07 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.4%us,  1.2%sy,  0.1%ni, 93.8%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
> Mem:   3924288k total,  3759336k used,   164952k free,    78360k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219900k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3688 2740 R 10.7  0.1   0:02.76 openssl
>
>
> top - 10:17:10 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.6%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
> Mem:   3924288k total,  3758584k used,   165704k free,    78360k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3708 2740 S 11.3  0.1   0:03.10 openssl
>
>
> top - 10:17:13 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.6%us,  1.1%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  0.8%si,  0.0%st
> Mem:   3924288k total,  3758476k used,   165812k free,    78376k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3728 2740 S 10.7  0.1   0:03.42 openssl
>
>
> top - 10:17:16 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  1.7%si,  0.0%st
> Mem:   3924288k total,  3759824k used,   164464k free,    78384k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40124 3748 2740 S 11.3  0.1   0:03.76 openssl
>
> ---------------
>
> top - 10:23:10 up 46 days,  1:36,  2 users,  load average: 0.03, 0.05, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.6%us,  1.3%sy,  0.1%ni, 94.4%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756048k used,   168240k free,    75888k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216576k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6048 2740 S 10.7  0.2   0:41.95 openssl
>
>
> top - 10:23:13 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756064k used,   168224k free,    75904k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6068 2740 S 10.7  0.2   0:42.27 openssl
>
>
> top - 10:23:16 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.3%sy,  0.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3756188k used,   168100k free,    75912k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6088 2740 R 11.0  0.2   0:42.60 openssl
>
>
> top - 10:23:19 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.1%us,  1.2%sy,  1.6%ni, 93.5%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756528k used,   167760k free,    75920k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216584k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6108 2740 S 10.7  0.2   0:42.92 openssl
>
>
> top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756924k used,   167364k free,    75952k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216600k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42500 6124 2740 S 10.3  0.2   0:43.23 openssl
>
> Thanks
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf Of Mody, Darshan (Darshan)
> Sent: Thursday, March 23, 2017 7:40 PM
> To: [hidden email]
> Cc: Bahr, William G (Bill)
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
> Thanks Richard and Matt,
>
> I will patch it and send the patch. It will take me couple of days.
>
> Regards
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf Of Richard Levitte
> Sent: Thursday, March 23, 2017 7:31 PM
> To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
> I think that Matt is asking for example code that exhibits this leak.
> You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch.
>
> The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out.
>
> Cheers,
> Richard
>
> In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:
>
> darshanmody> Matt,
> darshanmody>
> darshanmody> Below is the scenario.
> darshanmody>
> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
> darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
> darshanmody> 3. Connect client with certificates that server does not trust.
> darshanmody> 4. The connections from client to server fails
> darshanmody>
> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
> darshanmody>
> darshanmody> Hope this helps
> darshanmody>
> darshanmody> Thanks
> darshanmody> Darshan
> darshanmody>
> darshanmody> -----Original Message-----
> darshanmody> From: openssl-dev [mailto:[hidden email]]
> darshanmody> On Behalf Of Matt Caswell
> darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
> darshanmody> To: [hidden email]
> darshanmody> Subject: Re: [openssl-dev] Memory leak in application when
> darshanmody> we use ECDH
> darshanmody>
> darshanmody>
> darshanmody>
> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> darshanmody> > Can you further elaborate?
> darshanmody> >
> darshanmody> > What we did is to create a TLS connection and with
> darshanmody> > invalid certificates from the client and server on
> darshanmody> > verification would reject the certificate. The cipher
> darshanmody> > negotiated was ECDHE cipher between client and server.
> darshanmody> >
> darshanmody> > This was done with load (multiple while 1 script trying
> darshanmody> > to connect to server using invalid certificates and in
> darshanmody> > course of time the memory was increasing).
> darshanmody>
> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
> darshanmody>
> darshanmody> Matt
> darshanmody>
> darshanmody>
> darshanmody> >
> darshanmody> > Thanks Darshan
> darshanmody> >
> darshanmody> > -----Original Message----- From: openssl-dev
> darshanmody> > [mailto:[hidden email]] On Behalf Of
> darshanmody> > Matt Caswell
> darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To:
> darshanmody> > [hidden email]
> darshanmody> > Subject: Re: [openssl-dev] Memory leak in application
> darshanmody> > when we use ECDH
> darshanmody> >
> darshanmody> >
> darshanmody> >
> darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> darshanmody> >> Matt,
> darshanmody> >>
> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
> darshanmody> >> The leak started after we started using supporting EC
> darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
> darshanmody> >>
> darshanmody> >> The core dump shows  the string data of the far-end certificates.
> darshanmody> >> I cannot pin point  the code in openssl with this regard.
> darshanmody> >
> darshanmody> > Are you able to create a simple reproducer demonstrating
> darshanmody> > the problem with the callback?
> darshanmody> >
> darshanmody> > Matt
> darshanmody> >
> darshanmody> --
> darshanmody> openssl-dev mailing list
> darshanmody> To unsubscribe:
> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
> darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf
> darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e=
> darshanmody> --
> darshanmody> openssl-dev mailing list
> darshanmody> To unsubscribe:
> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8
> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK
> darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q
> darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
> darshanmody>
> --
> openssl-dev mailing list
> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
> --
> openssl-dev mailing list
> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= 
>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Memory leak in application when we use ECDH

Mody, Darshan (Darshan)
Matt,

We have set SSL_CTX_set_session_cache_mode(ctx, /*SSL_SESS_CACHE_SERVER */ SSL_SESS_CACHE_OFF);

Do you observe the same behavior with s_server app when we have cache mode set as SSL_SES_CACHE_OFF?

Thanks
Darshan

-----Original Message-----
From: openssl-dev [mailto:[hidden email]] On Behalf Of Matt Caswell
Sent: Monday, March 27, 2017 3:04 PM
To: [hidden email]
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Hi Darshan

The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server maintains a cache of sessions from previous connections to enable the resumption capability. Since your s_client loop isn't resuming it creates a new session every time (which contains the client certificate), so I would expect the memory to grow.

To confirm there are no leaks I ran s_server through valgrind and ran your s_client loop. I actually *did* find a minor leak - but it does not grow over time and is constant no matter how many connections are made.
It only affects the command line apps and is also quite small (64 bytes on my machine). Fix here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3040&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU&s=VTPuVxG9-V4MA6C5eMla9AZ1hS3cGGFkl6PN3R0bAyA&e= 

This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0 (probably because of the new auto-deinit capability).

Once the above patch was applied running s_server through valgrind with your s_client loop gives me:


CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
  71 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
  70 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
==15312==
==15312== HEAP SUMMARY:
==15312==     in use at exit: 0 bytes in 0 blocks
==15312==   total heap usage: 230,141 allocs, 230,141 frees, 19,200,644
bytes allocated
==15312==
==15312== All heap blocks were freed -- no leaks are possible ==15312== ==15312== For counts of detected and suppressed errors, rerun with: -v ==15312== Use --track-origins=yes to see where uninitialised values come from ==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0 from 0)


Matt



On 27/03/17 09:40, Mody, Darshan (Darshan) wrote:

> Matt, Richard,
>
> I have not created any patch. Instead I am using s_server app provided
> from Openssl. Below is the server side command run
>
> openssl s_server -accept <port> -key <custom-key> -cert
> <custom-certificate signed by custom CA> -CAfile <custom self signed
> CA>  -verify <custom self signed CA>
>
> On the client side I am running script below
>
> #/bin/sh
>
> while [ 1 ]
> do
>      openssl s_client -connect <server-ip>:<server-port> -cert <custom
> client certificate not trusted by server> -key <custom client
> certificate key> &>/dev/null done
>
> Running the client once and printing the results showed the cipher selected was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of openssl.
>
> I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue.
>
> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   3924288k total,  3757716k used,   166572k free,    78200k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl
>
>
> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:   3924288k total,  3757856k used,   166432k free,    78208k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl
>
>
> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
> Mem:   3924288k total,  3757980k used,   166308k free,    78232k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3544 2740 S  7.0  0.1   0:00.34 openssl
>
>
> top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.1%us,  1.1%sy,  0.0%ni, 96.5%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
> Mem:   3924288k total,  3757964k used,   166324k free,    78248k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl
>
>
> top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
> Mem:   3924288k total,  3758212k used,   166076k free,    78264k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3572 2740 S  8.0  0.1   0:00.78 openssl
>
>
> top - 10:16:52 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.2%sy,  0.0%ni, 94.8%id,  0.1%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3758212k used,   166076k free,    78288k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3592 2740 S 11.0  0.1   0:01.11 openssl
>
>
> top - 10:16:55 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.3%us,  1.3%sy,  0.1%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3758584k used,   165704k free,    78288k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3608 2740 S 11.3  0.1   0:01.45 openssl
>
>
> top - 10:16:58 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.3%us,  1.6%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3758864k used,   165424k free,    78296k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 39908 3628 2740 S 11.3  0.1   0:01.79 openssl
>
>
> top - 10:17:01 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.4%us,  1.5%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3758956k used,   165332k free,    78312k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219740k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3648 2740 S 10.7  0.1   0:02.11 openssl
>
>
> top - 10:17:04 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.9%us,  1.9%sy,  0.0%ni, 91.9%id,  1.6%wa,  0.0%hi,  0.7%si,  0.0%st
> Mem:   3924288k total,  3759708k used,   164580k free,    78328k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3668 2740 S 11.0  0.1   0:02.44 openssl
>
>
> top - 10:17:07 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.4%us,  1.2%sy,  0.1%ni, 93.8%id,  0.0%wa,  0.0%hi,  1.4%si,  0.0%st
> Mem:   3924288k total,  3759336k used,   164952k free,    78360k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219900k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3688 2740 R 10.7  0.1   0:02.76 openssl
>
>
> top - 10:17:10 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.6%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
> Mem:   3924288k total,  3758584k used,   165704k free,    78360k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219916k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3708 2740 S 11.3  0.1   0:03.10 openssl
>
>
> top - 10:17:13 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.6%us,  1.1%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  0.8%si,  0.0%st
> Mem:   3924288k total,  3758476k used,   165812k free,    78376k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40016 3728 2740 S 10.7  0.1   0:03.42 openssl
>
>
> top - 10:17:16 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.07
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  1.7%si,  0.0%st
> Mem:   3924288k total,  3759824k used,   164464k free,    78384k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219920k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 40124 3748 2740 S 11.3  0.1   0:03.76 openssl
>
> ---------------
>
> top - 10:23:10 up 46 days,  1:36,  2 users,  load average: 0.03, 0.05, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.6%us,  1.3%sy,  0.1%ni, 94.4%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756048k used,   168240k free,    75888k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216576k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6048 2740 S 10.7  0.2   0:41.95 openssl
>
>
> top - 10:23:13 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756064k used,   168224k free,    75904k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6068 2740 S 10.7  0.2   0:42.27 openssl
>
>
> top - 10:23:16 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.2%us,  1.3%sy,  0.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
> Mem:   3924288k total,  3756188k used,   168100k free,    75912k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216572k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6088 2740 R 11.0  0.2   0:42.60 openssl
>
>
> top - 10:23:19 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  3.1%us,  1.2%sy,  1.6%ni, 93.5%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756528k used,   167760k free,    75920k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216584k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42392 6108 2740 S 10.7  0.2   0:42.92 openssl
>
>
> top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
> Mem:   3924288k total,  3756924k used,   167364k free,    75952k buffers
> Swap:  8388604k total,   998972k used,  7389632k free,   216600k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 27303 root      20   0 42500 6124 2740 S 10.3  0.2   0:43.23 openssl
>
> Thanks
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf
> Of Mody, Darshan (Darshan)
> Sent: Thursday, March 23, 2017 7:40 PM
> To: [hidden email]
> Cc: Bahr, William G (Bill)
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
> Thanks Richard and Matt,
>
> I will patch it and send the patch. It will take me couple of days.
>
> Regards
> Darshan
>
> -----Original Message-----
> From: openssl-dev [mailto:[hidden email]] On Behalf
> Of Richard Levitte
> Sent: Thursday, March 23, 2017 7:31 PM
> To: [hidden email]
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
>
> I think that Matt is asking for example code that exhibits this leak.
> You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch.
>
> The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out.
>
> Cheers,
> Richard
>
> In message <[hidden email]> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" <[hidden email]> said:
>
> darshanmody> Matt,
> darshanmody>
> darshanmody> Below is the scenario.
> darshanmody>
> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain.
> darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app.
> darshanmody> 3. Connect client with certificates that server does not trust.
> darshanmody> 4. The connections from client to server fails
> darshanmody>
> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved.
> darshanmody>
> darshanmody> Hope this helps
> darshanmody>
> darshanmody> Thanks
> darshanmody> Darshan
> darshanmody>
> darshanmody> -----Original Message-----
> darshanmody> From: openssl-dev
> darshanmody> [mailto:[hidden email]]
> darshanmody> On Behalf Of Matt Caswell
> darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
> darshanmody> To: [hidden email]
> darshanmody> Subject: Re: [openssl-dev] Memory leak in application
> darshanmody> when we use ECDH
> darshanmody>
> darshanmody>
> darshanmody>
> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> darshanmody> > Can you further elaborate?
> darshanmody> >
> darshanmody> > What we did is to create a TLS connection and with
> darshanmody> > invalid certificates from the client and server on
> darshanmody> > verification would reject the certificate. The cipher
> darshanmody> > negotiated was ECDHE cipher between client and server.
> darshanmody> >
> darshanmody> > This was done with load (multiple while 1 script trying
> darshanmody> > to connect to server using invalid certificates and in
> darshanmody> > course of time the memory was increasing).
> darshanmody>
> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring.
> darshanmody>
> darshanmody> Matt
> darshanmody>
> darshanmody>
> darshanmody> >
> darshanmody> > Thanks Darshan
> darshanmody> >
> darshanmody> > -----Original Message----- From: openssl-dev
> darshanmody> > [mailto:[hidden email]] On Behalf Of
> darshanmody> > Matt Caswell
> darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To:
> darshanmody> > [hidden email]
> darshanmody> > Subject: Re: [openssl-dev] Memory leak in application
> darshanmody> > when we use ECDH
> darshanmody> >
> darshanmody> >
> darshanmody> >
> darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> darshanmody> >> Matt,
> darshanmody> >>
> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
> darshanmody> >> The leak started after we started using supporting EC
> darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
> darshanmody> >>
> darshanmody> >> The core dump shows  the string data of the far-end certificates.
> darshanmody> >> I cannot pin point  the code in openssl with this regard.
> darshanmody> >
> darshanmody> > Are you able to create a simple reproducer
> darshanmody> > demonstrating the problem with the callback?
> darshanmody> >
> darshanmody> > Matt
> darshanmody> >
> darshanmody> --
> darshanmody> openssl-dev mailing list
> darshanmody> To unsubscribe:
> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.
> darshanmody> op
> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQ
> darshanmody> w8
> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJ
> darshanmody> rK
> darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7s
> darshanmody> Qf _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e=
> darshanmody> --
> darshanmody> openssl-dev mailing list
> darshanmody> To unsubscribe:
> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.
> darshanmody> op
> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQ
> darshanmody> w8
> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJ
> darshanmody> rK
> darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm
> darshanmody> 8q 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
> darshanmody>
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZL
> ikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e=
> --
> openssl-dev mailing list
> To unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uU
> qvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e=
>
--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU&s=UUx2DxGuCVxrSicIa6MnjTprasDvG2yZURwlzaCG8bg&e= 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Loading...