MySQL Hit By "Critical" Remote Code Execution 0-Day

[nils_]

The trigger need the FILE permission "3) Attackers with only SELECT/FILE permissions can gain access to logging functions (normally only available to MySQL admin users) on all of the _default_ MySQL installations and thus be in position to add/modify MySQL config files. If attackers do not have administrative rights required to access logging settings and only have standard user privileges with the addition of FILE privilege then they could still gain the ability to write to / modify configuration files."

That seems a rather unusual combination of permissions. Also I believe to set the definer for the trigger to any user and to set global options like log file you'll need SUPER privilege, at which point you can also simply load plugins.

[F.Ultra]

The article on legalhackers is very interesting. There are multiple bugs here, but the most critical one is privilege escalation to root, because the mysql_safe wrapper script does stupid things before dropping root privileges.

Which once again proves why it is a bad idea to have an init system that relies on a bunch of fragile bash scripts. On systemd, the privilege escalation is defeated by these three lines in the mysql.service file:

[Service]
User=mysql
Group=mysql

Now whatever other bugs are in mysql will surely allow anyone able to submit SQL querys (either by having authenticated access or via sql injection) to do bad things to my database, but thanks to a proper init system, they don't become root. Awesome!

Not only that but the only reason that the mysql_safe wrapper exists in the first place is due to shortcomings of SysV Init. The systemd unit file for MySQL/MariaDB is almost reason enough to install systemd over SysV Init. How many times over the years have I not been bitten by that damn wrapper script trying to restart a shutting down database just because it took a bit longer than it expected (or how it could be stuck forever in shutdown due to the pid being reused by another process).

[timtas]

Yes, totally correct, the only solution against that crappy mysql startup script and the shitty mysqld_safe wrapper clearly is to immediately migrate to systemd. How can those stupid anti-systemd idiots just fail to see that? And there also was that shitty bind startup script, remember. All fools.

[rohcQaH]

Yes, totally correct, the only solution against that crappy mysql startup script and the shitty mysqld_safe wrapper clearly is to immediately migrate to systemd.

What else are you going to do? If oracle doesn't provide a patch, it seems that users who haven't migrated to mariadb are currently out of non-invasive options.

[nils_]

Yes, totally correct, the only solution against that crappy mysql startup script and the shitty mysqld_safe wrapper clearly is to immediately migrate to systemd. How can those stupid anti-systemd idiots just fail to see that? And there also was that shitty bind startup script, remember. All fools.

Unfortunately systemd seems to do nothing for your mood...

[F.Ultra]

Yes, totally correct, the only solution against that crappy mysql startup script and the shitty mysqld_safe wrapper clearly is to immediately migrate to systemd. How can those stupid anti-systemd idiots just fail to see that? And there also was that shitty bind startup script, remember. All fools.

You do realise that that wrapper did things that other inits such as upstart and systemd provides but that SysV did not? And btw MariaDB provided the very same wrapper since they also wanted the functionality that it provided if run under SysV. I take it that you don't really know what the wrapper did and how it could fail miserably.