Custom free routine is invoked with NULL argument in openssl 1.0.1

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Custom free routine is invoked with NULL argument in openssl 1.0.1

Sudarshan Raghavan
Hi,

I am using CRYPTO_set_mem_functions to use our own custom memory
routines in a non blocking proxy implementation. This was working fine
in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
routine is being invoked with a NULL argument after calling SSL_free
and this results in the proxy crashing.

#3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
#4  0xb75342b4 in CRYPTO_free () from
/home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
#5  0x00000000 in ?? ()

This happens every time the SSL connections is torn down. If I don't
use CRYPTO_set_mem_functions it works fine. I am assuming the default
free routine ignores a NULL argument. Is it an expectation from the
custom free routine to also ignore NULL? I can provide more
information if needed. Can someone help me debug this problem.

Thanks,
Sudarshan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Dr. Stephen Henson
On Thu, May 24, 2012, Sudarshan Raghavan wrote:

> Hi,
>
> I am using CRYPTO_set_mem_functions to use our own custom memory
> routines in a non blocking proxy implementation. This was working fine
> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> routine is being invoked with a NULL argument after calling SSL_free
> and this results in the proxy crashing.
>
> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
> #4  0xb75342b4 in CRYPTO_free () from
> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
> #5  0x00000000 in ?? ()
>
> This happens every time the SSL connections is torn down. If I don't
> use CRYPTO_set_mem_functions it works fine. I am assuming the default
> free routine ignores a NULL argument. Is it an expectation from the
> custom free routine to also ignore NULL? I can provide more
> information if needed. Can someone help me debug this problem.
>

Well you need to compile OpenSSL with debugging symbols and find precisely
where this is happening with a stack trace. OpenSSL shoudln't be attempting to
free a NULL so this is a bug which should be fixed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Richard Levitte - VMS Whacker
In reply to this post by Sudarshan Raghavan
In message <[hidden email]> on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan <[hidden email]> said:

sudarshan.t.raghavan> Hi,
sudarshan.t.raghavan>
sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our own custom memory
sudarshan.t.raghavan> routines in a non blocking proxy implementation. This was working fine
sudarshan.t.raghavan> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
sudarshan.t.raghavan> routine is being invoked with a NULL argument after calling SSL_free
sudarshan.t.raghavan> and this results in the proxy crashing.
sudarshan.t.raghavan>
sudarshan.t.raghavan> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
sudarshan.t.raghavan> #4  0xb75342b4 in CRYPTO_free () from
sudarshan.t.raghavan> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
sudarshan.t.raghavan> #5  0x00000000 in ?? ()
sudarshan.t.raghavan>
sudarshan.t.raghavan> This happens every time the SSL connections is torn down. If I don't
sudarshan.t.raghavan> use CRYPTO_set_mem_functions it works fine. I am assuming the default
sudarshan.t.raghavan> free routine ignores a NULL argument. Is it an expectation from the
sudarshan.t.raghavan> custom free routine to also ignore NULL? I can provide more
sudarshan.t.raghavan> information if needed. Can someone help me debug this problem.
sudarshan.t.raghavan>
sudarshan.t.raghavan> Thanks,
sudarshan.t.raghavan> Sudarshan

Your assumption is correct, OpenSSL expects the same semantics as
malloc(), realloc() and free(), so you free() replacement must be able
to handle a NULL argument.

Cheers,
Richard

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Jakob Bohm-7
On 5/25/2012 12:30 AM, Richard Levitte wrote:

