Unbreakable MySQL?
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.
Policy is clearly stated here http://www.oracle.com/us/support/assurance/fixing-policies/index.html
I don’t find it clear. What security bugs can one expect to be fixed in the next release? What security bugs will be fixed whenever or not at all? What security bugs will be fixed immediately and how fast this “immediately” is?
The few years old MySQL rules are summed up in this article (originally from dev.mysql.com, but it’s no longer there): http://web.archive.org/web/20100328011334/http://dev.mysql.com/tech-resources/articles/security_vulnerabilities.html
MariaDB rules are here: https://kb.askmonty.org/en/bug-fixing-policy/
Quoting from that policy:
“It is Oracle’s policy not to announce security fixes until they are
available for all affected and supported product version and platform
combinations”
“In order to provide the best security posture to all Oracle customers, Oracle fixes significant security vulnerabilities in severity order. As a result, the most critical issues are always fixed first.”
You may disagree that it is correct or not to do so, but it is clear.
That part is clear, yes. What is not clear – when a user may expect a particular issue to be fixed. What issues one may expect to be never fixed?
These questions both MySQL and MariaDB policies do answer. Oracle’s – does not.
Now 5.5.30 is released. NeitherCVE-2012-5615 nor CVE-2012-5627 are fixed. Nor CVE-2012-5611 fix is corrected. If I were MySQL user, it would be crucial for me to know when to expect a fix.
does mariadb vulnerable against this issues?
No, of course not. We have all that fixed in MariaDB 5.5.29
Test cases aren’t completely private. They’re available to distributions, and I’d bet you can ask for them too.
Is that so? Can you provide any more info on that?
It would be great, if it would be true.
But so far I’ve got no reply from Oracle about it (I’ve asked).
And I’ve asked distributions too – they (those that I’ve asked) use MySQL tarballs, and have *no* access to test cases. But I didn’t ask Oracle Linux people 🙂
I’ve got an authoritative answer from Oracle now. Distributions have no access to the test cases. Oracle has no plans of changing that.
Unfortunately, it looks like you were misinformed.
They also havent solved the information_schema incorrect mutexes handling on subqueries issue (MDEV-4029) that allow any user to lock the whole server Information_schema table with a simple SELECT.
An issue that exists since MySQL 5.1 and that has been solved on Maria 5.5.29 less than a week after the bug has been filled but it still hasnt been corrected on MySQL 5.5.30 and according to their bugtrack it has been solved on MySQL 5.7 (5.6 wasnt even GA at the time of this answer)… knowing that the bug has been reported in 2010 on the MySQL bugtrack system (http://bugs.mysql.com/bug.php?id=58738).