| Subject: | wrong verify callback can be invoked |
Hi,
Due to the way the verify callback is stored and invoked the wrong
callback can be accidently invoked.
Currently the verify callback is stored in a single hash
ssleay_ctx_verify_callbacks. Despite the name of the variable it can
store the CTX or the SSL verify callback.
The key for the hash is the address of the SSL* or SSL_CTX* object.
Bug#1:
As a minor bug the documentation states, that there can be only one
verify callback at a given time and that a proper solution would maybe
to to implement t as a has. This is wrong, the implementation with a
hash was obviously already done.
Bug#2:
The documentation states, that to prevent thread safety problems and
crashes on exit the callback should be reset to undef immediatly after
use. It doesn't say that anything else would cause a memory leak,
because Net::SSLeay never removes the callback itself from the hash,
even if the SSL object or context no longer exist. It would be nice to
remove it on Net::SSLeay::free or Net::SSLeay::CTX_free, but at least
one should document this behavior.
Which leads to Bug#3:
If the callback does not get removed but the CTX or SSL object is no
longer there it could happen, that a later constructed SSL* or CTX_SSL*
has the same pointer then the removed object and thus has the same key.
Even if you take the case, where you use verify callbacks on all CTX and
never on SSL* it could still could cause the wrong callback to call, if
the new SSL* matches an old SSL_CTX*, because it does not distinguish
between SSL* and SSL_CTX* based keys in the hash.
This could probably be resolved by having different hashes for SSL* and
SSL_CTX*.
I think a similar problem is with the password callback.
This is not a theoretical bug - it happened inside the IO::Socket::SSL
testsuite and caused strange sporadic errors in auto_verify_hostname.t
(with IO::Socket::SSL versions before 1.22)
Regards,
Steffen