3 ms·

For FreeBSD users out there, I would seem that, in the default setting, the mysqld_safe script is being run as mysql uid by the rc startup script. So by the tim

For FreeBSD users out there, I would seem that, in the default setting, the mysqld_safe script is being run as mysql uid by the rc startup script. So by the time mysqld_safe is invoked, root privileges are already dropped. But that shouldn't dissuade one from taking some preventive measures, e.g. making sure that unnecessary FILE privileges are revoked from accounts and/or making sure that my.cnf is owned by root and only writable by root. Also, as the CVE mentions, do remember that a my.cnf in /var/db/mysql (or /var/lib/mysql for Linux) will override settings in other locations. Touching it as root with an appropriate flag mask should plug that hole too. An updated mysql package will be soon be available of course.

JdeBP 10y ago
So one can merely get shell access as the unprivileged server process user rather than as the superuser. It's interesting to see how many people look at this and react "Whoa! Shell access!" or "Whoa! Malicious shared library injection!", and how few have commented on the fact (almost treated as a minor sideline) that one vector for the exploit involves setting up database triggers that run with SUPER privileges. "Whoa! Attackers (with FILE privilege) can alter your purchase orders and invoices, steal your contacts and confidential customer account information, change inventory records, and forge identities." No shell access or shared libraries involved. But that's been known as CVE-2012-5613 for some time. (-: