Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b
114 views
Skip to first unread message
Dan Kegel via RT
Jun 3, 2016, 1:06:36 PM6/3/16
to
The commit
From: "Dr. Stephen Henson" <st...@openssl.org>
Date: Fri, 1 Apr 2011 15:46:03 +0000
Subject: [PATCH] Add additional OPENSSL_init() handling add dummy call to
(hopefully) ensure OPENSSL_init() is always linked into an application.
https://github.com/openssl/openssl/commit/c4acfb1fd049f52fb074b103be01cab5cf5c04f8
seems to have broken CRYPTO_set_mem_functions. After this commit,
CRYPTO_set_mem_functions() calls OPENSSL_init(), which calls
CRYPTO_malloc(), which sets `allow_customize` to 0, which is then
checked by CRYPTO_set_mem_functions(), which then returns without
doing anything.
See also earlier reports
http://openssl.6102.n7.nabble.com/CRYPTO-set-mem-functions-Doesn-t-Work-in-Version-1-0-1b-td46745.html
http://bugs.python.org/msg191610
The death test program
#include <stdio.h>
#include <stdlib.h>
#include <openssl/ssl.h>
void * my_alloc(size_t n) { abort(); }
void my_free(void *p) { abort(); }
void * my_realloc(void *p, size_t n) { abort(); }
int main(int argc, const char **argv)
{
const SSL_METHOD *method;
SSL_CTX *ctx;
CRYPTO_set_mem_functions(my_alloc, my_realloc, my_free);
SSL_library_init();
method = SSLv23_client_method();
ctx = SSL_CTX_new(method);
printf("Got ctx %p\n", ctx);
return 0;
}
aborts as expected on Ubuntu 10.04 with openssl0.9.8k, but blithely
prints a ctx with openssl 1.0.*.
The bug is probably not present in openssl-1.1.0-pre5, as the
offending code was removed by
https://github.com/openssl/openssl/commit/bbd86bf5424a611cb6b77a3a17fc522931c4dcb8
but a fix for 1.0.0 and 1.0.1 would be much appreciated.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
From: "Dr. Stephen Henson" <st...@openssl.org>
Date: Fri, 1 Apr 2011 15:46:03 +0000
Subject: [PATCH] Add additional OPENSSL_init() handling add dummy call to
(hopefully) ensure OPENSSL_init() is always linked into an application.
https://github.com/openssl/openssl/commit/c4acfb1fd049f52fb074b103be01cab5cf5c04f8
seems to have broken CRYPTO_set_mem_functions. After this commit,
CRYPTO_set_mem_functions() calls OPENSSL_init(), which calls
CRYPTO_malloc(), which sets `allow_customize` to 0, which is then
checked by CRYPTO_set_mem_functions(), which then returns without
doing anything.
See also earlier reports
http://openssl.6102.n7.nabble.com/CRYPTO-set-mem-functions-Doesn-t-Work-in-Version-1-0-1b-td46745.html
http://bugs.python.org/msg191610
The death test program
#include <stdio.h>
#include <stdlib.h>
#include <openssl/ssl.h>
void * my_alloc(size_t n) { abort(); }
void my_free(void *p) { abort(); }
void * my_realloc(void *p, size_t n) { abort(); }
int main(int argc, const char **argv)
{
const SSL_METHOD *method;
SSL_CTX *ctx;
CRYPTO_set_mem_functions(my_alloc, my_realloc, my_free);
SSL_library_init();
method = SSLv23_client_method();
ctx = SSL_CTX_new(method);
printf("Got ctx %p\n", ctx);
return 0;
}
aborts as expected on Ubuntu 10.04 with openssl0.9.8k, but blithely
prints a ctx with openssl 1.0.*.
The bug is probably not present in openssl-1.1.0-pre5, as the
offending code was removed by
https://github.com/openssl/openssl/commit/bbd86bf5424a611cb6b77a3a17fc522931c4dcb8
but a fix for 1.0.0 and 1.0.1 would be much appreciated.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Rich Salz via RT
Jun 3, 2016, 1:08:36 PM6/3/16
to
Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and 1.0.1 is
only getting security fixes at this time.
only getting security fixes at this time.
Dan Kegel via RT
Jun 3, 2016, 1:23:37 PM6/3/16
to
1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.)
Rich Salz via RT
Jun 24, 2016, 2:16:35 PM6/24/16
to
I just tried this against 1.0.2 and got a backtrace:
#0 0x00007ffff7847c37 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff784b028 in __GI_abort () at abort.c:89
#2 0x0000000000401cfe in my_alloc (n=176) at a.c:4
#3 0x000000000044e525 in default_malloc_ex (num=176, file=0x5ca5ce "lhash.c",
line=120) at mem.c:79
#4 0x000000000044ebb5 in CRYPTO_malloc (num=176, file=0x5ca5ce "lhash.c",
line=120) at mem.c:330
#5 0x0000000000486d58 in lh_new (h=0x4515f7 <obj_name_LHASH_HASH>,
c=0x451619 <obj_name_LHASH_COMP>) at lhash.c:120
#6 0x000000000045167e in OBJ_NAME_init () at o_names.c:61
#7 0x0000000000451a68 in OBJ_NAME_add (name=0x58bccb "DES-CBC", type=2,
data=0x5cace0 <des_cbc> "\037") at o_names.c:185
#8 0x0000000000490a31 in EVP_add_cipher (c=0x5cace0 <des_cbc>) at names.c:74
#9 0x0000000000421d6e in SSL_library_init () at ssl_algs.c:68
#0 0x00007ffff7847c37 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff784b028 in __GI_abort () at abort.c:89
#2 0x0000000000401cfe in my_alloc (n=176) at a.c:4
#3 0x000000000044e525 in default_malloc_ex (num=176, file=0x5ca5ce "lhash.c",
line=120) at mem.c:79
#4 0x000000000044ebb5 in CRYPTO_malloc (num=176, file=0x5ca5ce "lhash.c",
line=120) at mem.c:330
#5 0x0000000000486d58 in lh_new (h=0x4515f7 <obj_name_LHASH_HASH>,
c=0x451619 <obj_name_LHASH_COMP>) at lhash.c:120
#6 0x000000000045167e in OBJ_NAME_init () at o_names.c:61
#7 0x0000000000451a68 in OBJ_NAME_add (name=0x58bccb "DES-CBC", type=2,
data=0x5cace0 <des_cbc> "\037") at o_names.c:185
#8 0x0000000000490a31 in EVP_add_cipher (c=0x5cace0 <des_cbc>) at names.c:74
#9 0x0000000000421d6e in SSL_library_init () at ssl_algs.c:68
0 new messages