Date: Fri, 23 Sep 2016 00:58:33 -0300
From: Dawid Golunski <dawid@...alhackers.com>
To: fulldisclosure@...lists.org
Cc: mark.koek@...ec.com
Subject: Re: [FD] CVE-2016-6662 - MySQL Remote Root Code Execution /
 Privilege Escalation ( 0day )

Hi Mark,

Thanks for the feedback.
I'll answer your questions and throw in a few other comments on here
using the occasion that will
hopefully clarify some of the other misconceptions I've seen around or
be otherwise useful to someone.

As for SUPER priv requirement.
The short answer is: yes, you are wrong in thinking that (but good
that you question it at least :)

SUPER privilege is not required as mentioned in my advisory in the
dedicated chapter V. 3) titled:
'3) Attackers with only SELECT/FILE permissions can gain access to
logging functions[...]'
You could confirm this by running the exploit, or having a look at the
example run output or the replication steps that show the exact
privileges applied on the test account (no SUPER privs in there :)
The current PoC exploit basically abuses the power of a risky FILE
privilege alone which can be used to escalate
privileges via a number of ways (including extracting mysql password
hashes, or injecting specially crafted triggers as shown in the
advisory/PoC exploit).

As for your remote exploitation and user/password requirement question.
Although the current PoC is limited (to give users a chance to react
to this vuln etc.), notice that the advisory mentions that SQL
Injection could be used as a vector for exploitation in addition to an
authenticated connection to the mysql service (via direct connection
to mysql port, or via phpMyAdmin).
SQL injection attacks can be conducted remotely so I'd say it is fair
to call it a remote exploit.
I'd say it'd still be a remote exploit even with a remote
authenticated connection to mysql service was the only option (i.e.
Authenticated RCE is still an RCE if that makes sense).
On a separate note, I'm not aware of other _reliable/working_ recent
MySQL PoC exploits that could let remote attackers (even starting with
database admin/super privs) to bypass protections such as SELinux and
AppArmor and achieve remote code execution, let alone gain root access
on top of that through MySQL exploitation.
Other than the old vuln from 2003
(http://www.kb.cert.org/vuls/id/203897) that is similar to my exploit
and which I referenced in my advisory.
Note that CERT also mentioned remote exploitation in the description
of the article and gave it a CVSS score of 9.43.

As for other reliable exploits that could get you a shell through MySQL.
Some years ago (<2008) it used to be possible for malicious _database
admin_ users (required access to CREATE FUNCTION statement) to create
a malicious UDF (user-defined function) from a library that executed a
system() call and let an attacker run commands as myql system user.
The UDF "trick" was blocked however in 2008 , in MySQ version 5.0.67.
>From then on MySQL only allows loading UDF libraries from trusted
system directories (writable by root only). And _even_ if you had a
way to inject a library into a  trusted directory and create a
malicious UDF function from it, you'd still be blocked by default
policies of SELinux or AppArmor on many modern systems when trying to
execute system() call or similar as the mysqld process.
There are some blog posts around still showing the UDF method as a way
to get code execution on today's MySQL setups. They however rely on
the mysqld process running as root which never happens in practice
(note that my exploit targets mysqld_safe which does in contrast run
as root on many default setups) and if it did , you'd have bigger
problems to start  with :)
That's just to illustrate some of the challenges. If anyone knows of a
working/reliable exploit that can address these and achieve remote
code execution through MySQL then I'd be interested to learn the
details :)


Another misconception I've seen on some forums that is that the
CVE-2016-6662 vulnerability I discovered is not exploitable on systems
without overly-permissive my.cnf config files (e.g owned by mysql).
This is not correct and I addressed this in the advisory in section:

"'2) Create new configuration files within a MySQL data directory
(writable by MySQL by default) on _default_ MySQL installs without the
need to rely on improper config permissions"

which mentions that attackers could in fact be able to inject new
valid configs on systems with default my.cnf/datadir permissions (not
implemented in the current limited PoC). This is actually the reason
behind creating a dummy my.cnf in /var/lib/mysql datadir with root
perms as a temporary mitigation (i.e. to prevent malicious attackers
from creating a new my.cnf file in datadir on default setups when
they're unable to find one with weak perms).


I should have probably extended some of the descriptions in my
advisory from the start to make it easier to understand for a larger
group of people, but still I put a lot of effort into making the
advisory quite detailed (including comments in the exploit code etc.)
with most answers in it for those who read it closely/tested the
provided PoC, especially taking into account the crazy
circumstances/timing when it all happened...
I wrote the advisory/exploits over 3 sleepless nights on my holiday
when backpacking through the north of Brazil, stuck at a hostel's
lounge with mosquitoes and other drunk travelers running around
through the night (think of having the 'team distraction' from DefCon
https://youtu.be/rVwaIe6CiHw?t=3548 over a few sleepless nights :)
But that's another story, probably for a blog post or a chat with some
fernet/vodka at the upcoming EkoParty conference in Buenos Aires ;)

Sorry for a lengthy message.
Hopefully this will answer not only your doubts but also help to clear
up similar misconceptions out there.
I updated my advisory with a few extra clarifications/notes at:

http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

I should follow up shortly with more info shared via my website:
http://legalhackers.com

or my twitter feed:
https://twitter.com/dawid_golunski


Thanks for reading all of that (if you got here that is :)


-- 
Regards,
Dawid Golunski
http://legalhackers.com



On Tue, 13 Sep 2016 12:27:29 +0200, Mark Koek wrote:
> Well, 'remote root'... The PoC asks for a working MySQL user name and password.
>
> And I don't really get how that account can re-set the logfile location without SUPER privileges?
>
> Am I wrong in thinking that this is really "just" a MySQL admin -> root privilege escalation? Don't get me wrong, still a very nice exploit, but...
>
> Mark

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists