MariaDB Oracle MySQL CVE-2016-6662 - fixed in MariaDB/Percona already

Colin · Sep 13, 2016

Feel free to delete, move, merge.

I. VULNERABILITY
-------------------------

MySQL <= 5.7.15 Remote Root Code Execution / Privilege Escalation (0day)
5.6.33
5.5.52

MySQL clones are also affected, including:

MariaDB
PerconaDB
Click to expand...

Percona mailer just altered me to their fix.
MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

y-combinator discussion MySQL Remote Root Code Execution/Privilege Escalation Exploit | Hacker News

eva2000 · Sep 13, 2016

thanks for the heads up, still reading through that info !

from MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

1) Inject malicious configuration into existing MySQL configuration files on
systems with weak/improper permissions (configs owned by/writable by mysql user).

MySQL configuration files are loaded from all supported locations and processed
one by one when mysqld_safe script is executed.

Exact config locations depend on MySQL version.
For example, as described on:
MySQL :: MySQL 5.5 Reference Manual :: 4.2.6 Using Option Files
for MySQL 5.5 the config locations include:

/etc/my.cnf Global options
/etc/mysql/my.cnf Global options
SYSCONFDIR/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options
defaults-extra-file The file specified with --defaults-extra-file=file_name, if any
~/.my.cnf User-specific options

There is a common misconception that mysql config files should be owned by mysql
user for the server to work properly.

If any of the MySQL config files is owned by mysql user, an attacker could
append malicious config entries to it as follows:
Click to expand...

Centmin Mod /root/.my.cnf and /etc/my.cnf are owned by root user not mysql so not vulnerable for injection of malicious config file options.

Looks like the other 2 proof of concepts require some form of mysql user access like the above 1st proof of concept. Particularly the FILE permission which regularly granted non-root mysql users don't have unless you grant FILE permissions

MySQL Remote Root Code Execution/Privilege Escalation Exploit | Hacker News

I think this is poorly framed as RCE when it's just privilege escalation. The user already needs MySQL login access, shell access, and the ability to upload a malicious library that can be added to LD_PRELOAD through a setting in my.cnf. They do propose a trick to overwrite my.cnf with a logging function, but still...

This doesn't seem very threatening at all. If you're not already running services with strict file permissions this is the least of your worries.

edit: appears shell access isn't required to upload the malicious library, but you still need valid MySQL creds. Just because a SQLi might be there doesn't mean you can upgrade this to "remote code execution". That's just chaining vulns together; it doesn't magically upgrade the severity of this.
Click to expand...

eva2000 · Sep 13, 2016

more news at MySQL Zero-Day Allows Database Takeover

MariaDB and Percona fixed this but Oracle MySQL has not yet !

Polish security researcher Dawid Golunski has discovered two zero-days, CVE-2016-6662 and CVE-2016-6663, that affect all currently supported MySQL versions and allow an attacker to take full control over the database.

Golunski says he informed Oracle of both issues, along with other database vendors that forked the MySQL engine in the past such as MariaDB and PerconaDB.

Today the researcher took the extreme measure of publishing proof-of-concept exploit code for CVE-2016-6662 after both MariaDB and PerconaDB fixed the vulnerabilities and Oracle did not.
Click to expand...

Oracle most likely to patch issues in October's CPU

Oracle is on a strict security update release schedule that comes out once every three months. The last Oracle Critical Patch Update (CPU) came out on July 19.

Golunski says he reported the issue to Oracle on July 29. He also mentions that Oracle's security team acknowledged and triaged the report. The next Oracle CPU is scheduled for October 18, 2016.
Click to expand...

"The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August," Golunski explained. "During the course of the patching by these vendors the patches went into public repositories and the fixed security issues were also mentioned in the new releases which could be noticed by malicious attackers."
Click to expand...

LOL so glad I switched to MariaDB and not Oracle MySQL !

MariaDB 10.1.17 was released on August 30, 2016 and MariaDB 10.1.17 Changelog - MariaDB Knowledge Base lists

MDEV-10465 general_log_file can be abused

from that JIRA MDEV-10465 ticket

Fixed Version/s 5.5.51, 10.0.27, 10.1.17
Click to expand...

Description
Earlier MySQL used to read my.cnf from three locations, in that order:

/etc

datadir

$HOME/.my.cnf

The second is particularly unsafe, because datadir is writable by the mysqld server, and a user that can connect to MySQL can create my.cnf in the datadir using SELECT ... OUTFILE. Over time various safety mechanisms were implemented:

mysqld no longer reads my.cnf in the datadir. Still, mysqld_safe.sh does and forces the server to, so if the server is started via mysqld_safe.sh, my.cnf in the datadir is still used.

--secure-file-priv command-line option limits SELECT ... OUTFILE to the specified directory, it's recommended to set it outside of datadir

SELECT ... OUTFILE creates files that are world-writable and mysqld refuses to read my.cnf if it is world-writable.

But as was recently discovered by Dawid Golunski, one can abuse @@general_log_file variable to create a my.cnf in the datadir, and it will be not created world-writable, so the bothmysqld_safe and mysqld will read it on startup.
Click to expand...

Revenge · Sep 13, 2016

Ya, i have read it this afternoon. MariaDB and Percona are not affected by this. They fixed it last month.

eva2000 · Sep 13, 2016

yeah mean while Oracle MySQL users need to wait 48 days (between August 30th till October 18th) ! Though it does require mysql user access in the first place.

