https://pentestmag.com/write-secure-code-cc-programming-languages/
Secure coding in C/C++ programming languages is a big deal. The two languages, which are commonly used in a multitude of applications and operating systems, are popular, flexible, and versatile – and often vulnerable to exploitation.
Sometimes the solution is to code using a safer language like Java. However, this is not always the best alternative.
It is important to learn how to create a bulletproof, un-exploitable code in the C/C++ programming languages.
7 Comments
Tomi Engdahl says:
Avoiding The Top 10 Software Security Design Flaws
https://semiengineering.com/avoiding-the-top-10-software-security-design-flaws/
Why so many design flaws have remained on the list of top security issues for years, and how you can avoid them.
Avoiding the Top 10 Software Security Design Flaws
https://www.synopsys.com/software-integrity/resources/white-papers/top-10-software-design-flaws.html
The IEEE Center for Secure Design brought together some of the foremost experts in software security in a working group to tackle the issue of secure software design.
This whitepaper covers their findings
Tomi Engdahl says:
A Guide to the MISRA Coding Standard: What You Need to Know
http://www.techonline.com/electrical-engineers/education-training/tech-papers/4458213/A-Guide-to-the-MISRA-Coding-Standard-What-you-need-to-know
Compliance to MISRA is required across the automotive industry, but is rapidly taking root in many other industries. Because MISRA was developed to provide a recognized standard to ensure safety critical systems are free of coding defects, more and more organizations in a variety of industries are demanding that software is developed in accordance with the MISRA standard.
Tomi Engdahl says:
The article at https://pentestmag.com/write-secure-code-cc-programming-languages/ says:
Desist from using strcpy() and strcat(). Substitute them with strncpy() and strncat() instead
Using strcpy() and strcat() functions in C/C++ fail to limit the length of the input string to be copied or added to the output buffer. This way, they make the programs susceptible to buffer overflow attacks. As such, it’s better you use the more secure strncpy() and strncat() functions.
My comments on “better you use the more secure strncpy() and strncat() functions”:
The use of strncpy() and strncat() functions is a good idea when they are used correctly.
If you use strncpy() incorrectly, it is not safer and can cause other type of security issues.
The strncpy() function pads the result string with zero (string termination character), but it
does not guarantee that the end result is always null terminated. If input string has length of
n or more, the output string contains n characters WITHOUT NULL termination. This can cause
serious problems when the string is used later!
So if you use strncpy(), you need to make sure that the output string is null terminated.
The strncat() function will always make null terminated string, which is good things.
The C library function char *strncat(char *dest, const char *src, size_t n) appends the string pointed to by src to the end of the string pointed to by dest up to n characters long.
From https://stackoverflow.com/questions/41652122/does-strncat-always-null-terminate
Quoting C11, chapter §7.24.3.2, (emphasis mine)
The strncat function appends not more than n characters (a null character and characters that follow it are not appended) from the array pointed to by s2 to the end of the string pointed to by s1. The initial character of s2 overwrites the null character at the end of s1. A terminating null character is always appended to the result.
and, the footnote
Thus, the maximum number of characters that can end up in the array pointed to by s1 is strlen(s1)+n+1
Tomi Engdahl says:
When we are talking about “safer” “n” versions, remember also this case with strncmp() on Intel AMP bug
https://arstechnica.com/security/2017/05/the-hijacking-flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought
The bug was in the code to compare the two strings. It used the strncmp function that compares the first N characters of two strings:
strncmp(string1, string2, N)
This would work just fine for hashes sent by the browser, which are always 32 characters in length. Even if the password field is empty, it would compare the two strings, they wouldn’t match, and it would reject the empty password or invalid password.
The problem is what happens if you don’t use a browser, but you generate an invalid request manually or using a proxy to alter the response, sending an empty string instead of the 32 character hash. Then the compare code does this:
strncmp(“6629fae49393a05397450978507c4ef1″,””,0)
This means the function will compare the first 0 characters between the two strings. So it is equivalent to:
strncmp(“”,””,0)
Of course, two 0 length strings are equal, so it wrongfully concludes the hashes are equal.
What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings.
Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you and you don’t need to supply a length parameter
The very fact that we’re debating if it was the handwork of a 3 letter agency or pure incompetence is a worrying sign of the times were in.
But to think that this flaw went on for 7 years… Were they just copying and pasting the AMT code from generation to generation? We’re talking about Intel here, the guys who seem to release a new processor with every full moon.
may chay bo cao cap says:
Definitely believe that which you stated. Your favorite reason appeared to be on the web
the easiest thing to be aware of. I say to you, I certainly get annoyed while
people think about worries that they plainly don’t know about.
You managed to hit the nail upon the top and defined out the whole thing without having side effect , people could take a signal.
Will likely be back to get more. Thanks
maryjane says:
nice information.
Tomi Engdahl says:
3 security tips for software developers
Don’t make these common security mistakes that leave you vulnerable to attack.
https://opensource.com/article/17/6/3-security-musts-software-developers?sc_cid=7016000000127ECAAY
Every developer knows the importance of following best security practices. But too often we cut corners, maybe because we have to work hard until those security practices sink in. Unfortunately, that usually takes something like seeing a security malpractice that’s so bad it gets marked in indelible ink in our brains.