> In message<[hidden email]>  on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan<[hidden email]>  said:
>
> sudarshan.t.raghavan>  Hi,
> sudarshan.t.raghavan>
> sudarshan.t.raghavan>  I am using CRYPTO_set_mem_functions to use our own custom memory
> sudarshan.t.raghavan>  routines in a non blocking proxy implementation. This was working fine
> sudarshan.t.raghavan>  in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> sudarshan.t.raghavan>  routine is being invoked with a NULL argument after calling SSL_free
> sudarshan.t.raghavan>  and this results in the proxy crashing.
> sudarshan.t.raghavan>
> sudarshan.t.raghavan>  #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
> sudarshan.t.raghavan>  #4  0xb75342b4 in CRYPTO_free () from
> sudarshan.t.raghavan>  /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
> sudarshan.t.raghavan>  #5  0x00000000 in ?? ()
> sudarshan.t.raghavan>
> sudarshan.t.raghavan>  This happens every time the SSL connections is torn down. If I don't
> sudarshan.t.raghavan>  use CRYPTO_set_mem_functions it works fine. I am assuming the default
> sudarshan.t.raghavan>  free routine ignores a NULL argument. Is it an expectation from the
> sudarshan.t.raghavan>  custom free routine to also ignore NULL? I can provide more
> sudarshan.t.raghavan>  information if needed. Can someone help me debug this problem.
> sudarshan.t.raghavan>
> sudarshan.t.raghavan>  Thanks,
> sudarshan.t.raghavan>  Sudarshan
>
> Your assumption is correct, OpenSSL expects the same semantics as
> malloc(), realloc() and free(), so you free() replacement must be able
> to handle a NULL argument.
ANSI C and POSIX free() is NOT required to handle free(NULL)
as a NOP.

ANSI C++ operator delete() is required to do this, but this
requirement does not extent to free() invoked from a C++ program.

Some libc implementations provide this feature anyway, but it
is not a required property of free(), and according to Dr.
Henson's reply above it is not a requirement of the OpenSSL
custom free() callback either.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Sudarshan Raghavan
In reply to this post by Richard Levitte - VMS Whacker
Ok, I can fix the custom free to take care of this. But, why is this
happening in openssl 1.0.1 and not in 1.0.0 or 0.9.8? Is there is a
document or resource in the web that explains what is expected from
the custom alloc, realloc and free routines?

Regards,
Sudarshan

On Fri, May 25, 2012 at 4:00 AM, Richard Levitte <[hidden email]> wrote:

> In message <[hidden email]> on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan <[hidden email]> said:
>
> sudarshan.t.raghavan> Hi,
> sudarshan.t.raghavan>
> sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our own custom memory
> sudarshan.t.raghavan> routines in a non blocking proxy implementation. This was working fine
> sudarshan.t.raghavan> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> sudarshan.t.raghavan> routine is being invoked with a NULL argument after calling SSL_free
> sudarshan.t.raghavan> and this results in the proxy crashing.
> sudarshan.t.raghavan>
> sudarshan.t.raghavan> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
> sudarshan.t.raghavan> #4  0xb75342b4 in CRYPTO_free () from
> sudarshan.t.raghavan> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
> sudarshan.t.raghavan> #5  0x00000000 in ?? ()
> sudarshan.t.raghavan>
> sudarshan.t.raghavan> This happens every time the SSL connections is torn down. If I don't
> sudarshan.t.raghavan> use CRYPTO_set_mem_functions it works fine. I am assuming the default
> sudarshan.t.raghavan> free routine ignores a NULL argument. Is it an expectation from the
> sudarshan.t.raghavan> custom free routine to also ignore NULL? I can provide more
> sudarshan.t.raghavan> information if needed. Can someone help me debug this problem.
> sudarshan.t.raghavan>
> sudarshan.t.raghavan> Thanks,
> sudarshan.t.raghavan> Sudarshan
>
> Your assumption is correct, OpenSSL expects the same semantics as
> malloc(), realloc() and free(), so you free() replacement must be able
> to handle a NULL argument.
>
> Cheers,
> Richard
>
> --
> Richard Levitte                         [hidden email]
>                                        http://richard.levitte.org/
>
> "Life is a tremendous celebration - and I'm invited!"
> -- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Sudarshan Raghavan
In reply to this post by Dr. Stephen Henson
I enabled debug symbols in openssl and this is what I am seeing


#3  0x0828bd74 in CUSTOM_FREE (oldMem=0x0) at ssl_mem.c:34
#4  0xb758e160 in CRYPTO_free (str=0x0) at mem.c:397
#5  0xb773520c in SSL_SRP_CTX_free (s=0xb3e4f300) at tls_srp.c:102
#6  0xb77091c0 in ssl3_free (s=0xb3e4f300) at s3_lib.c:2995
#7  0xb7712486 in tls1_free (s=0xb3e4f300) at t1_lib.c:165
#8  0xb77265f2 in SSL_free (s=0xb3e4f300) at ssl_lib.c:586

