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.

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.

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

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.

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