Protect your corporate IT network from hackers and other unwanted intruders with Proxy Sentinel™. Click here for all the details and get the peace of mind you deserve.
Back to our Homepage Proxy Sentinel™ high performance Internet proxy server and secure firewall solution Firewall Sentinel™ secure & powerful Internet firewall solution About Internet and GCIS Frequently Asked Questions on Internet security issues Internet Security Industry News - Stay informed of what's happening Contact Internet today and order your Proxy Sentinel™ or Firewall Sentinel™ server now!

Critical security flaw discovered in MySQL can allow root access

Sponsered ads:
Read the latest IT news. Visit Updated several times daily.

If you need reliability when it comes to SMTP servers, get the best, get Port 587.

Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!

Share on Twitter.

September 13, 2016

We just learned this morning that a very critical security flaw has been discovered in MySQL that can allow a hacker to obtain remote root access to servers.

Even more worrisome is the fact that details on how to exploit the security vulnerability are now public and there's no patch available at this time.

Although the programming blunder is present in all default installations of MySQL 5.5, 5.6 and 5.7, if you've taken some very basic precautions, you're probably safe, for now anyway.

The MySQL bug is dubbed CVE-2016-6662 and was discovered by David Golunski, who says he reported it to MySQL overseer Oracle on July 29.

Golunski found that you can misuse an SQL command to write arbitrary text to the open-source database's configuration files. He has published limited proof-of-concept code to open a remote root shell on a vulnerable installation.

But how is this possible in the first place? Bear in mind that MySQL is launched by a script file called mysqld_safe, unless you're using an RPM distribution with systemd, and MySQL 5.7.6 or later.

This script runs as root even if you tell MySQL to run as a non-root user. It reads from the database's configuration files for a setting called malloc_lib and dynamically loads the shared library referenced by this setting.

So if you can upload a malicious library onto a server and then tamper with one of MySQL's config files so that mysqld_safe loads that library, you can probably get remote code execution as root when the database is next started and before it drops its privileges.

Yes, that's a lot of ifs, but nevertheless, it's worrisome just the same. You can, via SQL, abuse the database variable general_log_file to write to a configuration file.

But that requires you to be able to run arbitrary SQL on the victim's machine, and with permission to set general_log_file. One way to do this would be to exploit an SQL injection vulnerability in a web app script to upload a malicious .so library and then play around with the config file via the logging system.

The attacked web app would still need permission to do that, but any smart system admin would off course turn that off-- that's so basic.

Additionally, the hijacked configuration file would have to be writeable for the MySQL server, but not world writeable or the database would reject it for security reasons.

Alternatively, a new config file could be created by the logging system in one of the various file system locations that MySQL always looks in for its general settings.

If a web app can use the FILE SQL command, and has an SQLi vulnerability, a hacker can exploit that hole to upload a trigger file so that at some point in the future, such as when an INSERT command completes, the trigger script kicks in and the general_log_file trick can be performed as the MySQL root user.

In his proof-of-concept exploit code, Golunski notes-- "This is a limited version of the PoC exploit. It only allows appending to existing mysql config files with weak permissions."

"Full PoC will be released at a later date, and will show how attackers could exploit the security vulnerability on default installations of MySQL on systems with no writable my.cnf config files available."

The upcoming advisory CVE-2016-6663 will also make the exploitation trivial for certain low-privileged attackers that do not have FILE privilege.

If a hacker can execute arbitrary SQL commands on your database, you're already in a world of pain. But if your web app's permissions aren't locked down, and the MySQL user can write to or create new configuration files for itself, an SQL injection vulnerability will rapidly turn into a remote root shell via Golunski's CVE-2016-6663 and CVE-2016-6662 security holes.

In the absence of a workable fix from Oracle, make sure you're not at risk of any SQLi attacks, don't give your web scripts access to dangerous SQL commands, and don't allow the server to modify its own configuration files.

MySQL derivatives MariaDB and PerconaDB have both issued security fixes to address the reported bugs. Oracle's update is expected to arrive at the end of October at the earliest. Not soon enough, that's for sure!

"No official security patches or mitigations are available at this time from the vendor," said Golunski. "As temporary mitigations, users should ensure that no MySQL config files are owned by the MySQL user, and create root-owned dummy my.cnf files that are not in use.

"These are by no means a complete solution and users should apply official vendor patches as soon as they become available," he added.

Source: David Golunski.

Sponsered ads:
Read the latest IT news. Visit Updated several times daily.

If you need reliability when it comes to SMTP servers, get the best, get Port 587.

Get a powerful Linux Dual-Core dedicated server for less than $2.67 a day!

Share on Twitter.

Home | Proxy Sentinel™ | Firewall Sentinel™ | FAQ | News | Sitemap | Contact
Copyright © Internet    Terms of use    Privacy agreement    Legal disclaimer