tls_srp.c :102 is this

OPENSSL_free(s->srp_ctx.login);

Regards,
Sudarshan

On Thu, May 24, 2012 at 7:23 PM, Dr. Stephen Henson <[hidden email]> wrote:

> On Thu, May 24, 2012, Sudarshan Raghavan wrote:
>
>> Hi,
>>
>> I am using CRYPTO_set_mem_functions to use our own custom memory
>> routines in a non blocking proxy implementation. This was working fine
>> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
>> routine is being invoked with a NULL argument after calling SSL_free
>> and this results in the proxy crashing.
>>
>> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
>> #4  0xb75342b4 in CRYPTO_free () from
>> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
>> #5  0x00000000 in ?? ()
>>
>> This happens every time the SSL connections is torn down. If I don't
>> use CRYPTO_set_mem_functions it works fine. I am assuming the default
>> free routine ignores a NULL argument. Is it an expectation from the
>> custom free routine to also ignore NULL? I can provide more
>> information if needed. Can someone help me debug this problem.
>>
>
> Well you need to compile OpenSSL with debugging symbols and find precisely
> where this is happening with a stack trace. OpenSSL shoudln't be attempting to
> free a NULL so this is a bug which should be fixed.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Sudarshan Raghavan
I can see this code in s3_lib.c

                if (ctx->srp_ctx.login != NULL)
                        OPENSSL_free(ctx->srp_ctx.login);

while tls_srp.c does not have the NULL check before calling free. I
added the NULL check in tls_srp.c and I am not seeing the crash
anymore. Is this the fix or is there something more to this?

Regards,
Sudarshan

On Fri, May 25, 2012 at 5:00 PM, Sudarshan Raghavan
<[hidden email]> wrote:

> I enabled debug symbols in openssl and this is what I am seeing
>
>
> #3  0x0828bd74 in CUSTOM_FREE (oldMem=0x0) at ssl_mem.c:34
> #4  0xb758e160 in CRYPTO_free (str=0x0) at mem.c:397
> #5  0xb773520c in SSL_SRP_CTX_free (s=0xb3e4f300) at tls_srp.c:102
> #6  0xb77091c0 in ssl3_free (s=0xb3e4f300) at s3_lib.c:2995
> #7  0xb7712486 in tls1_free (s=0xb3e4f300) at t1_lib.c:165
> #8  0xb77265f2 in SSL_free (s=0xb3e4f300) at ssl_lib.c:586
>
> tls_srp.c :102 is this
>
> OPENSSL_free(s->srp_ctx.login);
>
> Regards,
> Sudarshan
>
> On Thu, May 24, 2012 at 7:23 PM, Dr. Stephen Henson <[hidden email]> wrote:
>> On Thu, May 24, 2012, Sudarshan Raghavan wrote:
>>
>>> Hi,
>>>
>>> I am using CRYPTO_set_mem_functions to use our own custom memory
>>> routines in a non blocking proxy implementation. This was working fine
>>> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
>>> routine is being invoked with a NULL argument after calling SSL_free
>>> and this results in the proxy crashing.
>>>
>>> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
>>> #4  0xb75342b4 in CRYPTO_free () from
>>> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
>>> #5  0x00000000 in ?? ()
>>>
>>> This happens every time the SSL connections is torn down. If I don't
>>> use CRYPTO_set_mem_functions it works fine. I am assuming the default
>>> free routine ignores a NULL argument. Is it an expectation from the
>>> custom free routine to also ignore NULL? I can provide more
>>> information if needed. Can someone help me debug this problem.
>>>
>>
>> Well you need to compile OpenSSL with debugging symbols and find precisely
>> where this is happening with a stack trace. OpenSSL shoudln't be attempting to
>> free a NULL so this is a bug which should be fixed.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Richard Levitte - VMS Whacker
In reply to this post by Jakob Bohm-7
In message <[hidden email]> on Fri, 25 May 2012 09:33:36 +0200, Jakob Bohm <[hidden email]> said:

