Re: Re: Use after free in my_login() function of DBD::mysql (Perl module)

[lazytyped <lazytyped () gmail com>]

On 7/29/16 8:58 AM, Hanno Böck wrote:
> On Thu, 28 Jul 2016 06:31:20 -0700
> lazytyped <lazytyped () gmail com> wrote:
>
> > Quick question:
> >
> > - I guess the affecting function call is the following:
> >
> >     do_error(dbh, mysql_errno(imp_dbh->pmysql),
> >                    mysql_error(imp_dbh->pmysql)
> > ,mysql_sqlstate(imp_dbh->pmysql));
> >
> > which one of those calls provides an exploitation path? They seem all
> > reads off the free'd structure.
> >
> > I see in the bug report: " (I think use after free's can be serious
> > and potentially lead to malfunction and security issues)" and would
> > like to understand more about the rationale.
> Hi,
>
> I don't have a practical exploit scenario, thus my careful wording (the
> best answer to "is this exploitable?" is often simply "I don't know").
>
> It's a use after free, should be undeniable that it should be fixed.

Yes, but whether this is a security bug or not is a different matter. 
The main reason why I'm bringing this up is that security bugs have a 
significantly different treatment by OS teams and a quite different 
expectation of turnaround time by users/customers.

But once a CVE is out (as is in this case), the bug has been officially 
declared as a security issue, there is no turning back.

So, yes, a use-after-free is a bug, but not necessarily a security one, 
yet the CVE makes it as much, with all the associated process. It would 
be great if we could get a bit more triaging by the owner of the code or 
the submitter before declaring the bug one thing or the other 
(especially in these days of projects like yours that bring in a lot of 
reports -- and don't get me wrong, this is a very valuable effort).

> But my highlevel understanding of what could happen in such a case: In a
> multithreaded application using that module it may be possible that
> another thread is allocating the free'd memory before do_error is
> called and may fill the memory of the struct with attacker-controlled
> content. Would require careful analysis of what do_error does exactly
> whether that could lead to further bad things.

Well, AddressSanitizer should have told you whether the access is a read 
access (as I suspect) or a write access. A bit of code inspection (or 
follow up from the code maintainer) should add to the picture.

As things stand right now, it seems that this could be turned into an 
infoleak (despite some CVSS high scores I've seen around). But 
notwithstanding this, I think it might help the community in general if 
we do not just blindly characterize bugs based on what class they 
belong, but we get a bit more information/effort around them.


       -  Enrico

>