@Colin re-titled this thread to make it clearer MariaDB / Percona already fixed

eva2000 · Sep 13, 2016

confused now Oracle MySQL 5.5.52 MySQL :: MySQL 5.5 Release Notes :: Changes in MySQL 5.5.52 (2016-09-06)

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-version options 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)

Privilege escalation was possible by exploiting the way REPAIR TABLE used temporary files. (Bug #24388746)

Click to expand...

seems was fixed ?

eva2000 · Sep 13, 2016

New MySQL Zero Days — Hacking Website Databases

Both MariaDB and PerconaDB had fixed the vulnerabilities, but Oracle had not.

The vulnerability (CVE-2016-6662) can be exploited by hackers to inject malicious settings into MySQL configuration files or create their own malicious ones.

Exploitation Vector

The above flaw could be exploited either via SQL Injection or by hackers with authenticated access to MySQL database (via a network connection or web interfaces like phpMyAdmin).
Click to expand...

The flaw actually resides in the mysqld_safe script that is used as a wrapper by many MySQL default packages or installations to start the MySQL service process.

The mysqld_safe wrapper script is executed as root, and the primary mysqld process drops its privilege level to MySQL user, Golunski examined.

"If an attacker managed to inject a path to their malicious library within the config, they would be able to preload an arbitrary library and thus execute arbitrary code with root privileges when MySQL service is restarted (manually, via a system update, package update, system reboot, etc.)"
Click to expand...

The researcher will soon release details and full exploit code for CVE-2016-6663, the flaw that allows low-privileged attackers to make exploitation trivial.
Click to expand...

eva2000 · Sep 13, 2016

Percona's email newsletter

Hi Sir/Madam ,

Early on Monday 9/12, Dawid Golunski of Legal/ethical hacking. Information security. reported MySQL bug CVE-2016-6662. From seclist.org:

An independent research has revealed multiple severe MySQL vulnerabilities. This advisory focuses on a critical vulnerability with a CVEID of CVE-2016-6662. The vulnerability affects MySQL servers in all version branches (5.7, 5.6, and 5.5) including the latest versions, and could be exploited by both local and remote attackers.

Both the authenticated access to MySQL database (via network connection or web interfaces such as phpMyAdmin) and SQL Injection could be used as exploitation vectors. Successful exploitation could allow attackers to execute arbitrary code with root privileges which would then allow them to fully compromise the server on which an affected version of MySQL is running.

This is a CRITICAL update, and the fix mitigates the potential for remote root code execution. We have added a fix for CVE-2016-6662 in the following releases:

Percona Server 5.5.51-38.1

Percona Server 5.6.32-78.0

Percona Server 5.7.14-7

We encourage our users to update to the latest version of their particular fork as soon as possible, ensuring they have appropriate change management procedures in place beforehand so they can test the update before placing it into production.

Percona would like to thank Dawid Golunski for disclosing this vulnerability in the MySQL software, and working with us to resolve it.
Click to expand...

Revenge · Sep 13, 2016

MariaDB and Percona used the same fix or they both implemented their own?

eva2000 · Sep 14, 2016

serious enough for a separate blog post by MariaDB MariaDB - MariaDB Server versions and the Remote Root Code Execution Vulnerability CVE-2016-6662 | Centmin Mod Community

However, if the database user being used has neither SUPER nor FILE privilege or if the user has FILE but–secure-file-priv is set to isolate the location of import and export operations, the vulnerability is NOT exploitable. It is always recommended configuration to not grant SUPER privileges and avoiding granting FILE privileges without using –secure-file-priv.

Users that have installed MariaDB Server 10.1.8 or later from RPM or DEB packages are not affected by the vulnerability. This is due to the fact that in version 10.1.8, we started using systemd instead of init to manage the MariaDB service. In this case the mysqld_safe startup script isn’t used.

The corresponding bug about the vulnerability can be seen in MariaDB’s project tracking with bug numberMDEV-10465. It was opened on July 31st this year.

All stable MariaDB versions (5.5, 10.0, 10.1) were fixed in August in the following versions:

5.5.51, released on August 10th

10.0.27, released on August 25th

10.1.17, released on August 30th

If you’re on any of the above versions (or later) you’re protected against this vulnerability.
Click to expand...

fyi, addons/mysqladmin_shell.sh used to create mysql users and databases on Centmin Mod does not grant SUPER or FILE privileges to mysql users created

eva2000 · Sep 14, 2016

Revenge said: ↑

MariaDB and Percona used the same fix or they both implemented their own?
Click to expand...

not sure probably they all have their own relative fixes

negative · Sep 16, 2016

I have mariadb 10.1.17 already so do i need to any action for this bug fix thread? I don't understand exactly.

eva2000 · Sep 16, 2016

All stable MariaDB versions (5.5, 10.0, 10.1) were fixed in August in the following versions:

5.5.51, released on August 10th

10.0.27, released on August 25th

10.1.17, released on August 30th

Click to expand...

Log in / Register

Forums

Want to subscribe to topics you're interested in?

MariaDB Oracle MySQL CVE-2016-6662 - fixed in MariaDB/Percona already

Colin Premium Member Premium Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

negative Active Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want to subscribe to topics you're interested in?

MariaDB Oracle MySQL CVE-2016-6662 - fixed in MariaDB/Percona already

Colin Premium Member Premium Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

negative Active Member

eva2000 Administrator Staff Member

.