[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160730102709.25d91e44@pc1>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
