[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Jul 2017 20:21:03 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: mpg123: global buffer overflow in III_i_stereo
(layer3.c)
On 2017-07-10 7:28 PM, Seth Arnold wrote:
> On Mon, Jul 10, 2017 at 11:42:53AM +0200, Dr. Thomas Orgis wrote:
>> Is this really worth a CVE, though? So far I was only able to see a
>> crash triggered by the AddressSanitizer. Never from a normal build. So
> It is common to assign CVEs for issues discovered via fuzzers and
> sanitizers even if the consequences aren't visible without them: perhaps
> the consequences aren't visible to users only by accident.
To expand on this: some fuzzing results are largely "who cares", e.g. a
locally executed file converter for office files that crashes, no code
execution largely devolves to "well don't open that file again", but a
web browser/email client, or libraries they depend upon that cause a
crash, yeah, that's a problem (I really hate waiting for all my tabs to
reload, and hopefully I didn't lose any data/progress).
> Some people only accept a vulnerability report if there's an exploit that
> goes along with it but developing even a proof of concept is difficult
> and error-prone. Lack of an exploit doesn't prove that an issue can safely
> be ignored. (There's always someone more dedicated to writing an exploit.)
The beauty is that CVE is now a claims based system, obviously the
stronger the claim (e.g. working exploit code, or a professional
reputation helps) the better the case for a CVE, and conversely there is
also a DISPUTE process, again the stronger the claim, the closer you'll
get to REJECT =). Of course proving a negative can be tricky. On the
flip side we do have historical data (e.g. Null pointer deref in Linux
kernel, that's usually a CVE!).
>
> Assigning a CVE number makes downstream consumers aware of the issue and
> each can prioritize a fix as they see fit based on their own threat models.
It also simply creates an entry in the taxonomy so we can discuss it.
The result of that can be "we need to fix this" or "we need to stop
using this" (e.g. some pieces of software have over 1000 CVE's and are
well known to be vectors for infection in web drive by attacks). It lets
us move away from qualitative data to quantitative data (facts yo!) or
any numbr of other responses ("the risk is acceptable").
>> every build of mpg123 in the wild, except for extremely hardened
>> distros that build everything with GCC's sanitizers enabled for daily
>> use, is not affected. Are people running binaries in production with
>> the sanitizers on?
> I believe the general consensus is that only the UBSAN sanitizer is safe
> for 'daily use'; the others aren't themselves security hardened and in
> fact have lead to exploits. This thread has more discussion:
> http://www.openwall.com/lists/oss-security/2016/02/18/1
>
> Thanks
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
Download attachment "signature.asc" of type "application/pgp-signature" (843 bytes)
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.
