[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Jul 2016 20:42:03 -0700
From: lazytyped <lazytyped@...il.com>
To: Hanno Böck <hanno@...eck.de>
Cc: oss-security@...ts.openwall.com
Subject: Re: Re: Use after free in my_login() function of
DBD::mysql (Perl module)
On 7/29/16 8:58 AM, Hanno Böck wrote:
> On Thu, 28 Jul 2016 06:31:20 -0700
> lazytyped <lazytyped@...il.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
>
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.
