Date: Sat, 30 Jul 2016 10:27:09 -0400 From: Hanno Böck <hanno@...eck.de> To: lazytyped <lazytyped@...il.com> Cc: oss-security@...ts.openwall.com Subject: Re: Re: Use after free in my_login() function of DBD::mysql (Perl module) On Fri, 29 Jul 2016 20:42:03 -0700 lazytyped <lazytyped@...il.com> wrote: > 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. It's my (maybe poor / limited) understanding that most use after free bugs are actually reads, but still can lead to code execution, e.g. if the read includes function pointers. This is probably not the case in this example (but I previously had an example where I thought it's not exploitable for similar reasons, and later got told by people who understand this stuff much better that they disagree). > 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). I understand your wish here, but I am afraid it doesn't match up well with the reality we are in. I had similar discussions before, but I think there is a very obvious problem here: The tools we use to find these bugs (asan+afl) are dead simple and there are a lot of people out there using them, finding and reporting bugs. The number of people with a detailed knowledge of memory corruption on the other hand is small. Generally this is a good thing, as it means more people finding bugs. But we have a large number of people who can use the tools to find these bug classes, but who aren't neccessarily able to judge the severity. And that definitely includes me (although I learned a lot in the past year, but I've been accused both in over and underplaying bugs in the past). My approach to this is that I simply try to choose my wording that it matches what I know and if I can't say anything reasonable about exploitability I simply don't. As for CVEs, it's my impression that MITRE right now has a policy that they give one for almost any memory safety issue and that they don't require an explicit exploit scenario. E.g. my impression is that buffer overreads, as long as they aren't simply in a command line tool, almost always get CVEs. -- Hanno Böck https://hboeck.de/ mail/jabber: hanno@...eck.de GPG: BBB51E42 [ CONTENT OF TYPE application/pgp-signature SKIPPED ]
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