[openssl.org #2363] bug: memory allocated by DH_new() may never be free()ed
libcrypto.so.0.9.8`CRYPTO_new_ex_data+0x38 libcrypto.so.0.9.8`DH_new_method+0xcc libcrypto.so.0.9.8`DH_new+0x1d openssl_test.so`run+0x2c main+0x7d libumem.so.1`umem_cache_alloc_debug+0x144 libumem.so.1`umem_cache_alloc+0x19a libumem.so.1`umem_alloc+0xcd libumem.so.1`malloc+0x2a libcrypto.so.0.9.8`default_malloc_ex+0x21 libcrypto.so.0.9.8`CRYPTO_malloc+0x5d libcrypto.so.0.9.8`lh_new+0x28 libcrypto.so.0.9.8`ex_data_check+0x4d libcrypto.so.0.9.8`def_get_class+0x29 libcrypto.so.0.9.8`int_new_ex_data+0x20 libcrypto.so.0.9.8`CRYPTO_new_ex_data+0x38 libcrypto.so.0.9.8`DH_new_method+0xcc libcrypto.so.0.9.8`DH_new+0x1d openssl_test.so`run+0x2c main+0x7d In order to actually find the symbols corresponding to the addresses in the stack we must ran the program twice: 1) Get the stack of the leaks (::bufctl_audit) 2) Run the program in mdb putting a breakpoint on the dlclose call in main. Because the library is mapped (always?) in the same place the symbols for the addresses can be found by using ::dis on each address, thus rebuilding the stack. -- Jan Pechanec http://blogs.sun.com/janp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2325] memory corruption after libssl is unloaded from memory
hi, this has been shortly discussed on the OpenSSL dev list (sent on Aug 10, 2010). I understand that given the conditions needed to reproduce this error it will not be a priority but we believe it is a bug worth fixing so we would like to document it in the OpenSSL RT. Thank you. the initial email follows: hi, when libssl is linked against modules that can be dlopen()ed and dlclose()d multiple times during the process life time, we hit a memory corruption where the hash table built in memory for the error strings references SSL strings in the address range previously occupied by libssl. The behaviour depends on what other shared objects are loaded in between and when etc. but in general the hash table can end up referencing some wrong memory. Verified with 0.9.8e, 0.9.8o, 1.0.0a. For 1.0.0a, a modification of the attached program might be needed, details in the code. we hit the problem on OpenSolaris where Apache started to crash when loading mod_ssl. It loads all built-in engines and on Solaris we end up in the PKCS#11 engine loading libpkcs11.so.1 with other modules being dlopen()ed and some of them are linked against libssl. We however believe this is a generic problem and other systems could be hit by that sooner or later. the attached program simulates the problem using dlopen() directly on libssl and can be built on FreeBSD (we used 7.2) and OpenSolaris. It also contains instructions on how to simulate the problem on Linux (modifications needed depending on the distro) as well. To show the problem we mmap() some anonymous memory with the PROT_NONE flag right after dlclose() on libssl but before another dlopen() is called on it. The next SSL_load_error_strings() causes a crash then: $ gcc -g -lcrypto ssl-dlopen-crash.c $ ./a.out Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... Opening libssl.so... Initializing with SSL_load_error_strings... Segmentation Fault (core dumped) $ mdb core mdb: core file data for mapping at fe84f000 not saved: Bad address Loading modules: [ libuutil.so.1 ld.so.1 ] $c libcrypto.so.0.9.8`err_cmp+6(fecb70b0, 8047758, 8047748, feeda26e) libcrypto.so.0.9.8`getrn+0x7d(8061558, 8047758, 804770c, 110) libcrypto.so.0.9.8`lh_retrieve+0x1e(8061558, 8047758, fef4b408, 12a) libcrypto.so.0.9.8`int_err_get_item+0x51(8047758, fef69000, 8047768, feedd808) libcrypto.so.0.9.8`ERR_func_error_string+0x47(14064000, fef69000, 8047788, fe82cff8) libssl.so.0.9.8`ERR_load_SSL_strings+0x23(8051270) libssl.so.0.9.8`SSL_load_error_strings+0x1d(fe822330, feac0b80, 80477cc, 80511a9, fed2, 80511ba) testssl+0x83(fed2, 80511ba, 80612ec, 80477ac, 80477cc, 80511fa) main+0x5f(1, 80477f0, 80477f8) _start+0x80(1, 8047900, 0, 8047908, 8047921, 8047943) we think that the proper fix is to make a copy of those strings when bulding the hash table. Using ERR_free_strings() is not a solution since that frees all the strings, also those needed by libcrypto. A new function in the libssl's fini section removing only SSL strings would also probably solve the problem. the workaround is simple. Either use LD_PRELOAD on libssl to lock it in the memory: $ LD_PRELOAD=/lib/libssl.so.0.9.8 ./a.out Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... or build the library with -znodelete. The linker on Solaris supports this option. This ensures that libssl is never unloaded. I think we should file a bug in the RT. Is there anything else we should provide? thanks, Jan. -- Jan Pechanec http://blogs.sun.com/janp /* * Demo for the SSL memory corruption bug. The problem is if libssl is * dlopen()ed, SSL error strings loaded, and the library is dlclose()d then. The * hash string table built in memory still uses references to the memory * previously occupied by libssl since there is no clean-up. If we map * non-accessible memory to that address range, the next * SSL_load_error_strings() causes a SIGSEGV. * * Tested with 0.9.8e, 0.9.8o, and 1.0.0a. See a comment with mmap() below in * the code if you want to run this with 1.0.0. * * Compile: * * $ gcc -g -lcrypto ssl-dlopen-crash.c * * Stack trace on FreeBSD 7.2: * #0 0x2813da5a in ERR_unload_strings () from /lib/libcrypto.so.5 * #1 0x2818393e in lh_retrieve () from /lib/libcrypto.so.5 * #2 0x2813e38e in ERR_get_implementation () from /lib/libcrypto.so.5 * #3 0x2813dd77 in ERR_func_error_string () from /lib/libcrypto.so.5 * #4 0x2844e1c0 in ERR_load_SSL_strings () from /usr/lib/libssl.so * #5 0x2844e18c in SSL_load_error_strings () from /usr/lib/libssl.so * #6 0x080488f4 in testssl () at ssl-dlopen-freebsd.c:53 * #7 0x08048a11 in main () at ssl-dlopen-freebsd.c:113 * * Stack trace on OpenSolaris: * libcrypto.so.0.9.8`err_cmp+6(fecb70b0, 804775c, 804774c
Re: memory corruption after libssl is unloaded from memory
On Fri, 13 Aug 2010, Darryl Miles wrote: While it is possible to make a Valgrind clean (as in memory leaks) executable, that loads OpenSSL DSO/DLLs exactly once during the executable lifetime. I'm not sure it has ever been a feasible goal to make OpenSSL DSO/DLLs able to be unloaded (with the aim of subsequently loading). Let alone a goal that this function of dynamic-linking is claimed to be supported by OpenSSL in its documentation. hi Darryl, the problem is that shared modules are loaded and unloaded (PAM, PKCS#11 to name two of existing frameworks that work dynamically with shared modules) and SSL is used more and more often. So, libssl can be just linked against such modules, ending up being loaded and unloaded as a side effect. That's why we hit it just recently, a new provider in the Solaris Crypto Frameowork uses libssl. As said in my first email, I believe this problem will become more and more frequent in the future. I won't dispute it is a worthy goal of any DSO to be compliant with use of dlunload() but I see wider issues needing resolution at the same time. For a start doesn't there need to be a mechanism where a superior-executable can ask the DSO if it is ready to unload, maybe there are hooks in dlunload() to inquire on this. dlopen/dlclose are part of the UNIX spec and there is nothing like that. It could be fixed by having a function that unloads just SSL strings and put it into the .fini section of the shared object (or even libssl). Unfortunately, such function does not exist in libcrypto, there is just one generic ERR_free_strings() that unloads all the strings aside from those in SSL, including those that might be still used by libcrypto consumers. This ignores the nice to have features of: * Exposed reference counters for dlopen to the DSO itself * Ability for a DSO to say, you can never unload me the latter was mentioned in my 1st email as a linker option in Solaris (and it may be a Solaris only thing) but that's still just a workaround. There is nothing like that in the dlopen/dlclose API. Maybe these problem are already solved on the platforms you are working with (FreeBSD / OpenSolaris) and I'd certainly like to hear about that. As glibc/linux takes a somewhat different stance. I'm not sure what stance you mean here? The problem can be reproduced on Linux as well. thanks, Jan. -- Jan Pechanec http://blogs.sun.com/janp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: memory corruption after libssl is unloaded from memory
On Fri, 13 Aug 2010, Ladar Levison wrote:
I was able to dynamically load OpenSSL, initialize it, unload it, and then
reload it back up again using your example along with some of my cleanup code.
Since I don't know your specific use case, I don't know if something like this
will work for you, but figured I'd send it along just in case. Here's the
console output:
[la...@magma Desktop]$ gcc -std=gnu99 -g -ldl ssl-dlopen-crash.c 21 ; /a.out
; valgrind --tool=memcheck --leak-check=yes ./a.out
Opening libssl.so...
Initializing with OpenSSL...
Closing libssl.so...
Opening libssl.so...
Initializing with OpenSSL...
Closing libssl.so...
==21089== Memcheck, a memory error detector
==21089== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21089== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21089== Command: ./a.out
==21089==
Opening libssl.so...
Initializing with OpenSSL...
Closing libssl.so...
Opening libssl.so...
Initializing with OpenSSL...
Closing libssl.so...
==21089==
==21089== HEAP SUMMARY:
==21089== in use at exit: 0 bytes in 0 blocks
==21089== total heap usage: 5,293 allocs, 5,293 frees, 207,568 bytes
allocated
==21089==
==21089== All heap blocks were freed -- no leaks are possible
==21089==
==21089== For counts of detected and suppressed errors, rerun with: -v
==21089== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from 9)
And a variant of the cleanup function I took from my actual application:
void ssl_stop(void) {
if (ssl_locks != NULL) {
ERR_remove_state_d(0);
COMP_zlib_cleanup_d();
CONF_modules_unload_d(1);
OBJ_cleanup_d();
OBJ_NAME_cleanup_d(-1);
BIO_sock_cleanup_d();
EVP_cleanup_d();
ENGINE_cleanup_d();
CRYPTO_cleanup_all_ex_data_d();
ERR_free_strings_d();
hi Ladar, this frees all the strings, not just SSL strings
referenced from the hash table created by the libcrypto code. So, if
some code will use some libcrypto error strings after unloading libssl
and calling this stop function, I believe we may end up in a similar
situation and crash again.
Jan.
--
Jan Pechanec
http://blogs.sun.com/janp
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
memory corruption after libssl is unloaded from memory
hi, when libssl is linked against modules that can be dlopen()ed and dlclose()d multiple times during the process life time, we hit a memory corruption where the hash table built in memory for the error strings references SSL strings in the address range previously occupied by libssl. The behaviour depends on what other shared objects are loaded in between and when etc. but in general the hash table can end up referencing some wrong memory. Verified with 0.9.8e, 0.9.8o, 1.0.0a. For 1.0.0a, a modification of the attached program might be needed, details in the code. we hit the problem on OpenSolaris where Apache started to crash when loading mod_ssl. It loads all built-in engines and on Solaris we end up in the PKCS#11 engine loading libpkcs11.so.1 with other modules being dlopen()ed and some of them are linked against libssl. We however believe this is a generic problem and other systems could be hit by that sooner or later. the attached program simulates the problem using dlopen() directly on libssl and can be built on FreeBSD (we used 7.2) and OpenSolaris. It also contains instructions on how to simulate the problem on Linux (modifications needed depending on the distro) as well. To show the problem we mmap() some anonymous memory with the PROT_NONE flag right after dlclose() on libssl but before another dlopen() is called on it. The next SSL_load_error_strings() causes a crash then: $ gcc -g -lcrypto ssl-dlopen-crash.c $ ./a.out Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... Opening libssl.so... Initializing with SSL_load_error_strings... Segmentation Fault (core dumped) $ mdb core mdb: core file data for mapping at fe84f000 not saved: Bad address Loading modules: [ libuutil.so.1 ld.so.1 ] $c libcrypto.so.0.9.8`err_cmp+6(fecb70b0, 8047758, 8047748, feeda26e) libcrypto.so.0.9.8`getrn+0x7d(8061558, 8047758, 804770c, 110) libcrypto.so.0.9.8`lh_retrieve+0x1e(8061558, 8047758, fef4b408, 12a) libcrypto.so.0.9.8`int_err_get_item+0x51(8047758, fef69000, 8047768, feedd808) libcrypto.so.0.9.8`ERR_func_error_string+0x47(14064000, fef69000, 8047788, fe82cff8) libssl.so.0.9.8`ERR_load_SSL_strings+0x23(8051270) libssl.so.0.9.8`SSL_load_error_strings+0x1d(fe822330, feac0b80, 80477cc, 80511a9, fed2, 80511ba) testssl+0x83(fed2, 80511ba, 80612ec, 80477ac, 80477cc, 80511fa) main+0x5f(1, 80477f0, 80477f8) _start+0x80(1, 8047900, 0, 8047908, 8047921, 8047943) we think that the proper fix is to make a copy of those strings when bulding the hash table. Using ERR_free_strings() is not a solution since that frees all the strings, also those needed by libcrypto. A new function in the libssl's fini section removing only SSL strings would also probably solve the problem. the workaround is simple. Either use LD_PRELOAD on libssl to lock it in the memory: $ LD_PRELOAD=/lib/libssl.so.0.9.8 ./a.out Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... Opening libssl.so... Initializing with SSL_load_error_strings... Closing libssl.so... or build the library with -znodelete. The linker on Solaris supports this option. This ensures that libssl is never unloaded. I think we should file a bug in the RT. Is there anything else we should provide? thanks, Jan. -- Jan Pechanec http://blogs.sun.com/janp /* * Demo for the SSL memory corruption bug. The problem is if libssl is * dlopen()ed, SSL error strings loaded, and the library is dlclose()d then. The * hash string table built in memory still uses references to the memory * previously occupied by libssl since there is no clean-up. If we map * non-accessible memory to that address range, the next * SSL_load_error_strings() causes a SIGSEGV. * * Tested with 0.9.8e, 0.9.8o, and 1.0.0a. See a comment with mmap() below in * the code if you want to run this with 1.0.0. * * Compile: * * $ gcc -g -lcrypto ssl-dlopen-crash.c * * Stack trace on FreeBSD 7.2: * #0 0x2813da5a in ERR_unload_strings () from /lib/libcrypto.so.5 * #1 0x2818393e in lh_retrieve () from /lib/libcrypto.so.5 * #2 0x2813e38e in ERR_get_implementation () from /lib/libcrypto.so.5 * #3 0x2813dd77 in ERR_func_error_string () from /lib/libcrypto.so.5 * #4 0x2844e1c0 in ERR_load_SSL_strings () from /usr/lib/libssl.so * #5 0x2844e18c in SSL_load_error_strings () from /usr/lib/libssl.so * #6 0x080488f4 in testssl () at ssl-dlopen-freebsd.c:53 * #7 0x08048a11 in main () at ssl-dlopen-freebsd.c:113 * * Stack trace on OpenSolaris: * libcrypto.so.0.9.8`err_cmp+6(fecb70b0, 804775c, 804774c, feeda26e) * libcrypto.so.0.9.8`getrn+0x7d(8061228, 804775c, 8047710, 110) * libcrypto.so.0.9.8`lh_retrieve+0x1e(8061228, 804775c, fef4b408, 12a) * libcrypto.so.0.9.8`int_err_get_item+0x51(804775c, fef69000, 804776c, feedd808) * libcrypto.so.0.9.8`ERR_func_error_string+0x47(14064000, fef69000, 804778c
Re: NO_FORK problem in speed.c
On Wed, 3 Mar 2010, kai_yang2008 wrote: Hi All, I have build the new openssl-0.9.8m on HPUX platform, it sees that the openssl-0.9.8m don't support the command line openssl speed -multi 2. And I have traced to the source code of speed.c. But it work fines with the openssl-0.9.8l. The reason is that : #if defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_MACINTOSH_CLASSIC) || defined(OPENSSL_SYS_OS2) || defined(OPENSSL_SYS_NETWARE) # define NO_FORK 1 #elif HAVE_FORK # undef NO_FORK #else # define NO_FORK 1 #endif But my hpux platform support fork, so if I want to support the option multi , what should I do? Anybody has some ideas? Thanks! we hit that as well and filed: http://rt.openssl.org/index.html?q=2183 as a workaround, add -DHAVE_FORK to the field for compiler options for your architecture in Configure and reconfigure/rebuild. Or, just put #define HAVE_FORK 1 after the endif and rebuild. J. -- Jan Pechanec http://blogs.sun.com/janp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2183] 0.9.8m broke -multi option in openssl(1) on unix(-like) systems
commit 18494 changed how HAVE_FORK is dealt with in speed.c. The original submitter (http://www.mail-archive.com/openssl-dev@openssl.org/msg26278.html) correctly stated that HAVE_FORK should be defined by the configure script but wrongly assumed that it really was. it's not the case. Maybe autoconf does that, I'm not sure about that. Anyway, the outcome of the change is this on any unix or unix-like system because HAVE_FORK is not defined: $ cd openssl-0.9.8m $ LD_LIBRARY_PATH=. apps/openssl speed rsa -multi 4 Error: bad option or value Available values: snip Available options: -elapsedmeasure time in real time instead of CPU user time. -engine e use engine e, possibly a hardware device. -evp e use EVP e. -decrypttime decryption instead of encryption (only EVP). -mr produce machine readable output. as you can see, multi is ifdef'ed out from the helper string as well. I'd send a patch but I'm not sure how you would like to fix it. Use -DHAVE_FORK for all apropriate architectures in the Configure script? Or do another fix in the speed.c source code? I guess the former aproach might be better, fixing it in speed.c could bring the problem back again, just for yet another architecture not specified in the #ifdef. cheers, Jan. -- Jan Pechanec http://blogs.sun.com/janp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2124] memory mismanagement in OpenSSL (patch included against 0.9.8l)
On Tue, 8 Dec 2009, Jan Pechanec wrote: sorry, forgot to include a link to the OpenSolaris bugster: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6441083 with an explanation of a person who reported the problem. J. hi, there are some places where functions allocating memory are not checked against NULL, or are checked too late (LHASH code). We run some tests with libumem(3lib) and mtbf=5000 (mean time between failure) in UMEM_DEBUG, simulating occasional memory shortages and that was causing OpenSSL to crash. the changes have been used here at Sun internally for 2 years against 0.9.8a. Attached is a patch generated against 0.9.8l. make test passes on the changed code after rebuilding it. thanks, Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: adding a new NID
On Mon, 25 May 2009, rakesh aggarwal wrote: Hi, i am new to openssl and trying to add support for CTR mode in AES. i dont know what i am doing is correct or not? I made some changes based on my understanding but i want to cross verify. For adding the above support, first i need to add SN_LN,NID, OBJ etc for CTR mode just like AES in CBC (SN_aes_128_cbc,LN_aes_128_cbc,..) mode. For adding the mentioned (SN, LN, NID, OBJ), i did the following change. it's easier to do othat dynamically. See pk11_add_NID() here, for example: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/openssl/crypto/engine/hw_pk11.c -- Jan Pechanec
Re: AES counter mode support missing from EVP
On Tue, 29 Apr 2008, Dr. Stephen Henson wrote: the problem is that now one can't offload AES counter modes to the engine unless the application itself specifies its own EVP functions and structures. However, even then, counter mode IDs and names are missing from obj*.h files so functions like OBJ_nid2sn() crash. That happens with openssl engine -c, for example. It is enough to add following 3 lines to objects.txt so that AES counter mode can be offloaded to the engine using the workaround mentioned: : AES-128-CTR : aes-128-ctr : AES-192-CTR : aes-192-ctr : AES-256-CTR : aes-256-ctr It would be better is standard OIDs existed for these modes and those were added instead. You can create OIDs dynamically with OBJ_create() too, that should work without the need to modify OpenSSL at all. aha, thanks, that's a good idea. It seems to me that I can't use OBJ_create() without providing an OID but ASN1_OBJECT_create() + OBJ_add_object() is OK for me and no phony OIDs are used then. J. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
AES counter mode support missing from EVP
hi, I can see that EVP API doesn't support AES counter mode. My guess is that it might be because of the fact that current EVP API doesn't have a parameter for counter length. Is that the reason or is it something else? the problem is that now one can't offload AES counter modes to the engine unless the application itself specifies its own EVP functions and structures. However, even then, counter mode IDs and names are missing from obj*.h files so functions like OBJ_nid2sn() crash. That happens with openssl engine -c, for example. It is enough to add following 3 lines to objects.txt so that AES counter mode can be offloaded to the engine using the workaround mentioned: : AES-128-CTR : aes-128-ctr : AES-192-CTR : aes-192-ctr : AES-256-CTR : aes-256-ctr I'm happy to file a bug and post a patch but I'd like to know if there is anything I'm missing. I searched through the archives but I didn't see any discussion related to the AES counter mode with regard to EVP API. and to put it to some context - SSH protocol always uses 128 bits long counter for AES counter mode so that's why OpenSSH can work with its own EVP functions for this mode. However, above mentioned changes are needed so that CTR mode can be offloaded to the engine. thanks, Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 wrapper around OpenSSL
On Mon, 19 Nov 2007, Alon Bar-Lev wrote: On Nov 19, 2007 10:52 PM, Steven Bade [EMAIL PROTECTED] wrote: I believe that Sun contributed a pretty robust PKCS#11 engine for openSSL. It support a single static (compile time) provider, and even does not the idea is that if you have pkcs#11 engine then everything else you get through Crypto Framework to which you can connect hw providers. login to the token... there's a preliminary patch for that on blogs.sun.com/janp I don't understand why it is packed as a patch and not as separate shared library... crypto with a hole problem. Some countries didn't allow delivery of such systems. I'm not sure if that's still the case, at least Solaris (s10u4) is now shipped with the strong crypto -- keys above 128 bits etc. That was the same problem -- not US export but import in some coutries until recently. Anyway, from reading the code this is not really usable. correct, not with the current bits in Solaris (I guess we talk about accesing tokens). We plan to work on that but it's not top priority for now. cheers, Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1564] bug: FIPS module can't be built on Solaris
building the fips module ends with a tricky error: /usr/ccs/bin/ld: illegal option -- n usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit ... ... the problem is that in general Solaris's echo's don't have '-n' so this is a problem in fips-1.0/Makefile: fipscanister.o: fips_start.o $(LIBOBJ) $(FIPS_OBJ_LISTS) fips_end.o @FIPS_BN_ASM=`for i in $(BN_ASM) ; do echo -n ../crypto/bn/$$i ; done`; \ not sure what is the best fix here, whether test for Solaris and set it to printf, or to replace it with printf right away, or something different. After the fix the module builds fine. For more information about echo's in Solaris, see: man -M /usr/man echo regards, Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HMAC_Final()/tls1_P_hash() problem with PKCS#11
On Sun, 24 Jun 2007, Nanno Langstraat wrote: OpenSSL: ctx init, dgst init/update/final, ctx cleanup PKCS#11: dgst init/update/final where some memory is allocated in dgst init and freed in ctx cleanup (not dgst final) in OpenSSL, but allocated in dgst init and freed in dgst final in PKCS#11 tokens. So, if you don't call xyzFinal() it's fine wrt memory usage in OpenSSL but it's a problem in PKCS#11 app. it's usually not a problem because when there is digest init there is also digest final some time after that. However, not for HMAC computation. This sounds almost exactly why I added the SHA1_Drop() function to the save/load SHA1 state patch, discussed on this list a week ago. (or SHA1_Abandon(), SHA1_Cancel(), whatever name you prefer for the function) Even though it's a no-op for the current SHA1 C implementation, it creates a clean hook to deallocate any memory without having to do an unnecessary Final() calculation. hi Nanno, I don't think it's very similar. The problem is that one can't change PKCS#11 API. EVP_MD_CTX_cleanup() has its counterpart in the engine but not in the PKCS#11 token. the only way how to deallocate memory in the token allocated in C_DigestInit() is to call C_DigestFinal(), which means unless app calls EVP_DigestFinal() there is a leak. Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
HMAC_Final()/tls1_P_hash() problem with PKCS#11
hi all, I've been working on several issues involving PKCS#11 engine we ship with OpenSSL as part of Solaris and hit a problem of memory leakage when the engine was used. The problem can't be attributed strictly to OpenSSL or to the engine. The problem is how digests work: OpenSSL: ctx init, dgst init/update/final, ctx cleanup PKCS#11: dgst init/update/final where some memory is allocated in dgst init and freed in ctx cleanup (not dgst final) in OpenSSL, but allocated in dgst init and freed in dgst final in PKCS#11 tokens. So, if you don't call xyzFinal() it's fine wrt memory usage in OpenSSL but it's a problem in PKCS#11 app. it's usually not a problem because when there is digest init there is also digest final some time after that. However, not for HMAC computation. Probably due to the way how TLS PRF function is processed, ipad and opad helper digest contexts are not finalized in HMAC_Final(). This fact is used in tls1_P_hash() where HMAC_Init_ex()'s are called in reinit mode, reusing already used i/o_ctx's. This is not a problem for OpenSSL since all ctx's are cleaned in HMAC_CTX_cleanup() in the very end but it's a problem on PKCS#11 side because there is no EVP_MD_CTX_cleanup() equivalent. Yes, cleanup()-like function is called on the engine side but the only way would be to call PKCS#11's Final()-like function again. So, Final()-like function would be called twice in most cases which is not expected; the session doesn't exist after the first C_DigestFinal(). when I manually call EVP_DigestFinal_ex()'s for i/o_ctx's in the tls1_P_hash() loop for the last chunk it gets rid of those memory leaks. This is more a hack than anything else because it doesn't solve the problem when HMAC functions are directly used by an application (that uses the engine). Fixing HMAC_Final() with finalizing both pad contexts and then rewriting the loop using EVP_MD_CTX_copy_ex()'s calls on temp ctx's doesn't help either because due too excessive copy operations every SSL handshake becomes several tens of percent slower. And the solution itself is not nice either. what would be the best solution on OpenSSL side? Another approach could be that several EVP_DigestXXX()'s could be used instead of HMAC_Final() (or, eh, grouped into HMAC_Final2) and then HMAC_Final() could be changed but I would like to fix it the same way as in OpenSSL - if you decide to fix it of course. Having separate patches is too painful. thanks, Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1528] bug/typo: TLS_DEBUG section prints pre-master instead of master
in t1_enc.c, there is:
#ifdef TLS_DEBUG
printf(client random\n);
{ int z; for (z=0; zSSL3_RANDOM_SIZE; z++)
printf(%02X%c,s-s3-client_random[z],((z+1)%16)?' ':'\n'); }
printf(server random\n);
{ int z; for (z=0; zSSL3_RANDOM_SIZE; z++)
printf(%02X%c,s-s3-server_random[z],((z+1)%16)?' ':'\n'); }
printf(pre-master\n);
{ int z; for (z=0; zs-session-master_key_length; z++)
printf(%02X%c,s-session-master_key[z],((z+1)%16)?' ':'\n'); }
#endif
which uses pre-master\n in printf(). However,
s-session-master_key is a master key.
Jan.
--
Jan Pechanec
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1529] doc: AES support not documented in enc(1) manual page
this is 0.9.8e, and enc(1) command can do AES: -aes-128-cbc -aes-128-cfb -aes-128-cfb1 -aes-128-cfb8 -aes-128-ecb -aes-128-ofb -aes128 however, it's not documented in enc(1) manual page. Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1530] bug/typo: incorrent comment in s3_srvr.c
0.9.8e, s3_srvr.c claims this in a comment: * s-tmp.new_cipher- the new cipher to use. it should read s-s3-tmp.new_cipher ... Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1531] typo: 'rouines' should read 'routines' in all Copyright sections
as per $subj: * The word 'cryptographic' can be left out if the rouines from the library it seems to be everywhere: janp:ananke:/export/openssl$ ggrep -e rouines -R openssl-0.9.8e/* | wc -l 541 -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1438] BUG: extra backslash in openssl macros (version 0.9.8d)
hi, this is bug ID 6368841 on OpenSolaris.Org: http://bugs.opensolaris.org/view_bug.do?bug_id=6368841 following macros have a backslash on the last line of the macro (line numbers are where the macro starts), checked against OpenSSL 0.9.8d release: ASN1_ITEM_start (usr/src/common/openssl/crypto/asn1/asn1t.h), line 99 BLOCK_CIPHER_ecb_loop (usr/src/common/openssl/crypto/evp/evp_locl.h), 63 idea_mul (usr/src/common/openssl/crypto/idea/idea_lcl.h), 62 IMPLEMENT_PEM_read_fp (usr/src/common/openssl/crypto/pem/pem.h), 220 these backslashes are unnecessary, and they're a maintenance hazard. If somebody puts non-null text on the following line, it will get sucked into the macro. thanks, Jan. -- Jan Pechanec Software Engineer Security Technologies | OS Hardening __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1354] patch: SSL_SESSION_get_time.pod mentions SSL_SESSION_get_timeout twice
hi, SSL_SESSION_get_time(3) mentions SSL_SESSION_get_timeout twice in NAME section instead of SSL_SESSION_set_timeout. Patch included. Jan. -- Jan Pechanec Software Engineer Security Technologies | OS Hardening __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1355] patch: bug in CONF_modules_free.pod
hi, man page for CONF_modules_free mistakenly mentions CONF_modules_load instead of CONF_modules_finish (CONF_modules_load has its own manual page). Patch attached. checked against snapshot from 2006-06-20. Jan. -- Jan Pechanec __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
