MySQL - CVE-2016-6662
Hi,
Critical Vulnerability (0-Day) all version Mysql
helpnetsecurity.com/2016/09/12/mysql-0-day-cve-2016-6662/
legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
-
We've been working with our Sysadmins - here is what we have learned. fdgweb.com/cve-2016-6662-remote-root-code-execution-privilege-escalation-0day-exploit You basically should check that your /etc/my.cnf has the correct ownership/permissions. No MySQL users created by cPanel should have SUPER or FILE permissions unless specifically set by a System Administrator since neither of these permissions can be granted through cPanel or any other method other than root access. However, as I understand it - it you have granted these permissions via SSH / MySQL via root - then you can be vulnerable. You can view grants like so: SHOW GRANTS [FOR user] Full explanation: MySQL :: MySQL 5.7 Reference Manual :: 14.7.5.21 SHOW GRANTS Syntax Would love for cPanel to weigh in though .. as this is all still reactionary. 0 -
MariaDB seem to have addressed some of this vulnerability in versions 5.5.51, 10.0.27, 10.1.17 Please see [MDEV-10465] general_log_file can be abused - JIRA for more details 0 -
The cPanel Security Team has posted an article about this to the , here: CVE-2016-6662 MySQL - cPanel Knowledge Base - cPanel Documentation 0 -
Hello, 1) I verified /etc/my.cnf was owned by root/root with rw-r-r permissions. I did not create a .my.cnf here, should I have? I read several articles about this issue and followed the steps outlined in the cpanel article, specifically, I used the following command as root: touch /var/lib/mysql/my.cnf /var/lib/mysql/.my.cnf to create both, empty dummy files owned by root/root with rw-r-r permissions 2) Do you recommend additional mitigations? It appears there is a new CVE that hasn't been publicly disclosed CVE-2016-6663 allowing to bypass the needed FILE permissions & just need the SELECT permission, which pretty much every database has. A bit scary. 3) I have a default mysql configuration. Do you recommend creating the empty my.cnf & .my.cnf elsewhere besides /var/lib/mysql? 4) Should I remove the two dummy my.cnf / .my.cnf files from /var/lib/mysql when patching mysql? Assume it doesn't matter. 5) Will you be publishing the mysql 5.6.33 fixed version to both WHM 58 & 56 or just WHM 58? Still have some old centos5 servers that can only run 56 stable. I assume since this is security related that it would be published to 56 as well. Is there an ETA? Thank you. 0 -
Hello, 1) I verified /etc/my.cnf was owned by root/root with rw-r-r permissions. I did not create a .my.cnf here, should I have?
Good. No, you have one there and checked its owner and permissions.I read several articles about this issue and followed the steps outlined in the cpanel article, specifically, I used the following command as root: touch /var/lib/mysql/my.cnf /var/lib/mysql/.my.cnf to create both, empty dummy files owned by root/root with rw-r-r permissions 2) Do you recommend additional mitigations? It appears there is a new CVE that hasn't been publicly disclosed CVE-2016-6663 allowing to bypass the needed FILE permissions & just need the SELECT permission, which pretty much every database has. A bit scary.
Does any of your users have SUPER of FILE grants, as mentioned in the article? There's a command posted there you can use to check. Those additional my.cnf are for that.3) I have a default mysql configuration. Do you recommend creating the empty my.cnf & .my.cnf elsewhere besides /var/lib/mysql? 4) Should I remove the two dummy my.cnf / .my.cnf files from /var/lib/mysql when patching mysql? Assume it doesn't matter.
The article explains whats needed.5) Will you be publishing the mysql 5.6.33 fixed version to both WHM 58 & 56 or just WHM 58? Still have some old centos5 servers that can only run 56 stable. I assume since this is security related that it would be published to 56 as well. Is there an ETA? Thank you.
0 -
Hello, I read several articles on this. None of my users have the SUPER or FILE grants, however, they all have the SELECT permission. Basically, there's a new CVE 2016-6663 and from what I understand, it doesn't need the FILE or SUPER grant (just the SELECT one) and basically bypasses the FILE permission and can also exploit this vulnerability. As such, I created the empty my.cnf .my.cnf files in /var/lib/mysql with 0644 owned by root:root as a pre-caution. From what I've read, it's possible CVE 2016-6663 is already being exploited as 0-day and it's not hard to bypass the lack of FILE user permission. Ultimately, I just want to push out the newest version of MYSQL asap. Thoughts or am I missing something? Is there an ETA on the new MYSQL version getting pushed out by cpanel? Thank you. 0 -
I followed the link to CVE-2016-6662 as posted by Infopro. I see that my.cnf is owned by root with 644 permissions, and when I run the command: mysql mysql -e 'select User,Host from user where User != "root" and ( File_priv = "Y" or Super_priv = "Y" );' I get nothing what so ever back, just back to the # prompt. Can I deduce from this, that I'm not vulnerable ? Incidentally, I'm not aware of creating any MYSQL users outside of Cpanel or WHM, I wouldn't even know how to. 0 -
No word yet: cPanel is currently working on new versions with updated MySQL RPMs. We will update this section once new versions are available. 0 -
Thanks :) 0 -
Fixed in 11.58.0.30 [LIST] - Fixed case CPANEL-8432: Update MySQL55 to 5.5.52-1.cp1156.
- Fixed case CPANEL-8434: Update MySQL56 to 5.6.33-1.cp1156. Thanks
0 -
Will this not be fixed in cPanel 11.56 or 11.54? Aren't those versions still in LTS and still supported? 0 -
Will this not be fixed in cPanel 11.56 or 11.54? Aren't those versions still in LTS and still supported?
Hello @sparek-3, CPANEL-8432 and CPANEL-8434 and planned for inclusion with cPanel version 56.0.35. I'll update this thread once that version is published. There are no plans to include these cases with cPanel version 54, however mitigation steps are available at: CVE-2016-6662 MySQL - cPanel Knowledge Base - cPanel Documentation Thank you.0 -
Hmm, luckily I'm not using cPanel 54. But I can see how this could get under someone's skin if they are. So essentially you are not support cPanel 54 any more? And the table for scheduled end-of-life for cPanel 54 ( cPanel Long-Term Support - Documentation - cPanel Documentation ) should have anticipated end-of-life for cPanel 54 as September 2016. I know you plan to make some changes to the way releases and LTSs are done starting in 2017. I'm not sure if I'll really like those changes, but I'll admit something probably needs to be done. It sounds to me like if you aren't going to provide security updates for cPanel 54 any more, then you should just cut it from your list of supported versions. But I'm also hoping that when 2017 comes around and you change your LTS strategy that you don't decide to pick and choose what security patches to release for LTS versions and other supported versions. I don't have a problem with cutting support for a version, and to your credit the LTS table does say Anticipated End-of-Life which I suppose can mean that you can cut off support before then (or after). But for all of the versions that are "in life" I think you are obligated to honoring security patches. 0 -
I agree 100% with sparek-3. I'm migrating Centos5 systems to Centos6/7 before Centos5 is e-o-l March 31st, 2017, however, some clients refuse to perform a migration until almost the last minute. As such, I rely on cpanel to continue to push out security updates to cpanel 56 until Centos5 is e-o-l. 0 -
Hello @sparek-3 and @Venomous21, Thank you for taking the time to offer this feedback. The MySQL updates are now planned for inclusion with cPanel version 54. I'll update this thread again once the updated version 56/54 versions are published. On the topic of LTS versions, we recently published a new blog regarding the future of LTS versions at: cPanel"s tiered update system; New plans for the LTS tier | cPanel Blog Thank you. 0 -
Hello, Updates to MySQL were recently published to cPanel versions 54 and 56: 56 Change Log - Change Logs - cPanel Documentation 54 Change Log - Change Logs - cPanel Documentation Thank you. 0
Please sign in to leave a comment.
Comments
17 comments