Date: Fri, 29 Jul 2016 20:42:03 -0700 From: lazytyped <lazytyped@...il.com> To: Hanno B=c3=b6ck <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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