jb-openssl> On 5/25/2012 12:30 AM, Richard Levitte wrote:
jb-openssl> > In
jb-openssl> > message<[hidden email]>
jb-openssl> > on Thu, 24 May 2012 17:46:49 +0530, Sudarshan
jb-openssl> > Raghavan<[hidden email]> said:
jb-openssl> >
jb-openssl> > sudarshan.t.raghavan>  Hi,
jb-openssl> > sudarshan.t.raghavan>
jb-openssl> > sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our
jb-openssl> > own custom memory
jb-openssl> > sudarshan.t.raghavan> routines in a non blocking proxy
jb-openssl> > implementation. This was working fine
jb-openssl> > sudarshan.t.raghavan> in 0.9.8 and 1.0.0 but with 1.0.1c I can see
jb-openssl> > that the custom free
jb-openssl> > sudarshan.t.raghavan> routine is being invoked with a NULL argument
jb-openssl> > after calling SSL_free
jb-openssl> > sudarshan.t.raghavan>  and this results in the proxy crashing.
jb-openssl> > sudarshan.t.raghavan>
jb-openssl> > sudarshan.t.raghavan> #3 0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at
jb-openssl> > custom_mem.c:340
jb-openssl> > sudarshan.t.raghavan>  #4  0xb75342b4 in CRYPTO_free () from
jb-openssl> > sudarshan.t.raghavan>
jb-openssl> > /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
jb-openssl> > sudarshan.t.raghavan>  #5  0x00000000 in ?? ()
jb-openssl> > sudarshan.t.raghavan>
jb-openssl> > sudarshan.t.raghavan>  This happens every time the SSL connections is torn down. If I don't
jb-openssl> > sudarshan.t.raghavan>  use CRYPTO_set_mem_functions it works fine. I am assuming the default
jb-openssl> > sudarshan.t.raghavan>  free routine ignores a NULL argument. Is it an expectation from the
jb-openssl> > sudarshan.t.raghavan>  custom free routine to also ignore NULL? I can provide more
jb-openssl> > sudarshan.t.raghavan>  information if needed. Can someone help me debug this problem.
jb-openssl> > sudarshan.t.raghavan>
jb-openssl> > sudarshan.t.raghavan>  Thanks,
jb-openssl> > sudarshan.t.raghavan>  Sudarshan
jb-openssl> >
jb-openssl> > Your assumption is correct, OpenSSL expects the same semantics as
jb-openssl> > malloc(), realloc() and free(), so you free() replacement must be able
jb-openssl> > to handle a NULL argument.
jb-openssl> ANSI C and POSIX free() is NOT required to handle free(NULL)
jb-openssl> as a NOP.
jb-openssl>
jb-openssl> ANSI C++ operator delete() is required to do this, but this
jb-openssl> requirement does not extent to free() invoked from a C++ program.

I stand corrected.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Jeffrey Walton-3
In reply to this post by Sudarshan Raghavan
On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan
<[hidden email]> wrote:
> Ok, I can fix the custom free to take care of this. But, why is this
> happening in openssl 1.0.1 and not in 1.0.0 or 0.9.8?
I think the question to ask is why your code or library routines are
not validating parameters before operating on them. Its a hostile
world full of mis-users and adversaries - look for any reason to deny
processing (and if you can't find a reason, begrudgingly perform the
processing).

Negative test cases usually vet out this sort of thing. Are you
writing them against you code or library?

> Is there is a document or resource
> in the web that explains what is expected from
> the custom alloc, realloc and free routines?
Probably not.

Jeff

