Re: CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day )

[Mark Koek <mark.koek () qcsec com>]

I think the term is 'remote privilege escalation' (as opposed to local 
privilege escalation). As a headline I'd suggest 'remote privilege 
escalation from any mysql user to root'.


Mark

On 23-09-16 19:20, Dawid Golunski wrote:
> Hi Mark,
>
> Thanks for that. I guess it depends which RCE definition you follow.
> For example if you take:
>
> 'The ability to trigger arbitrary code execution from one machine on
> another (especially via a wide-area network such as the Internet) is
> often referred to as remote code execution.'
> from:  https://en.wikipedia.org/wiki/Arbitrary_code_execution
>
> Then you could  have a remote exploit that _does_ require an
> authentication before triggering code execution on the remote
> target/machine and still call it a remote exploit. I.e. Pre-Auth
> Remote Execution VS Authenticated Remote Execution.
> You'll find many remote exploits with those prefixes, including on the
> cisco website you quoted, for example:
> https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160601-prime2
>
> I agree however that my exploit strays a bit from a typical RCE
> (leaving preauth/authed classification aside) "concept" as the code
> execution is not instantaneous. I.e. it involves a delay due to a
> service restart (necessary in order to hook to the service startup and
> gain the root privileges before they're dropped ,since the mysqld
> daemon itself never serves requests as root).
> I've chosen 'Remote Root Code Execution / Privilege Escalation' name
> to keep it simple and to reflect/focus on the same end result/impact
> that a typical Root RCE would have - i.e. gaining a remote attacker a
> rootshell.
> If I called it a "Local exploit" then many people out there could
> think that they can't be attacked from another host and local shell is
> required. Whereas "Remote SQL injection/authed remote connection to
> Root Command Execution with a delay" sounds kind of long ;)
>
> One more note/clarification I might as well throw in here.
> Obviously it doesn't meant that the attacker has to wait endlessly for
> the exploit to finish its job. Once the exploitation is done and
> config has been poisoned with the malicious library injected they can
> go away and the reverse root shell will say hi whenever a restart
> takes place ;)
> Additionally, I've also found that remote attackers could be able to
> speed up the restart by remotely executing the SHUTDOWN
> command/statement which could bring  the exploit closer to a typical
> RCE concept. I've added this note to my advisory now too.
>
> Hope this clears up the naming a bit and the reasoning behind it.
> Of course, I'm not trying to insist on the naming I used as
> you/everyone else will have their own preference for classification of
> a remote exploit or their own ideas for an alternative name. There are
> also more constructive things to be doing rather than insisting on a
> particular name (e.g publishing remaining vulns :)
> The important bit is to keep in mind the impact of the vuln (root
> shell) and that it may also get exploited by remote (authed/sql
> injection) attackers.
>
> Thanks again.


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