A set of MySQL 0-Day vulnerabilities has been posted on the full-disclosure list with CVEs already assigned, as explained by Red Hat's SRT
So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it's a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I've spoken with some other Red Hat SRT members and we feel it is best to get CVE #'s assigned for these issues quickly so we can refer to them properly.
If Oracle security has already assigned CVE's for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure.
- MySQL 5.1/5.5 WiNDOWS REMOTE R00T (mysqljackpot)
- MySQL Windows Remote System Level Exploit (Stuxnet technique) 0day
- 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 Exploit
- CVE-2012-5614: MySQL Denial of Service Zeroday PoC
- CVE-2012-5615: MySQL Remote Preauth User Enumeration Zeroday
So far it appears from the MariaDB response and update notice (Oracle has yet to respond) that CVE-2012-5611 will be deprecated as a duplicate of CVE-2012-5579 but 5612 and 5614 require patches. 5615, a user disclosure issue, received this response from MariaDB
hardly a 'zeroday' issue, it was known for, like, ten years
And, last but not least, 5613 is a point of configuration.
The MySQL 5.0 Reference Manual Security Guidelines clearly state "Do not grant the FILE privilege to nonadministrative users" but someone may still make that mistake, as demonstrated in this video by Eric Romang
Still no word from Oracle…but MariaDB speculates on their behalf that their next releases shouldn't be vulnerable to the CVE that they know about.
At a time when trust and transparency are more in demand than ever, security lists indicate a continuing trend in what some have described as this:
Oracle's lack of communication regarding the future…