Latest YouTube Video

Tuesday, September 27, 2016

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

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: http://ift.tt/1mkbPsp > > 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: > http://ift.tt/1O6abzy > > 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. >

Source: Gmail -> IFTTT-> Blogger

No comments: