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

[Gsunde Orangen <gsunde.orangen () gmail com>]

Dawid meanwhile updated his post [1] to reflect that the fixes for
CVE-2016-6662 were added in 5.5.52/5.6.33/5.7.15.
... But today Oracle states that those versions were still affected [2],
thus the fix releases are 5.5.53/5.6.34/5.7.16.

So which one is correct? Based on the changelogs I assume [1].

And btw, Dawid: what happened with CVE-2016-6663? Still not public yet?

Gsunde

[1]
http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
[2]
http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html#AppendixMSQL

On 12.09.2016, 16:45 Fried Wil wrote:
> Hi Dawid,
>
> Affected MySQL versions (including the latest):
> <= 5.7.15
> <= 5.6.33
> <= 5.5.52
>
> Is your issue related to MySQL bugids fixed in 5.5.52/5.6.33/5.7.15 ?
>
> https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-52.html
> Changes in MySQL 5.5.52 (2016-09-06):
> - For mysqld_safe, the argument to --malloc-lib now must be one of the
> directories /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu, or
> /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and
> --mysqld-version options can be used only on the command line and not
> in an option file. (Bug #24464380)
> - Privilege escalation was possible by exploiting the way REPAIR TABLE
> used temporary files. (Bug #24388746)
> - It was possible to write log files ending with .ini or .cnf that
> later could be parsed as option files. The general query log and slow
> query log can no longer be written to a file ending with .ini or .cnf.
> (Bug #24388753)
>
> Thanks
>
>
> On Mon, Sep 12, 2016 at 6:58 AM, Dawid Golunski <dawid () legalhackers com> wrote:
> > Hi Alexander,
> >
> > I was just going to reply to your email you sent earlier.
> > Thanks for the feedback. I actually updated the introduction after your email.
> > The advisory focuses on CVE-2016-6662 vulnerability which lets users
> > to modify/create my.cnf files. A fix would prevent users from writing
> > to my.cnf config.
> >
> > And yes there's a typo in the last paragraph made after a few
> > sleepless nights ;) I've fixed it now.
> >
> > The CVE-2016-6663 is not public yet. I refer to it in the advisory to
> > give some heads up in case someone wanted to discard this issue based
> > on reasoning that FILE privs are not common and that they will never
> > be pwned etc. It'll soon be published then it'll be clear what this
> > CVEID is about ;)
> >
> > Cheers.
> >
> >
> >
> > On Mon, Sep 12, 2016 at 7:35 AM, Solar Designer <solar () openwall com> wrote:
> > > On Mon, Sep 12, 2016 at 06:09:10AM -0300, Dawid Golunski wrote:
> > > > Vulnerability: MySQL Remote Root Code Execution / Privilege Escalation 0day
> > > > CVE: CVE-2016-6662
> > > > Severity: Critical
> > > > Affected MySQL versions (including the latest):
> > > > <= 5.7.15
> > > > <= 5.6.33
> > > > <= 5.5.52
> > >
> > > > http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
> > >
> > > Thank you for posting this.  For archival, and to comply with
> > > oss-security content guidelines, I am attaching a text/plain version of
> > > the above advisory (which includes a lot of detail not in your posting).
> > >
> > > Also, to add detail on the disclosure timeline: Dawid brought this to
> > > the distros list yesterday (Sunday).
> > >
> > > As I had pointed out in a reply on distros, it is not entirely clear
> > > what exact issue the CVE-2016-6662 identifier is for.  The advisory
> > > talks about multiple sysadmin practices, packaging issues, dangerous
> > > features of MySQL, and finally of safe_mysqld including the data
> > > directory in its search path for my.cnf.  I guess it would be most
> > > reasonable to have the CVE ID refer only to the latter aspect, but
> > > confirmation/clarification is needed.  As it is, it's unclear from the
> > > advisory what exact "vulnerabilities were patched by PerconaDB and
> > > MariaDB vendors" (the advisory says so), and it is unclear what Oracle
> > > and distros "fixing" CVE-2016-6662 would mean.
> > >
> > > Also, in this paragraph I guess the advisory wanted to refer to the
> > > upcoming CVE-2016-6663 (I have no idea what that issue is, beyond what
> > > the advisory says), like it does in a few other places:
> > >
> > > "It is worth to note that attackers could use one of the other vulnerabilities discovered
> > > by the author of this advisory which has been assigned a CVEID of CVE-2016-6662 and is
> > > pending disclosure. The undisclosed vulnerability makes it easy for certain attackers to
> > > create /var/lib/mysql/my.cnf file with arbitrary contents without the FILE privilege
> > > requirement."
> > >
> > > Alexander
> >
> >
> >
> > --
> > Regards,
> > Dawid Golunski
> > http://legalhackers.com