4 ms·
Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires t
by rurban 5y ago
Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined.
The applause goes to the glibc maintainers, who still think they are above that.
- ndesaulniers 5y agoDoesn't memcpy_s not take into account the sources size though? You could still read past the end of an object with it, right?
- rurban 5y agonope, it checks both. How could you call it secure without checking both sizes? memcpy_s(dest,dmax,src,slen) and my implementation safeclib even at compile-time, similar to glibc's FORTIFY.
- loeg 5y agoAnnex K is pretty awful[1]. There are plenty of fine solutions here in hindsight, but glibc adopting Annex K isn’t one of them. NSS has a plethora of build targets, including Windows - which does not implement Annex K either (despite inspiring it). [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
- rurban 5y agoWrong. First it's good, not awful. Awful are only the ones not using it. Second, Windows implements Annex K as only major provider. The others are some minor embedded targets, plus Android Bionic recently. Implementations, such as safeclib, are cross platform. you can use it everywhere. Security and crypto people per se don't use it (incompetence or not invented here), but security aware people, such as on embedded or in the industry.