Re: C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 2012-06-04 8:10 PM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. C89/90 is hard to find now, but it definitely did specify free(NULL) is no-op. You say elsethread you may have confused C89 free() with generally similar calls in OS or perhaps libraries; those certainly might not be safe for NULL. According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the last widely-used platform that crashed on free(NULL) was SunOS 4, which stopped being a reasonable portability target around 2007. SunOS 4 was noncompliant with C89 in dozens of other ways as well. zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 6/5/2012 6:19 AM, Zack Weinberg wrote: On 2012-06-04 8:10 PM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. C89/90 is hard to find now, but it definitely did specify free(NULL) is no-op. You say elsethread you may have confused C89 free() with generally similar calls in OS or perhaps libraries; those certainly might not be safe for NULL. According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the last widely-used platform that crashed on free(NULL) was SunOS 4, which stopped being a reasonable portability target around 2007. SunOS 4 was noncompliant with C89 in dozens of other ways as well. Actually, that is not really what it says when read closely. What it really says is than some guy named Jim Meyering believed (possibly mistakenly) that the free(NULL) issue existed only on SunOS 4 (he gave no reason for that belief). On top of that Jim Meyering may have referring to some political GNU policy of not wanting to support SunOS 4 as an official porting target (again, Jim Meyering gave no reason for why SunOS 4 became irrelevant in 2007). None of that is really convincing, and the surrounding thread makes it clear that the gcc patch in question consisted entirely of overeager cleanup. The quotes elsewhere in this discussion have convinced me that C89 did require free(NULL) to be a NOP, however I have limited data as to how many platforms implemented that specific requirement correctly, and prefer to keep guarding my free() calls just to be safe. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
On Tue, Jun 5, 2012 at 4:35 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 6/5/2012 6:19 AM, Zack Weinberg wrote: According to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00376.html the last widely-used platform that crashed on free(NULL) was SunOS 4, which stopped being a reasonable portability target around 2007. Actually, that is not really what it says when read closely. What it really says is than some guy named Jim Meyering believed (possibly mistakenly) that the free(NULL) issue existed only on SunOS 4 (he gave no reason for that belief). Rather, that it existed on many pre-C89 platforms including SunOS 4, but all of them ceased to be interesting portability targets before SunOS 4 did. On top of that Jim Meyering may have referring to some political GNU policy of not wanting to support SunOS 4 as an official porting target (again, Jim Meyering gave no reason for why SunOS 4 became irrelevant in 2007). I'm not aware of any general GNU policy for or against supporting old systems (but I am not necessarily in the loop for such things). However, I trust Jim Meyering not to make such statements lightly. (I would have put SunOS 4's irrelevance date considerably earlier, tbh.) Enough about this, but I do have a related question which is more on-topic for this list: Do the various OBJECT_free() functions *defined by libssl and libcrypto* make the same promise to be a no-op when called on a NULL pointer? zw __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Sent: Tuesday, 29 May, 2012 03:34 On 5/27/2012 2:29 AM, Jeremy Farrell wrote: snip: ANSI C and POSIX make free(NULL) no-op Note that when considering portability, C99 is not yet fully implemented everywhere, so when I say ANSI C without qualification, I generally refer to C89 plus the two TR update documents that mostly focused on things many compilers were already doing. That's confused. There were no Technical Reports (TR) for C89/90. There were two Technical Corrigenda *TC* AND one Normative Amendment (NA or AMD) which substantially expanded the 'wchar_t' (effectively Unicode) features. The 2 TCs and NA for C90 were rolled-up into C99, and similarly the three TCs for C99 are rolled-up into C11 (which I don't think is fully implemented *any*where). (I think the committee starting draft for C11, n1256, has already been pointed to; that's exactly C11+TC[123].) There were several TRs for C99; two were apparently accepted for roll-up to C11, but I didn't track them. Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. C89/90 is hard to find now, but it definitely did specify free(NULL) is no-op. You say elsethread you may have confused C89 free() with generally similar calls in OS or perhaps libraries; those certainly might not be safe for NULL. I'll believe Stroustrup emphasized it more clearly, though my TC++PL was 'borrowed' years ago and never recovered. (KR1 and then 2 were pretty exact but often quite terse. TC++PLs were also exact but often more explanatory.) As C99 adopted many other features from C++ (such as declarations between statements), the free(NULL) behavior might also be new in C99. The only three 'backports' I know are mixed-declarations, prototypes, and // comments. Those are important features, but not many. Well, and C99 tgmath (and now C11 _Generic) is vaguely similar to C++ templates, but only vaguely. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 5/29/2012 8:56 PM, Jeremy Farrell wrote: From: Jakob Bohm [mailto:jb-open...@wisemo.com] Sent: Tuesday, May 29, 2012 8:34 AM On 5/27/2012 2:29 AM, Jeremy Farrell wrote: From: Jakob Bohm [mailto:jb-open...@wisemo.com] On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I quoted from C99 in a recent message; can't remember where I got it (12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99 and C11 legally available for free on the web I believe. Various revisions of POSIX are available free for reference online; the current POSIX.1-2008 at http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1- 2004 at http://pubs.opengroup.org/onlinepubs/009695399/ Note that when considering portability, C99 is not yet fully implemented everywhere, so when I say ANSI C without qualification, I generally refer to C89 plus the two TR update documents that mostly focused on things many compilers were already doing. Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. As C99 adopted many other features from C++ (such as declarations between statements), the free(NULL) behavior might also be new in C99. C99 was what I had most conveniently to hand, but as I mentioned originally the requirement has been the same in all versions of Standard C from C89 through to the current C11. C89 has: 4.10.3.2 The free function Synopsis #includestdlib.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. Returns The free function returns no value. The Rationale for C89 states The null pointer is specified as a valid argument to this function to reduce the need for special-case coding. Other standards documents of the time (XPG3, for example) mention adding the sentence on NULL for conformance with the draft C Standard, so it looks like the ANSI C committee was the driver for explicitly requiring this behaviour; I don't know if any earlier implementations worked that way, KR 1 didn't mention the free library function. I don't know C++, but Stroustrup's site says C++ 2 was written in '91, so he'd be assuming the C89 library as the basis. In the early days of C++, Stroustrup was also closely involved in the work that became C89. In one of his books, he has taken partial credit for the const keyword. Some of the NULL not accepted free routines I have come across were slightly outside the basic C runtime (such as underlying OS memory allocators), so adding the special casing for NULL (or other false) pointers has been deeply engrained in my coding habits for long enough that I may not have noticed if most libc implementations did their own checking and NOP-ing too. I also started coding before 1989, although didn't learn C until after '89, so I may have learned from existing KR compatible code (It is kind of sad that recent compilers have dropped the KR parsing option, it was kind of cute). I'm a bit surprised you've come across systems at all recently which don't tolerate free of NULL. I've tended to assume they do without explicitly testing it (I'm fool enough to rely blindly on standards for some things), but I would usually only make such a call in unusual error paths; I guess it may come back to bite me sometime. Regards, jjf -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 5/27/2012 2:29 AM, Jeremy Farrell wrote: From: Jakob Bohm [mailto:jb-open...@wisemo.com] On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I quoted from C99 in a recent message; can't remember where I got it (12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99 and C11 legally available for free on the web I believe. Various revisions of POSIX are available free for reference online; the current POSIX.1-2008 at http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1-2004 at http://pubs.opengroup.org/onlinepubs/009695399/ Note that when considering portability, C99 is not yet fully implemented everywhere, so when I say ANSI C without qualification, I generally refer to C89 plus the two TR update documents that mostly focused on things many compilers were already doing. Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. As C99 adopted many other features from C++ (such as declarations between statements), the free(NULL) behavior might also be new in C99. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
From: Jakob Bohm jb-open...@wisemo.com Which version of the ANSI Spec, and where did you get a copy? I have to rely on secondary sources and experience using various implementations that claim conformance. I generally refer to Plauger's The Standard C Library, where he quotes the spec with commentary and implementation. Plauger was a co-author of the standard. Google finds this copy of the spec: http://flash-gordon.me.uk/ansi.c.txt Even KR say free(NULL) is a noop.
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
From: Jakob Bohm [mailto:jb-open...@wisemo.com] Sent: Tuesday, May 29, 2012 8:34 AM On 5/27/2012 2:29 AM, Jeremy Farrell wrote: From: Jakob Bohm [mailto:jb-open...@wisemo.com] On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I quoted from C99 in a recent message; can't remember where I got it (12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99 and C11 legally available for free on the web I believe. Various revisions of POSIX are available free for reference online; the current POSIX.1-2008 at http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1- 2004 at http://pubs.opengroup.org/onlinepubs/009695399/ Note that when considering portability, C99 is not yet fully implemented everywhere, so when I say ANSI C without qualification, I generally refer to C89 plus the two TR update documents that mostly focused on things many compilers were already doing. Having no current access to the C89 standard or its drafts, I am relying on the experience that many C89 real world systems I have encountered did not tolerate free(NULL). In contrast all recent C++ specifications (starting with The C++ Programming Language 2nd Ed. which preceded all published standards), insist that delete (char*)NULL must be a safe NOP. As C99 adopted many other features from C++ (such as declarations between statements), the free(NULL) behavior might also be new in C99. C99 was what I had most conveniently to hand, but as I mentioned originally the requirement has been the same in all versions of Standard C from C89 through to the current C11. C89 has: 4.10.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. Returns The free function returns no value. The Rationale for C89 states The null pointer is specified as a valid argument to this function to reduce the need for special-case coding. Other standards documents of the time (XPG3, for example) mention adding the sentence on NULL for conformance with the draft C Standard, so it looks like the ANSI C committee was the driver for explicitly requiring this behaviour; I don't know if any earlier implementations worked that way, KR 1 didn't mention the free library function. I don't know C++, but Stroustrup's site says C++ 2 was written in '91, so he'd be assuming the C89 library as the basis. I'm a bit surprised you've come across systems at all recently which don't tolerate free of NULL. I've tended to assume they do without explicitly testing it (I'm fool enough to rely blindly on standards for some things), but I would usually only make such a call in unusual error paths; I guess it may come back to bite me sometime. Regards, jjf __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
C standard, was RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
(somewhat offtopic) From: owner-openssl-us...@openssl.org On Behalf Of Jeremy Farrell Sent: Saturday, 26 May, 2012 20:29 From: Jakob Bohm [mailto:jb-open...@wisemo.com] Which version of the ANSI Spec, and where did you get a copy? I quoted from C99 in a recent message; can't remember where I got it (12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99 and C11 legally available for free on the web I believe. ANSI generally sells the official versions of computer standards (specifically those under jurisdiction of INCITS-formerly-ASCX3) in PDF for individual use for USD 30 at webstore.ansi.org . (Years ago, including 2000 when I bought C99, it was USD 18.) Right now they have both 9899-1999 (C99) and 9899-2011* (C11) which was just adopted (and not yet implemented that I know of) but this probably won't last long. Note you must select the INCITS version; the other (here BSI and ISO/IEC) versions have identical content but are much more costly for legal reasons. (* The ISO/IEC adoption of C11 was very late in the year, and so the INCITS=ANSI=US formal adoption was in 2012. This seems to have resulted in a confusing listing on webstore; the INCITS 2011[2012] link doesn't work and the INCITS 2012 link is 2011.) The committee (formally, Working Group 14 of SubCommittee 22 of ISO/IEC JTC1) website is http://www.open-std.org/jtc1/sc22/wg14/ . They publish numerous working documents, including periodic (usually once or twice a year) updated drafts of the standard, all identified by (roughly) sequential n numbers. n869 cited elsethread was indeed the last draft before C99. n1256 was the starting draft for C11, and consisted of C99 as amended by the three Technical Corrigenda and thus is a rather convenient reference to what C99 really is, except for two minor typos which the editor Lawrence Jones posted to comp.lang.c some years ago but a quick google didn't find. n1570 was the last draft before C11, if you're interested where C may be going (or not) in the future. (Also n1569 nonpublic?) Formally the committee documents are copyright, and years ago they had a statement on the website to the effect they were published only for purposes advancing standardization of C or something pretty vague like that, but I find no such statement there now and people in comp.lang.c (and also comp.std.c) have for years frequently cited the standard drafts and sometimes other committee documents and there have never been any complaints about doing so. Various revisions of POSIX are available free for reference online; the current POSIX.1-2008 at http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1-2004 at http://pubs.opengroup.org/onlinepubs/009695399/ That too. Although POSIX duplicates some information from the C standard(s) but formally says if the POSIX copy differs from the actual C standard the actual C standard prevails. Most of POSIX, of course, is *addditional* to the C standard and in those areas it is definitive. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
Hi all, Which version of the ANSI Spec, and where did you get a copy? I have to rely on secondary sources and experience using various implementations that claim conformance. Wikipedia http://en.wikipedia.org/wiki/ANSI_C is used to have a link to a recent draft (free of charge) which is known to be very close to the standard, currently it points to a plain text document at http://flash-gordon.me.uk/ansi.c.txt. oki, Steffen 4.10.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. Returns The free function returns no value. -- 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I have to rely on secondary sources and experience using various implementations that claim conformance. -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
In message cah8yc8mpmuxmnjdhxf0-fsiu0fjsgwxcpjggipup06w8w83...@mail.gmail.com
on Fri, 25 May 2012 11:39:05 -0400, Jeffrey Walton noloa...@gmail.com said:
noloader Perhaps I'm looking at the wrong free function (or I'm not
noloader reading/deducing correct behavior), but it looks like a double free to
noloader me:
noloader
noloader void CRYPTO_free(void *str)
noloader {
noloader if (free_debug_func != NULL)
noloader free_debug_func(str, 0);
noloader #ifdef LEVITTE_DEBUG
noloader fprintf(stderr, LEVITTE_DEBUG: 0x%p\n, str);
noloader #endif
noloader free_func(str);
noloader if (free_debug_func != NULL)
noloader free_debug_func(NULL, 1);
noloader }
noloader
noloader Regarding parameter validation, below is a perfect example since free
noloader (from above) does not appear to include a size.
Why would it include a size?
noloader Are implementations verifying `num` is not less than 0 since
noloader it is defined as an integer? Its clear the OpenSSL code is
noloader not verifying its parameters. What's not clear to me is why
noloader one can even specify a negative size.
noloader
noloader void *CRYPTO_malloc(int num, const char *file, int line)
noloader {
noloader void *ret = NULL;
noloader
noloader allow_customize = 0;
noloader if (malloc_debug_func != NULL)
noloader {
noloader allow_customize_debug = 0;
noloader malloc_debug_func(NULL, num, file, line, 0);
noloader }
noloader ret = malloc_func(num);
noloader #ifdef LEVITTE_DEBUG
noloader fprintf(stderr, LEVITTE_DEBUG: 0x%p (%d)\n, ret, num);
noloader #endif
noloader if (malloc_debug_func != NULL)
noloader malloc_debug_func(ret, num, file, line, 1);
noloader
noloader return ret;
noloader }
It's correct that CRYPTO_malloc(), CRYPTO_realloc() and CRYPTO_free()
don't verify the parameters, they are just wrappers around the real
memory routines (malloc(), realloc() and free() by default), and rely
on those to verify parameters as they see fit.
Cheers,
Richard
--
Richard Levitte rich...@levitte.org
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 05/26/2012 12:28 PM, Jakob Bohm wrote: On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I have to rely on secondary sources and experience using various implementations that claim conformance. It looks like a safe assumption to make: The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008 Copyright © 2001-2008 The IEEE and The Open Group [CX] The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2008 defers to the ISO C standard. The free() function shall cause the space pointed to by ptr to be deallocated; that is, made available for further allocation. If ptr is a null pointer, no action shall occur. Otherwise, if the argument does not match a pointer earlier returned by a function in POSIX.1-2008 that allocates memory as if by malloc(), or if the space has been deallocated by a call to free() or realloc(), the behavior is undefined. Any use of a pointer that refers to freed space results in undefined behavior. RETURN VALUE The free() function shall not return a value. ERRORS No errors are defined. And from my copy of a draft of the C99 standard: 320 Committee Draft — January 18, 1999 WG14/N869 Description 2 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. Returns 3 The free function returns no value. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
From: Jakob Bohm [mailto:jb-open...@wisemo.com] On 5/25/2012 5:30 PM, Ken Goldman wrote: 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. Which version of the ANSI Spec, and where did you get a copy? I quoted from C99 in a recent message; can't remember where I got it (12 years ago ...), perhaps Techstreet. There are 'final drafts' of C99 and C11 legally available for free on the web I believe. Various revisions of POSIX are available free for reference online; the current POSIX.1-2008 at http://pubs.opengroup.org/onlinepubs/9699919799/ and the older POSIX.1-2004 at http://pubs.opengroup.org/onlinepubs/009695399/ Regards, jjf __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On 5/25/2012 12:30 AM, Richard Levitte wrote: In messagecagxgq09umap5b1bhsyjj54srwrg-syzqnodk5rh_gnt29xa...@mail.gmail.com on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavansudarshan.t.ragha...@gmail.com 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 0x 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 rich...@levitte.org wrote: In message cagxgq09umap5b1bhsyjj54srwrg-syzqnodk5rh_gnt29xa...@mail.gmail.com on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 0x 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 rich...@levitte.org 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 st...@openssl.org 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 0x 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 openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 sudarshan.t.ragha...@gmail.com 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 st...@openssl.org 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 0x 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 openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
In message 4fbf35d0.3020...@wisemo.com on Fri, 25 May 2012 09:33:36 +0200, Jakob Bohm jb-open...@wisemo.com said: jb-openssl On 5/25/2012 12:30 AM, Richard Levitte wrote: jb-openssl In jb-openssl messagecagxgq09umap5b1bhsyjj54srwrg-syzqnodk5rh_gnt29xa...@mail.gmail.com jb-openssl on Thu, 24 May 2012 17:46:49 +0530, Sudarshan jb-openssl Raghavansudarshan.t.ragha...@gmail.com 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 0x 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 rich...@levitte.org 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 rich...@levitte.org wrote: In message cagxgq09umap5b1bhsyjj54srwrg-syzqnodk5rh_gnt29xa...@mail.gmail.com on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 0x 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
Hi all! * Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On Thu, May 24, 2012 at 8:16 AM, Sudarshan Raghavan
sudarshan.t.ragha...@gmail.com 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 0x 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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 steffen.dett...@ingenico.com wrote: Hi all! * Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
On Fri, May 25, 2012 at 11:25 AM, Ken Goldman kgold...@us.ibm.com 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
From: Jakob Bohm [mailto:jb-open...@wisemo.com] 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
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 0x 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Custom free routine is invoked with NULL argument in openssl 1.0.1
In message cagxgq09umap5b1bhsyjj54srwrg-syzqnodk5rh_gnt29xa...@mail.gmail.com on Thu, 24 May 2012 17:46:49 +0530, Sudarshan Raghavan sudarshan.t.ragha...@gmail.com 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 0x 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 rich...@levitte.org 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
