Jeffrey Altman wrote:
I think we need to take a very close look at the situations when it is safe to replace memset(buf,0,sizeof(buf)) with OPENSSL_cleanse(buf,sizeof(buf)). It is clearly safe to make this replacement when the buffer is a stack allocation because there can be no future use of the data can take place. So there is no functional difference between a buffer filled with zeros and a buffer filled with garbage data.

However, this is not true for data structures that are located on the heap. In many cases OpenSSL provides functions that allow a buffer to be reused: XXX_init(), XXX_cleanup(), XXX_free(). This is true for several data structures. By replacing memset() with OPENSSL_cleanse() in the XXX_cleanup() function we have a problem when the data structure contains pointers to additional heap allocations. One case that I found a problem with is:

. application allocates X509_STORE_CTX and initializes it with X509_STORE_CTX_init(). . application calls X509_STORE_CTX_cleanup() which in turn calls OPENSSL_cleanse()

. application calls X509_STORE_CTX_free() which in turn calls X509_STORE_CTX_cleanup().
This results in an exception because the ex_data field is a struct that contains pointers to memory allocations. Due to the OPENSSL_cleanse() call the pointer values are garbage non-NULL values. An attempt is made to free the memory. This causes an exception.

This is going to require careful examination to find all of the places where pointers need to be set to NULL after or during a cleanse operation.
OPENSSL_cleanse() should be followed by a memset()? OTOH, if the result of memset() is used, then it can't be optimised away...

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]


Reply via email to