oss-sec mailing list archives
Re: mpg123: global buffer overflow in III_i_stereo (layer3.c)
From: Kurt Seifried <kseifried () redhat com>
Date: Mon, 10 Jul 2017 20:21:03 -0600
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. SoIt 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 () redhat com
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- mpg123: global buffer overflow in III_i_stereo (layer3.c) Agostino Sarubbo (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Dr. Thomas Orgis (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Agostino Sarubbo (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Seth Arnold (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Kurt Seifried (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Michal Zalewski (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Kurt Seifried (Jul 10)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Dr. Thomas Orgis (Jul 11)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Jonas Thiem (Jul 11)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Dr. Thomas Orgis (Jul 11)
- Re: mpg123: global buffer overflow in III_i_stereo (layer3.c) Dr. Thomas Orgis (Jul 10)