Hacker News Reader

Comment by rurban | Hacker News Reader

He really should have noted the misdefinition of the truncating versions in string.h. Eg. strncpy doesn't leave enough room for the final \0, so the string may be the unterminated. A serious POSIX error.

This worse than the wchar_t iswalpha trouble with older UCS-2 implementations (Windows, AIX).

Or the implementation trouble with memset, which either can be optimized away without a compiler barrier, or on modern hyperthreaded microarchitectures which violate load-store ordering and thus need a full memory barrier (mfence). no single libc does it properly, not even crypto libs, such as libsodium.

View on HN

That isn't an error in strncpy — it's for manipulating fixed length fields, which is why it zeroes the entire remaining field.

strncpy is commonly misused as a strlcpy, though, in part because glibc continues to refuse to add strlcpy. strlcpy provides the functionality most people want from strncpy but do not get.

Thanks for pointing this out.

Can you give an example of the strncpy problem?

Also is there a precaution programs can take to use memset more safely?

strncpy does not add a '\0' if the string does not fit into the target buffer, it just cuts it down to the max size.

So to be on the safe side you need to wrap strncpy calls into a function that always puts a '\0' on the very last index of the destination string buffer.

As for memset, the best workaround is to use OS specific variants that aren't subject to such issues, for example SecureZeroMemory() on Windows.

SecureZeroMemory() is insecure on hyperthreaded systems, and probably on normal SMT systems also. It only uses a compiler-barrier, ensuring that it is not optimized away. This is not secure, it is just a basic precaution against wrong compiler optimizations.

In reality the compiler should know about the libc memset and memzero and refuse to optimize it away, and memset_s/SecureZeroMemory needs a memory barrier.

explicit_bzero() is another OS-specific variant.

memset_s() is now part of standard C, but it is a pain to use because it isn't just a don't-optimize-away memset().

memset_s() is defined in C11 Annex K, which is optional and is not provided by most implementations.

AFAIK my own memset_s is the only secure one: https://github.com/rurban/safeclib/tree/master/src/mem but nobody cares. It was not mentioned at this years CCC talk about memset. Everybody thinks a simple compiler barrier is enough, it is not.

The strncpy truncating problem is widely known: https://www.google.com/search?q=strncpy+truncating+problem

But conceptually the biggest problem is the inability to deal with strings properly at all. You mentioned the iswalpha problem and the need for external libs, but the standard cannot even search for unicode strings properly (no normalization wcsnorm, no wcsfc, no UTF-8 u8 API), ditto sorting needs an API for the unicode version being used. It's relative and changes every year. And every libc is hopelessly behind. The most basic coreutils still cannot search for foreign strings (grep, sort, wc, cut, expand, ...): http://perl11.org/blog/foldcase.html https://crashcourse.housegordon.org/coreutils-multibyte-supp...

Replace strncpy and strcpy altogether with calls to snprintf. It takes a fixed buffer size, terminates correctly with the null character, and safely does everything strncpy does and more. It's a POSIX standard, so it should be portable to most systems too.

And yes, maybe it'll impact performance. Worry about that _after_ you profile your code and have the numbers to show it -- I'd bet good money that 95% of developers will never need to worry about it.

snprintf is the same trash, just slower. See eg. http://blog.infosectcbr.com.au/2018/11/memory-bugs-in-multip... discussing the need of an improved scnprintf in the Linux kernel.

Here's my rant on strncpy:

http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

Reply on news.ycombinator.com