> On Fri, May 25, 2012 at 4:00 AM, Richard Levitte <[hidden email]> wrote:
>> In message <[hidden email]> on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan <[hidden email]> said:
>>
>> sudarshan.t.raghavan> Hi,
>> sudarshan.t.raghavan>
>> sudarshan.t.raghavan> I am using CRYPTO_set_mem_functions to use our own custom memory
>> sudarshan.t.raghavan> routines in a non blocking proxy implementation. This was working fine
>> sudarshan.t.raghavan> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
>> sudarshan.t.raghavan> routine is being invoked with a NULL argument after calling SSL_free
>> sudarshan.t.raghavan> and this results in the proxy crashing.
>> sudarshan.t.raghavan>
>> sudarshan.t.raghavan> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
>> sudarshan.t.raghavan> #4  0xb75342b4 in CRYPTO_free () from
>> sudarshan.t.raghavan> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
>> sudarshan.t.raghavan> #5  0x00000000 in ?? ()
>> sudarshan.t.raghavan>
>> sudarshan.t.raghavan> This happens every time the SSL connections is torn down. If I don't
>> sudarshan.t.raghavan> use CRYPTO_set_mem_functions it works fine. I am assuming the default
>> sudarshan.t.raghavan> free routine ignores a NULL argument. Is it an expectation from the
>> sudarshan.t.raghavan> custom free routine to also ignore NULL? I can provide more
>> sudarshan.t.raghavan> information if needed. Can someone help me debug this problem.
>> sudarshan.t.raghavan>
>> sudarshan.t.raghavan> Thanks,
>> sudarshan.t.raghavan> Sudarshan
>>
>> Your assumption is correct, OpenSSL expects the same semantics as
>> malloc(), realloc() and free(), so you free() replacement must be able
>> to handle a NULL argument.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Custom free routine is invoked with NULL argument in openssl 1.0.1

Steffen DETTMER
Hi all!

* Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM

> On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan
>                              <[hidden email]> wrote:
> > Ok, I can fix the custom free to take care of this.
> > But, why is this happening in openssl 1.0.1 and not in 1.0.0 or
> > 0.9.8?
>
> I think the question to ask is why your code or library
> routines are not validating parameters before operating on
> them. Its a hostile world full of mis-users and adversaries -
> look for any reason to deny processing (and if you can't find
> a reason, begrudgingly perform the processing).

I think in this case the parameter *cannot* be checked. The passed
parameter is a pointer to dynamically allocated memory and a C
application has not way to correctly check a pointer for being valid.
It can be a valid pointer to static .text or to already freed dynamic
memory, it could be a wild pointer or some other dangling one.

Of course it is possible to add some checks like for non-equal to NULL
or non-equal to "whatever limited list of known invalid pointers" (also
pointers to functions cannot be freed etc), but I think this only
missleadingly suggests that a function would be able to check its
pointer arguments.

I think crashing with NULL is quite good: a must-not-happen situation
leads to a defined dead of SIGSEGVs, at least for platforms supporting
that, typically with good aid for debuggin (like core files or halting
debuggers providing a backtrace). Maybe adding an assert() before.

oki,

Steffen

--
[end of message]

















































 
About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue.
More information on http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
 
 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Ken Goldman-2
On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
>
> I think crashing with NULL is quite good: a must-not-happen situation
> leads to a defined dead of SIGSEGVs, at least for platforms supporting
> that, typically with good aid for debuggin (like core files or halting
> debuggers providing a backtrace). Maybe adding an assert() before.

That's not the normal library behavior.

My typical design pattern is:

void *ptr = NULL;
do stuff which may in some branches allocate the pointer
free(ptr);

If the library crashes on free(NULL), you're just making people like me
do this everywhere:

if (ptr != NULL) free (ptr);


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Ken Goldman-2
In reply to this post by Jakob Bohm-7
On 5/25/2012 3:33 AM, Jakob Bohm wrote:

> ANSI C and POSIX free() is NOT required to handle free(NULL)
> as a NOP.

I checked reputable sources (Plauger, Harbison and Steele, the ANSI
spec, and the IEEE POSIX spec).

All agree that (e.g. ANSI)

"If ptr is a null pointer, no action occurs."



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Jeffrey Walton-3
In reply to this post by Sudarshan Raghavan
On Thu, May 24, 2012 at 8:16 AM, Sudarshan Raghavan
<[hidden email]> wrote:

