A rash of zero-day exploits and vulnerabilities in the MySQL database were disclosed to the Full Disclosure mailing list over the weekend, but experts are saying they’re much ado about nothing.
Of the half-dozen zero-days reported by a researcher known as King Cope, all but one require legitimate credentials to access the Oracle-owned database, or are configuration errors rather than vulnerabilities in the code.
“Some of the techniques are interesting, but you have to have a valid log-in for them to work,” said HD Moore, creator of the Metasploit Framework and CSO at Rapid7. “There’s usually a better way to get access.”
Most of the bugs lead to system crashes or denial of service conditions. However, CVE-2012-5611 is a stack-based buffer overflow in MySQL 5.5.19 and 5.1.53 that if exploited allows remote authenticated users to execute shell code. According to the CVE advisory, a long argument made to the GRANT FILE command would trigger the vulnerability.
“It’s trivially exploitable,” said Sergei Golubchik, vice president of architecture at the Monty Program, which manages a MySQL fork called MariaDB. “One can easily inject code there.”
Golubchik said a patched version of MariaDB was released Friday and that the bug was discovered by MariaDB engineers two weeks ago.
Golubchik told Threatpost that CVE-2012-5615, a remote pre-authentication user enumeration vulnerability, is a 10-year-old issue and documented in the MySQL developer’s manual.
“Admittedly, the text is way more complex than it should be, the older version was easier to read. But anyway, it documents that an authentication method is specified per user (in the server account
management tables). And that a client gets a special reply ‘change authentication method’ if the user name is correct and the authentication method does not match the correct authentication method
for this account,” Golubchik said. “Which means, exactly, that one can find what account names surely exist on the server by looking for these ‘change authentication method’ server replies. They are never returned for non-existent accounts.”
Two other vulnerabilities leading to denial-of-service conditions were reported: CVE-2012-5212 and CVE-2012-5214 both can crash MySQL instances.
CVE-2012-5212 is a heap-based buffer overflow in MySQL 5.5.19 and MariaDB 5.5.28a. Remotely authenticated users can cause memory corruption and crash the database using variations on a number of commands. CVE-2012-5614, meanwhile, also impacts the same two versions, and causes a crash via a SELECT command with an UpdateXML command containing a large number of nested elements in the XML code, according to the advisory.
Finally, a privilege escalation zero-day was also disclosed. The CVE-2012-5613 advisory notes that MySQL disputes this is a security vulnerability, calling it a configuration issue. MySQL 5.5.19 and MariaDB 5.5.28a are vulnerable to an attacker who is remotely authenticated gaining administrator privileges by leverage the FILE privilege to create files as the admin.
“The ‘exploit’ uses FILE privilege and SELECT … INTO OUTFILE to create a TRG file (a definition file) with a trigger that is executed with the database root privileges (the trigger metadata include the definer credentials),” Golubchik said. “From the body of this trigger, an attacker can grant himself any privileges he wants. This is not a vulnerability, because, like any other FILE privilege abuse, it requires an incorrectly configured server that allows users to access files in the datadir.”
The wait is on now for Oracle to address these vulnerabilities. Oracle acquired MySQL as part of its 2009 $7.4 billion acquisition of Sun Microsystems. Before that, the open source project was run by MySQL AB of Sweden; it’s at the core of many Web applications built on the Linux, Apache, MySQL, Perl/PHP/Python (LAMP) platform.
“We don’t get anything from [Oracle]; only a list of incomprehensible vulnerability descriptions in the
CPU (Critical Patch Updates), and changes to the source code,” Goluchik said. “When we learn about a security issue in MariaDB, I report it to Oracle on bugs.mysql.com. But that’s all the ‘working with Oracle’ that exists. A bit unidirectional. I’ve learned to expect no more feedback from Oracle than I get from /dev/null. But I can see that the MySQL code gets changed and bugs get fixed – so we continue to report security bugs to Oracle to keep MySQL users protected from security threats.”
