Usage of Secure C (memcpy_s, strcpy_s etc) functions on OpenSSL

[Jordan Brown]

On 11/26/2019 7:41 AM, Michael Wojcik wrote:
> The Appendix K functions (memcpy_s, etc) do NOT "remove buffer
> overflow kind of issues completely", and anyone who thinks they do is
> making a serious error. The Appendix K functions impose an additional
> check. That's all they do. It is possible, and in some use cases quite
> easy, for the developer to pass the wrong value for the destsz
> parameter and invalidate that check.
>
> Some C experts have argued that the length-checking versions of the
> library functions, either the C90 ones such as strncat or the Appendix
> K ones, are essentially pointless anyway; that the caller needs to
> handle truncation and so ought to know whether truncation (or
> overflow) would occur before attempting the operation.

I was initially a fan of them when I first heard of them, but have since
soured on them, as have others.  They are very nearly useless for
libraries, because their behavior is controlled on a process-global
basis.  The library cannot assume that the "bad" cases will result in
aborts, because the application might have chosen to have them return
errors instead.  That means that the library has to check for and handle
all of those "should be impossible" error cases.

Here's a paper on the subject: 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191126/f0770be0/attachment-0001.html>