SRP VBASE stuff still leaking memory

Michel michel.sales at free.fr
Mon Dec 7 15:42:11 UTC 2015


Hi,

 

Following my previous mail, here attached is an updated patch against 1.02e
to fix the SRP VBASE memory leaks.
I understand the VBASE stuff is not a TLS critical component, but it is part
of the SRP command line tool.

NB : it's a pity that the base64 encoding is not the same than the one use
elsewhere by OpenSSL.

 

Regards,

 

Michel.

 

De : openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de
Michel
Envoyé : lundi 23 mars 2015 12:10
À : openssl-dev at openssl.org
Objet : [openssl-dev] SRP memory leaks and more leaks

 

Hi,

 

Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c
.

 

1)  The first kind was due to bad use of OpenSSL 'stack' code and cumbersome
/ confusing names of structure / functions.

In this case, leaks occurs when loading a verifier file containing 'index'
lines.

Two structures are used : SRP_gN and SRP_gN_cache.

And unfortunatly, the SRP_gN_free function free a SRP_gN_cache structure.

The SRP_VBASE_free() function, line 276, should call :

sk_SRP_gN_cache_pop_free(vb->gN_cache, SRP_gN_cache_free);

instead of :

sk_SRP_gN_cache_free(vb->gN_cache);

And consequently the SRP_gN_cache_free() function, lines 305-312, has to
move before SRP_VBASE_free()

 

The attached patch solve this kind of leaks.

 

2) When simulating a 'fake user' as per RFC 5054, § '2.5.1.3.  Unknown SRP
User Name',

the SRP_VBASE_get_by_user() function returns a newly allocated SRP_user_pwd
structure whose adress is not kept anywhere else.

So, the caller should free it later, but from outside the function, there is
no way to distinguish between 'fake users' and real ones 

which are managed and freed throught the use of the SRP_VBASE structure /
functions.

 

I am afraid there is no other solution than changing the
SRP_VBASE_get_by_user() function prototype.

 

It is better I do not share here my opinion about the comments below : 

/* need to check whether there are memory leaks */, s_server.c line 433

or :

/* there may be still some leaks to fix, 
 */ srp_vfy.c line 449

>:(

 

Hope this will save time to other users,

 

Michel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20151207/81d13417/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: srp_vfy-1.0.2e.patch
Type: application/octet-stream
Size: 3035 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20151207/81d13417/attachment.obj>


More information about the openssl-bugs-mod mailing list