The MySQL vulnerability (CVE-2012-2122) could enable users to log in without the correct password simply by trying repeatedly. “This flaw was rooted in an assumption that the memcmp() function would always return a value within the range -128 to 127 (signed character)…. if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied”, explained HD Moore in a blog.
In response to the MySQL flaw discovery, Coverity decided to write a static analysis checker to find “truncation of memcmp, strcmp, and strncmp return values, or cases where the return value was tested against constants other than 0”, explained Andy Chou, chief technology officer with Coverity, in a blog. Coverity used the checker to analyze 330 million lines of code in 6,286 open source projects.
The checker found 16 defects of the MySQL type, although none appeared to be major security vulnerabilities. Several were already fixed in newer versions of existing packages and there were at least six that were going to be fixed by developers, Chou added.
These defects can have many different effects: they might cause no bad behavior at all on some platforms or they might result in broken program logic all the way to severe vulnerability, Chou said.
“We discovered that developers are making that mistake occasionally…in a certain way”, Chou told Infosecurity. The assumption that developers have are not always true, he noted.
Coverity identified a number of lessons for developers. First, developers should not truncate the return value of memcmp and strcmp. Second, they should only test memcmp return values in comparison to “0”, Chou explained. “You should never compare the return value of memcmp equal to 1 or -1; there is no reason to do that and it is incorrect”, he said.
In his blog, Chou opined: “I'm hoping the security community evolves to emphasize buggy code as worthy of discussion. It's true that many of these defects are in older code that's already fixed, or in software that is not widely used. But that doesn't mean they're useless to review – they are helpful to developers to understand the kind of mistakes real developers make in real code. If the developers of MySQL had seen salient examples of this defect before they wrote that fateful code, they might have avoided CVE-2012-2122.”