MySQL-Exploit-Remote-Root-Code-Execution

Reading more at your link, seeing this:
Official patches for the vulnerability are not available at this time for Oracle MySQL server.
Click to expand...

So, hopefully this will make the rest still running MySQL a extra motivation to upgrade/migrate to MariaDB instead. Thankfully I did my migration a long time ago. :)
 
ditto said:
It (CVE-2016-6662) is fixed in MariaDB 5.5.51, MariaDB 10.0.27 and MariaDB 10.1.17 - wich all are available in custombuild: https://mariadb.com/kb/en/mariadb/security/
Click to expand...


When I check custombuild, it does not provide an update for the 5.5.41-MariaDB currently on the system. It's not installed via system, as it is excluded from the yum repos. (CentOS 7)
 
Last edited:
ditto said:
MariaDB 5.5.51 is in custombuild when I check manually here: http://files1.directadmin.com/services/custombuild/mariadb/5.5/

I can't check any further because I run MariaDB 10.1.x myself.

If you do ./build update , then you should get it when you look at ./build versions
Click to expand...

No clue what it was that prevented it from updating. Did an update and did not provide version change. Changed the version from 5.5 to 10.0 and an update showed up from 5.5.41 to 10.0.27. Completely unrelated to the main topic, but anyway, upgraded to 10's safe version.
 
There are two settings in options.conf that control it. You need to set mysql_inst to mariadb and the mariadb setting to 5.5 if you want to upgrade from 5.5.41 to 5.5.51. For everyone else: this only applies to you if you have MariaDB currently installed. For more details see the following help page: https://help.directadmin.com/item.php?id=240.
 
Last edited:
Hello,

I've updated the versions.txt on files1 with the updates from MySQL:
5.5.52
5.6.33

------------------
For MariaDB, I was reading this:
http://thehackernews.com/2016/09/hack-mysql-database.html

it mentions MariaDB had already fixed it at the end of August.

I've confirmed the CVS is mentioned here:
10.1.17 - https://mariadb.com/kb/en/mariadb/mariadb-10117-release-notes/
10.0.27 - https://mariadb.com/kb/en/mariadb/mariadb-10027-release-notes/
5.5.51 - https://mariadb.com/kb/en/mariadb/mariadb-5551-release-notes/

so for MariaDB, if you already have these versions, you should be fine. It was added to the versions quite a while back (5.5.51 Aug 12th, 10.0.27 Aug 25th, and August 30th for 10.1.17).

John
 
Hello John, according to the original exploitpost the versions 5.5.52 and 5.6.33 are vulnerable; are they now fixed with your update or not, please could you clarify? Thank you
 
Oracle MySQL versions are not fixed by the update, I don't see how it would be possible for DirectAdmin to patch this. You have to patch them on your servers, or better migrate to MariaDB.
 
Arieh said:
From what I've understand so far is that access to my.cnf is required for this exploit.
Click to expand...

That's how I understood it too... specifically mysql user has to be able to write to it, and DirectAdmin setups have 644 on my.cnf owned by root. So I guess even exploitable versions are not vulnerable due to DA's my.cnf permissions?
 
I think also important to keep a eye on CVE-2016-6663 vulnerability

VII. BUSINESS IMPACT
-------------------------

As discussed above the vulnerability could be exploited by attackers with both
privileged and unprivileged (with FILE privilege only) access to mysql accounts.
It could also be combined with CVE-2016-6663 vulnerability which will be released
shortly and could allow certain attackers to escalate their privileges to root
even without FILE privilege.

The vulnerability could also be exploited via an SQL injection vector, which
removes the need for the attackers to have direct mysql connection and increases
the risk of exploitation.

Successful exploitation could gain a attacker a remote shell with root privileges
which would allow them to fully compromise the remote system.

If exploited, the malicious code would run as soon as MySQL daemon gets
restarted. MySQL service restart could happen for a number of reasons.
Click to expand...
 
Last edited:
johannes said:
Hello John, according to the original exploitpost the versions 5.5.52 and 5.6.33 are vulnerable; are they now fixed with your update or not, please could you clarify? Thank you
Click to expand...
Ah, my apologies, I think you're right. I assumed the release they made the same day were were getting questions about it would have included the fixes. That doesn't appear to be the case.

We'll need to wait for fixed releases from Oracle/MySQL.

However, if the theory that write access to the /etc/my.cnf as "mysql" is required... then as all /etc/my.cnf files are usually root, that might be sufficient for now... but I wouldn't be terribly content with it.

So the minimum would be:
Code: 
chown root:root /etc/my.cnf
touch /var/lib/mysql/my.cnf
chown root:root /var/lib/mysql/my.cnf
and then we wait for Oracle to release an update.

Note the /var/lib/mysql/my.cnf location appears to be DEPRECATED, so you might get warnings when you restart mysqld.
Leave it for now, as I'm not 100% sure if mysqld still reads it in.. because if it does, that's the spot we don't want the attackers creating, since the folder is chowned to mysql, which would grant write access to it.

John
 
Just reading their release in more detail, and it would appear that in fact, MySQL did fix it right away:
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-52.html
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-33.html

With these entries:
  • For mysqld_safe, the argument to --malloc-lib now must be one of the directories /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu, or /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and --mysqld-versionoptions can be used only on the command line and not in an option file. (Bug #24464380)
  • It was possible to write log files ending with .ini or .cnf that later could be parsed as option files. The general query log and slow query log can no longer be written to a file ending with .ini or .cnf. (Bug #24388753)
Click to expand...
so mysqld_safe appears to have been changed correctly.
Confusion might have been because they didn't reference the actual CVE-2016-6662 code.

This does contradict the "<=" in the actual exploit report url, so I would assume that MySQL is correct in this case, and the report should have stated just "<", but that's above my knowledge to confirm.
Regardless, we'll continue to monitor and will update things if we get new versions or more information.

John
 
You must log in or register to reply here.
Back
Top