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://ift.tt/2d7fYqv) 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://ift.tt/2cpoG2D 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 :)
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment