4 ms·

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?

pjmlp 8y ago
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.
- rurban 8y ago
  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.
- loeg 8y ago
  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().
  - _kst_ 8y ago
    memset_s() is defined in C11 Annex K, which is optional and is not provided by most implementations.
rurban 8y ago
AFAIK my own memset_s is the only secure one: https://github.com/rurban/safeclib/tree/master/src/mem 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 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 http://perl11.org/blog/foldcase.html https://crashcourse.housegordon.org/coreutils-multibyte-support.html https://crashcourse.housegordon.org/coreutils-multibyte-supp...
tonysdg 8y ago
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.
- rurban 8y ago
  snprintf is the same trash, just slower. See eg. http://blog.infosectcbr.com.au/2018/11/memory-bugs-in-multiple-linux-kernel.html http://blog.infosectcbr.com.au/2018/11/memory-bugs-in-multip... discussing the need of an improved scnprintf in the Linux kernel.

pjmlp 8y ago

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.

rurban 8y ago
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.
loeg 8y ago
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().
- _kst_ 8y ago
  memset_s() is defined in C11 Annex K, which is optional and is not provided by most implementations.

rurban 8y ago

AFAIK my own memset_s is the only secure one: https://github.com/rurban/safeclib/tree/master/src/mem 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 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 http://perl11.org/blog/foldcase.html https://crashcourse.housegordon.org/coreutils-multibyte-support.html https://crashcourse.housegordon.org/coreutils-multibyte-supp...

tonysdg 8y ago

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.

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