> Hi,
>
> I am using CRYPTO_set_mem_functions to use our own custom memory
> routines in a non blocking proxy implementation. This was working fine
> in 0.9.8 and 1.0.0 but with 1.0.1c I can see that the custom free
> routine is being invoked with a NULL argument after calling SSL_free
> and this results in the proxy crashing.
>
> #3  0x0828bd24 in CUSTOM_FREE (oldMem=0x0) at custom_mem.c:340
> #4  0xb75342b4 in CRYPTO_free () from
> /home/product/code/firmware/current/lib/openssl1.0/lib/libcrypto.so.1.0.0
> #5  0x00000000 in ?? ()
>
> This happens every time the SSL connections is torn down. If I don't
> use CRYPTO_set_mem_functions it works fine. I am assuming the default
> free routine ignores a NULL argument. Is it an expectation from the
> custom free routine to also ignore NULL? I can provide more
> information if needed. Can someone help me debug this problem.
Agreed on non-NULL pointers.

Perhaps I'm looking at the wrong free function (or I'm not
reading/deducing correct behavior), but it looks like a double free to
me:

void CRYPTO_free(void *str)
{
    if (free_debug_func != NULL)
        free_debug_func(str, 0);
#ifdef LEVITTE_DEBUG
    fprintf(stderr, "LEVITTE_DEBUG:         < 0x%p\n", str);
#endif
    free_func(str);
    if (free_debug_func != NULL)
        free_debug_func(NULL, 1);
}

Regarding parameter validation, below is a perfect example since free
(from above) does not appear to include a size. Are implementations
verifying `num` is not less than 0 since it is defined as an integer?
Its clear the OpenSSL code is not verifying its parameters. What's not
clear to me is why one can even specify a negative size.

void *CRYPTO_malloc(int num, const char *file, int line)
{
    void *ret = NULL;

    allow_customize = 0;
    if (malloc_debug_func != NULL)
    {
        allow_customize_debug = 0;
        malloc_debug_func(NULL, num, file, line, 0);
    }
    ret = malloc_func(num);
#ifdef LEVITTE_DEBUG
    fprintf(stderr, "LEVITTE_DEBUG:         > 0x%p (%d)\n", ret, num);
#endif
    if (malloc_debug_func != NULL)
        malloc_debug_func(ret, num, file, line, 1);

    return ret;
}
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Carter Browne
In reply to this post by Ken Goldman-2
On 5/25/2012 11:25 AM, Ken Goldman wrote:

> On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
>>
>> I think crashing with NULL is quite good: a must-not-happen situation
>> leads to a defined dead of SIGSEGVs, at least for platforms supporting
>> that, typically with good aid for debuggin (like core files or halting
>> debuggers providing a backtrace). Maybe adding an assert() before.
>
> That's not the normal library behavior.
>
> My typical design pattern is:
>
> void *ptr = NULL;
> do stuff which may in some branches allocate the pointer
> free(ptr);
>
> If the library crashes on free(NULL), you're just making people like me
> do this everywhere:
>
> if (ptr != NULL) free (ptr);

Any secure programming standard would also require that you set ptr to NULL as
soon as you free it.
Re-using already freed memory pointers is a common source of both bugs and
security holes.
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
> .
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Custom free routine is invoked with NULL argument in openssl 1.0.1

Sudarshan Raghavan
In reply to this post by Steffen DETTMER

I agree. Passing NULL to a free function is most likely due to a bug. Given that would you rather assert and find out the reason or ignore. I would assume the defensive option would be to assert and analyze the core. My 2 cents.

Regards,
Sudarshan

On 25-May-2012 8:39 PM, "Steffen DETTMER" <[hidden email]> wrote:
Hi all!

* Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM
> On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan
>                              <[hidden email]> wrote:
> > Ok, I can fix the custom free to take care of this.
> > But, why is this happening in openssl 1.0.1 and not in 1.0.0 or
> > 0.9.8?
>
> I think the question to ask is why your code or library
> routines are not validating parameters before operating on
> them. Its a hostile world full of mis-users and adversaries -
> look for any reason to deny processing (and if you can't find
> a reason, begrudgingly perform the processing).

I think in this case the parameter *cannot* be checked. The passed
parameter is a pointer to dynamically allocated memory and a C
application has not way to correctly check a pointer for being valid.
It can be a valid pointer to static .text or to already freed dynamic
memory, it could be a wild pointer or some other dangling one.

