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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Phillip Susi <phill@xxxxxxxxxxxx>
> > Michael Wojcik writes:

> > 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.

> Isn't this normally/easilly handled simply by passing sizeof( buffer ) -
> 1?  Then the last byte is always \0 whether or not the copy was truncated.

No, for a number of reasons:
- The buffer may be dynamically allocated, in which case sizeof buffer is very much the wrong thing.
- A trailing nul byte is not always desirable (not everything is a string), and not all of the Appendix K
functions will append one. Neither will strncpy, if the limit is reached; strncpy has broken semantics.
- The buffer size (less 1) is the wrong value to pass when using strncat with a destination that does not start
with a nul character. Developers also frequently miss the fact that strncat can append length+1 bytes to
the buffer. (strncat's semantics are dangerously non-obvious.)
- Non-trivial programs *will still have to handle truncation properly*. It's rarely the case for a non-trivial
program that "silently truncate the data" is a good way to handle it. A well-behaved program will treat
truncation as an error or a special case that needs further handling, or at least needs to be flagged to the
user or some other diagnostic sink. The C90 length-checked functions don't communicate truncation to
the caller; the Annex K ones only return "a non-zero value" if a constraint is violated, so there's no
standardization as to how a particular constraint violation is communicated.

Also, sizeof is an operator, not a function. There's no reason to parenthesize its argument unless the
argument is a type name, in which case it's parenthesized as a special syntactic case.

Incidentally, I misremembered; it's Annex K, not Appendix K, and it was introduced in C11, not C99. So the
Annex K functions weren't even standardized until C11, and they're still optional there (though Annex K is
normative).



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux