The report says that Huawei devices have unsafe functions like “memcpy” and "strcpy". Is this a coding preference or dangerous practice? To what extent can these examples reflect on code quality?
strcpy() - sure it is fairly often used unsafely, strlcpy() or snprintf() or similar should generally be used. But memcpy()? It takes an explicit length, which you have to calculate. What's the alternative? memcpy_s() does part of the check for you, but you end up writing more code around it. It's trying too hard and not achieving a net positive. I have seen "use of unsafe function memcpy()" show up in some dumb security scans recently, and it's a strange development. There is lots of C code where avoiding memcpy() would be quite awkward and really not help anything at all, it's just a fundamental operation.
This technical report is nonsensical, and asks for continuation of widespread insecure practices. The authors (the glibc maintainer) should be removed from the committee for spreading such harm. He simply doesn't like secure practices, and continue to use sometimes checked calls. If he would have some technical competence he would implement the needed safety checks seperated into compile-time (no performance penalty) and runtime (when the compiler doesn't know). He only does the first, and leaves all the dynamic cases unchecked.
But then he would stumble over the inability of gcc to properly handle compile-time expressions.
It doesn't say that those particular uses are dangerous. But it says that their overall standards don't prohibit the use of potentially dangerous methods.
In a non-critical application that kind of stuff is usually fine. But for critical infrastructure there are normally rules against using potentially unsafe methods like those entirely.
Huawei would need to be more transparent to show that their practices are secure and that these uses are wrapped in some kind of protective framework. But until that happens it's reasonable to be skeptical from a security (and stability) perspective.
They will just use memcpy_s with the dest len and the len set to the same var. Or strncpy with the limit set to strlen(src) etc. These guys will tell you it's suddenly using 'modern security practices'.
Conversely depending on the code strcpy / memcpy can be 100% safe.
I think these guys are selling static analysis, so they find themselves using these oversimplified metrics... it's a shame because it looks like there was no lack of real issues.
If I ever saw a project where someone wrote a fake wrapper around an insecure function that gave the illusion that it had proper checks in place (which is what's being described here) instead of using the actual function I would be concerned.
And if I ever saw code where the size parameters weren't legit (as in someone used the same variable for both) I would also be concerned unless proper checks where taking place elsewhere. But it is a bad smell.
That's the only point in that particular finding. They did detail other ways in which the whole development standards seem bad.
And, yes, you can always shoot your own foot, but it's still best not to aim directly at it.
Its a pretty good indication how easy its gonna be to find a memory corruption vulnerability. There are very few C programmers that I would trust to write secure code at all (none of those would ever touch those functions), yet alone with critical infrastructure equipment like this.
Here's a dry technical report on how the new-ish _s variants are not really helpful: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm