All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MySQL 0day exploit

Early on Monday 9/12, Dawid Golunski of http://legalhackers.com/ 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.
Comments
Oh dear... Let's have an eye on this!
And let me once step in the GIF game:

http://news.softpedia.com/news/mysql-zero-day-allows-database-takeover-508211.shtml
"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."
So everyone is just gonna be vulnerable for over a month?
----------Edit-----------
https://www.reddit.com/r/netsec/comments/52dgxh/mysql_remote_root_code_execution_privilege/d7jefp0
Maybe its not as bad as it sounds?
Other sources have reported that this is "just" a privilege escalation issue
"As temporary mitigations, users should ensure that no mysql config files are
owned by mysql user, and create root-owned dummy my.cnf files that are not in
use."
Aye. It's bad but it looks like there are appropriate measures to take. These days, I'm satisfied with that. I'll take good news on vulnerabilities where I can get it
This is true, though how many people clued up people leave their DB server/s publicly exposed? I imagine not many.
Yeah I expect primarily popcorn time from anyone using a public facing instance of phpMyAdmin. I feel like that defines the characteristics of people who will be compromised.
even more reason to switch from Oracle Mysql to MariaDB or Percona MySQL http://news.softpedia.com/news/mysql-zero-day-allows-database-takeover-508211.shtml
MariaDB 10.1.17 was released on August 30, 2016 and https://mariadb.com/kb/en/mariadb/mariadb-10117-changelog/
from that JIRA MDEV-10465 ticket
It stills requires an SQLi hole to exploit though - or did I misunderstand? Or do you mean in terms of a multi-tenant set up?
Oh I'm picturing root owned phpmyadmin with the user who logs in with his root MySQL password. You know, absolute first target for literally any vulnerability kind of person
MySQL clones are also affected, including:
MariaDB
PerconaDB
The only good thing is that you have to be vuln to SQL Injection in order for this to effect your server.
forks
are you talking about the same issue ? MariaDB already fixed this back on August 30 see https://jira.mariadb.org/browse/MDEV-10465
from http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
@eva2000 Does the centos 7 update repo mariadb has this patched?
We need @GCat to scan all colocrossing space for phpmyadmin installations, so we can sell email lists cheap
jks
Based on everything I'm reading the only way to exploit this vulnerability is you have to have a local MySQL user on the server and you need specific permissions that most users don't have.
What kind of permissions would someone need to exploit this?
I have a MySQL server with users that can use all privileges on databases named theirusername_% (allows them to create databases with the prefix theirusername_databasename).
Any elevated access to my MySQL server is accessible only via a VPN.
(woah, I haven't checked my server in a while and it turns out my users have pushed through 346.5GiB of bandwidth through MySQL alone)
Silly you, I've been doing that all week. Surprised I haven't had my scanning servers blocked yet
FILE permissions for starters http://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_file
@eva2000
I've set up my server to only be able to load from a specific directory.
Thanks!
All you have to do nowadays is to keep an eye on the logs for suspicious activities.
I have a fail2ban filter that watches the apache logs for any attempt to read phpmyadmin or myadmin directory. Since I don't have that I know it's a scanner and automatically ban it. I also watch for other common scanner activity and update the filter regularly.
I heard about it but I don't trust anyone other than myself in checking mysql logs as that may contain serious information.
You don't trust fail2ban? It's been out for a long time, I'm sure if it were malicious such details would have surfaced by now. Plus it's by far more likely that locally run, automated processes like fail2ban are going to notice suspect activity before you. It monitors every few minutes, 24 hours a day, all the time; a single person cannot monitor that frequently.