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.

Attachment: srp_vfy.patch
Description: Binary data

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to