Of course it is possible to add some checks like for non-equal to NULL
or non-equal to "whatever limited list of known invalid pointers" (also
pointers to functions cannot be freed etc), but I think this only
missleadingly suggests that a function would be able to check its
pointer arguments.

I think crashing with NULL is quite good: a must-not-happen situation
leads to a defined dead of SIGSEGVs, at least for platforms supporting
that, typically with good aid for debuggin (like core files or halting
debuggers providing a backtrace). Maybe adding an assert() before.

oki,

Steffen

--
[end of message]


















































About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue.
More information on http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Jeffrey Walton-3
In reply to this post by Ken Goldman-2
On Fri, May 25, 2012 at 11:25 AM, Ken Goldman <[hidden email]> wrote:
> On 5/25/2012 11:03 AM, Steffen DETTMER wrote:
>>
>> I think crashing with NULL is quite good: a must-not-happen situation
>> leads to a defined dead of SIGSEGVs, at least for platforms supporting
>> that, typically with good aid for debuggin (like core files or halting
>> debuggers providing a backtrace). Maybe adding an assert() before.
> That's not the normal library behavior.
Agreed - runtime crashes or calls to abort() are not appropriate in
production code (ie, NDEBUG is defined).

> My typical design pattern is:
>
> void *ptr = NULL;
> do stuff which may in some branches allocate the pointer
> free(ptr);
This is very old, and has not evolved as security needs have changed
(forgive me if I read too much into int). For example, the return
value of alloc() should be validated (lack of validation happens more
often than one would expect). If pointer validation is occuring, then
the [pointer validation] problem with free() is a non sequitur *IF*
free() occurs in the same function.

> If the library crashes on free(NULL), you're just making people like me
> do this everywhere:
>
> if (ptr != NULL) free (ptr);
If the free() is in a different function than the alloc(), the pointer
should be checked. Though legal C/C++, it makes no conceptual sense to
free a NULL pointer. I don't believe its an appropriate style to use
in the 2010's in a hostile envirnoment. In my mind's eye, it
demonstrates a level of slopiness that makes me suspicious.

I understand many others think differently than me, and it was not my
intention to start a flame war.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Ken Goldman-2
On 5/25/2012 12:09 PM, Jeffrey Walton wrote:
>
>> My typical design pattern is:
>>
>> void *ptr = NULL;
>> do stuff which may in some branches allocate the pointer
>> free(ptr);

> This is very old, and has not evolved as security needs have changed
> (forgive me if I read too much into it). For example, the return
> value of alloc() should be validated (lack of validation happens more
> often than one would expect). If pointer validation is occurring, then
> the [pointer validation] problem with free() is a non sequitur *IF*
> free() occurs in the same function.

It was s snippet.  Of course I check the return values!

BTW, if the alloc fails, the ptr will be NULL, so free(ptr) at the end
is still safe.

>
>> If the library crashes on free(NULL), you're just making people like me
>> do this everywhere:
>>
>> if (ptr != NULL) free (ptr);
> If the free() is in a different function than the alloc(), the pointer
> should be checked. Though legal C/C++, it makes no conceptual sense to
> free a NULL pointer. I don't believe its an appropriate style to use
> in the 2010's in a hostile environment. In my mind's eye, it
> demonstrates a level of sloppiness that makes me suspicious.

I don't see anything sloppy or risky about it.  The standard clearly
says free(NULL) is a legal noop.  Why bother doing
        if (ptr != NULL)
when the library already does it.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Custom free routine is invoked with NULL argument in openssl 1.0.1

Ken Goldman-2
In reply to this post by Carter Browne
On 5/25/2012 11:41 AM, Carter Browne wrote:

>> That's not the normal library behavior.
>>
>> My typical design pattern is:
>>
>> void *ptr = NULL;
>> do stuff which may in some branches allocate the pointer
>> free(ptr);
>>
>> If the library crashes on free(NULL), you're just making people like me
>> do this everywhere:
>>
>> if (ptr != NULL) free (ptr);
>

That was just a snippet to explain why I take advantage of free(NULL)
being a noop.

