Hacker News Reader

Comment by begriffs | Hacker News Reader

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?

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.

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

Reply on news.ycombinator.com