[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170803075619.GR25574@pali>
Date: Thu, 3 Aug 2017 09:56:19 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, security@...iadb.org,
secalert_us@...cle.com, security@...cona.com,
Andrea Barisani <andrea@...ersepath.com>,
Michiel Beijen <michiel.beijen@...il.com>,
Alceu Rodrigues de Freitas Junior <glasswalk3r@...oo.com.br>
Subject: Re: MySQL - use-after-free after mysql_stmt_close()
On Wednesday 02 August 2017 13:40:32 Tomas Hoger wrote:
> On Thu, 8 Jun 2017 23:49:03 +0200 Pali Rohár wrote:
>
> > MySQL applications written according to Oracle's MySQL documentation &
> > examples for mysql_stmt_close() function call are vulnerable to use-
> > after-free defect.
>
> ...
>
> > Whole example of usage is written in mysql_stmt_execute() function [3].
> > The relevant part for mysql_stmt_close() is at the end of example:
> >
> > /* Close the statement */
> > if (mysql_stmt_close(stmt))
> > {
> > fprintf(stderr, " failed while closing the statement\n");
> > fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
> > exit(0);
> > }
> >
> > And here is a problem, use-after-free defect. Current implementation of
> > mysql_stmt_close() function unconditionally free passed statement
> > structure and therefore following mysql_stmt_error() call is defective
> > to use-after-free.
>
> ...
>
> > Oracle team was unwilling to tell anything, provide any information how
> > to handle such issue or what to do, therefore with suggestion from oCERT
> > I decided to make this report public and open public discussion for
> > other people on oss-security list how to handle this problem.
> >
> > As Oracle fully ignored this problem and have not stated if problem is
> > in documentation, implementation or both, I see probably 3 different
> > solutions:
>
> Oracle has previously updated code examples in the documentation. They
> apparently also assigned CVE-2017-3635 via July 2017 CPU:
>
> http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html#AppendixMSQL
>
> There's the following note for the CVE:
>
> """
> The documentation has also been updated for the correct way to use mysql_stmt_close(). Please see:
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-execute.html,
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-fetch.html,
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-close.html,
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-error.html,
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-errno.html, and
> https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-sqlstate.html
> """
>
> The issue is listed as fixed in versions 5.5.57, 5.6.37, and 5.7.19.
> Their release notes also mention the change:
>
> https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-57.html
> https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-37.html
> https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-19.html
>
> """
> If the mysql_stmt_close() C API function was called, it freed memory
> that later could be accessed if mysql_stmt_error(), mysql_stmt_errno(),
> or mysql_stmt_sqlstate() was called. To obtain error information after
> a call to mysql_stmt_close(), call mysql_error(), mysql_errno(), or
> mysql_sqlstate() instead. (Bug #25988681)
> """
>
> There is also a code change referencing the above bug:
>
> https://github.com/mysql/mysql-server/commit/3d8134d2c9b74bc8883ffe2ef59c168361223837
>
> which does not seem to address the use-after-free problem.
Yes, that commit do absolutely nothing.
> It seems the CVE is effectively for buggy documentation, and the
> fixed-in version numbers are not really relevant.
So again, full silence and no information from Oracle about security
related reports for MySQL. They did absolutely nothing for 2 months
since public report of this issue.
Even CVE does not contain any information for which was assigned. Do we
need such CVE at all??
They are uncommunicative and ignore reports which can classified as
security. The only think what they can do is to threaten people if they
want to start public discussion about issue. My concern about Oracle
still remains: The worst company in handling security issue.
--
Pali Rohár
pali.rohar@...il.com
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
