On Thu, 23 Oct 2014, Martijn van Duren wrote:
> Hello misc@,
>
> I'm currently trying to write a library that heavily relies on
> libcrypto. Because I don't want applications linking to it, to have to
> call OpenSSL_add_all_algorithms, for convenience, I added those calls to
> the appropriate places in my library. Because of this nature, the
> function is called multiple times, and even if I shielded it within my
> library it could still be called outside of it by an application using
> my library.
> On AMD64 (OpenBSD 5.5-stable) this hasn't given me any problems yet, but
> as soon as I run my code on i386 (5.6-current) it crashes with the
> following trace:
> #0 obj_name_LHASH_COMP (arg1=0x0, arg2=0x857b7630) at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:97
> #1 0x0e91190c in getrn (lh=0x867d0380, data=0x857b7630, rhash=Variable
> "rhash" is not available.
> ) at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:419 #2
> 0x0e911c92 in lh_insert (lh=0x867d0380, data=0x857b7630) at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/lhash/lhash.c:192
> #3 0x0e8a0852 in OBJ_NAME_add (name=0x2e800aac "aes-256-cfb", type=2,
> data=0x2e815360 "\001")
> at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/objects/o_names.c:181
> #4 0x0e8a0149 in EVP_add_cipher (c=0x2e815360) at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/names.c:80
> #5 0x0e8384f3 in OpenSSL_add_all_ciphers () at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_allc.c:183
> #6 0x0e8357bc in OPENSSL_add_all_algorithms_noconf () at
> /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/evp/c_all.c:76
>
> I'm aware that the OpenSSL_add_all_algorithms(3) says:
> A typical application will call OpenSSL_add_all_algorithms() initially
> and EVP_cleanup() before exiting.
> but it doesn't explicitly says that it can only be called ones without
> causing problems.
>
> Could anyone tell me if this kind of use of this function is the
> undefined behaviour area that I should avoid or if this is a bug? If it
> is grey area that should be avoided, what is the recommended way to
> initialise ciphers and digests from within the library without risking
> crashes from initialization from within an application? I do use
> EVP_get_{cipher,digest}bynid(3), so all ciphers and digests need to be
> available.
Something strange seems to be happening here.
As far as I can tell, OpenSSL_add_all_algorithms() should be safe to call
multiple times and I'm not able to reproduce the crash on
OpenBSD/i386-current (for performance reasons you probably want to avoid
doing this whenver you can, but as far as I can tell nothing should prevent
it from working). However, keep in mind that most of these functions are not
thread safe.
obj_name_LHASH_COMP(arg1=0x0, arg2=0x857b7630) means that we've already ended
up with an entry in the LHASH that has a NULL data value (not that we're
trying to insert one). The only insert in the name_lh has an explicit NULL
check and there should be no other way (short of manually inserting a NULL
value or changing an existing data pointer to NULL) to trigger this.
If you can provide a minimal reproducable test case I can attempt to dig
further.
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
