I’m getting more and more concerned about the current Oracle approach to MySQL security. And the fact that I was solely responsible for the security@mysql.com for about ten years, doesn’t make it easier, on the contrary, it only emphasizes changes in the attitude.
Starting from the obvious — somewhat slower response to critical bug fixes, which can be expected, Oracle is a big company, right? Very little information about security vulnerabilities is disclosed, CPUs are carefully stripped from anything that might help to understand the problem, it takes hours to map them to code changes. Heck, even test cases are kept private now. This seriously smells Security through Obscurity to me.
But all that isn’t news. Here I want to talk about the recent wave of security vulnerabilities. If you search for, say, “mysql security full-disclosure”, you will find the original postings to the full-disclosure@lists.grok.org.uk mailing list, as well as further discussion and my replies. Not Oracle replies, though. In short, the vulnerabilities announced in the early December were:
- CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday
- CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday
- CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday
- CVE-2012-5614 MySQL Denial of Service Zeroday PoC
- CVE-2012-5615 MySQL Remote Preauth User Enumeration Zeroday
- CVE-2012-5627 MySQL Local/Remote FAST Account Password Cracking
All posted to the full disclosure mailing list, accompanied by
exploits in Perl. Out of these issues, the 3rd was a
configuration issue (FILE
privilege granted to
untrusted user, no --secure-file-priv
used), 4th was
already fixed in the latest MariaDB and MySQL releases (the
reporter used an outdated MySQL version), 1st — the most
dangerous one — was already fixed in the latest MariaDB release
(we were lucky to discover this issue independently few weeks
ealier and immediately released a fix). Everything else was
valid, exploitable, and very much public, after the original
postings were quoted in various blogs and news articles.
In a due time MySQL 5.5.29 is released. The 1st issue — CVE-2012-5611 — looks fixed. The second one — CVE-2012-5612 — is fixed too. Hurra! But 5th and 6th vulnerabilities — CVE-2012-5615 and CVE-2012-5627 — are not fixed. Which, apparently, leaves MySQL installations at the mercy of any script-kiddie, who can use google. And the 1st one (the worst of all) is fixed incompletely — the fact, that is simply impossible to miss, given the amount of testing that MySQL continuous integration framework (Pushbuild2) is performing.
Really, I wouldn’t expect a database vendor to blatantly ignore publicly announced vulnerabilities, that have CVE identifiers, known and easily available exploits, and were posted and reposted all over. So, Oracle, what was that, eh?
2013/Feb/05 UPDATE: MySQL 5.5.30 doesn’t seem to fix these issues either. Two months after the vulnerabilities went public. After MariaDB 5.5.29 release (with the fixes) and this blog post! I don’t think the Hanlon’s razor can explain that.