> Any secure programming standard would also require that you set ptr to NULL as
> soon as you free it.

I always do all the free()'s just before the function returns.  Setting
the local variable to NULL just before it disappears is redundant.

If you're worried about a function leaking secrets, I always zero an
array with secrets before I free it.

> Re-using already freed memory pointers is a common source of both bugs and
> security holes.

In a real program, I don't reuse pointers.  The saving of a few bytes is
hardly worth the risk (as you said).  It also makes the program harder
to understand when variables are reused.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Custom free routine is invoked with NULL argument in openssl 1.0.1

Steffen DETTMER
In reply to this post by Carter Browne
Hi all!

> > If the library crashes on free(NULL), you're just making
> > people like me do this everywhere:
> >
> > if (ptr != NULL) free (ptr);

ok, if you have a test case "free (NULL)", agreed ;-)
Seems not all platforms conform to the "free(NULL) is a no-op".

I understand your example, thanks for that, but I don't think
that this is the general case for "validating parameters".
Actually, NULL even is a valid parameter to free!

My comment was about:

> > > validating parameters before operating on them

I just wanted to tell, that it is not possible to validate pointer
parameters in C.  You might be able to invalidate a few (NULL and (-1)
maybe?), but you cannot validate. So functions must rely on the validity
of passed pointers. NULL could be may indicate an optional parameter:
the parameter / the object can be omitted, but otherwise it must be
valid, or in short, the passed object must be valid.

Checking "(ptr != NULL)" IMHO is not validating parameters, but it is
checking for one special case. There are many more possibilities for
invalid pointers, and most cannot be checked for.  Also setting ptr =
NULL after the free is not safe, because other pointers to the same
object may exist. All those measurements surely can limit damage - but
also increase later damage.

This does not mean checking for NULL is bad!!
-- it means checking for NULL is no reliable "parameter verification".

Especially since NULL is valid return value of malloc and argument
to free, ptr == NULL does not even indicate an invalid parameter,
because for example to free() it is a valid one.

> Any secure programming standard would also require that you
> set ptr to NULL as soon as you free it.
> Re-using already freed memory pointers is a common source of
> both bugs and security holes.

Yes, I agree.
Set it to NULL -- but still, better not rely on that.

If a pointer is NULL at a point in code where it shouldn't be NULL, just
adding an "if(ptr != NULL)" (for that mandatory ptr) could lead to
issues later. Here, assert() might help to spot bugs in development. If
the pointer might be NULL, it is a valid one, of course then no assert.
Double-free looks wrong even if pointer was set to NULL and second free
has no effect.

oki,

Steffen

--
[end of message]


















































 
About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue.
More information on http://www.ingenico.com/.
 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
 P Please consider the environment before printing this e-mail
 
 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Custom free routine is invoked with NULL argument in openssl 1.0.1

J. J. Farrell-2
In reply to this post by Jakob Bohm-7
> From: Jakob Bohm [mailto:[hidden email]]
>
> On 5/25/2012 12:30 AM, Richard Levitte wrote:
> >
> > sudarshan.t.raghavan>  I am assuming the default
> > sudarshan.t.raghavan>  free routine ignores a NULL argument
> >
> > Your assumption is correct, OpenSSL expects the same semantics as
> > malloc(), realloc() and free(), so you free() replacement must be
> > able to handle a NULL argument.
>
> ANSI C and POSIX free() is NOT required to handle free(NULL)
> as a NOP.

I'm afraid you're wrong on that Jakob. Quoting from C99:

======================================
7.20.3.2 The free function

Synopsis
#include <stdlib.h>
void free(void *ptr);

Description
The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc, malloc, or realloc function, or if the
space has been deallocated by a call to free or realloc, the behavior
is undefined.
======================================

The original and current C Standards say the same, as does POSIX.

Regards,
              jjf

> ANSI C++ operator delete() is required to do this, but this
> requirement does not extent to free() invoked from a C++ program.
>
> Some libc implementations provide this feature anyway, but it
> is not a required property of free(), and according to Dr.
> Henson's reply above it is not a requirement of the OpenSSL
> custom free() callback either.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
12