[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4388229.gHBqzp8EGK@wanheda>
Date: Tue, 29 Aug 2017 22:02:28 +0200
From: Agostino Sarubbo <ago@...too.org>
To: oss-security@...ts.openwall.com
Cc: cve-request@...re.org
Subject: Re: Re: [scr379303] A bunch of duplicate CVEs requested for?? bho..
Hello Mitre, I'm glad to see your response here.
On martedì 29 agosto 2017 21:23:50 CEST cve-request@...re.org wrote:
> > https://nvd.nist.gov/vuln/detail/CVE-2017-13753 duplicate of:
> > https://nvd.nist.gov/vuln/detail/CVE-2016-9396
>
> Yes, these are duplicates; we will reject CVE-2017-13753 and update
> CVE-2016-9396.
The problem is not about this duplicate but from some assignments in the last
two months from people I mentioned, see the first post here from a partial
list: https://marc.info/?l=oss-security&m=150401081512049&w=2
> This occurred because the MITRE CVE team inadvertently populated
> CVE-2016-9396 with incorrect version information,
This is right
> and because the code
> changed between the two tested versions.
from https://blogs.gentoo.org/ago/2016/11/16/jasper-multiple-assertion-failure/ we have:
libjasper/jpc/jpc_t1cod.c:144: int JPC_NOMINALGAIN(int, int, int, int):
Assertion `qmfbid == 0x01′ failed.
form https://bugzilla.redhat.com/show_bug.cgi?id=1485272 we have:
libjasper/jpc/jpc_t1cod.c:144: int JPC_NOMINALGAIN(int, int, int, int):
Assertion `qmfbid == JPC_COX_RFT' failed.
they looks to be similar.
> Specifically, CVE-2016-9396 had said "in JasPer before 1.900.12" but
> actually there was no reference stating that 1.900.12 was a fixed
> version. Also, the CVE-2017-13753 reference said "Assertion `qmfbid ==
> JPC_COX_RFT' failed" but the CVE-2016-9396 reference said "Assertion
> `qmfbid == 0x01' failed." These happen to be the same (there's a
> "#define JPC_COX_RFT 0x01" elsewhere), but it initially looked like
> the new report was about a different assertion that was problematic in
> 1.900.12 and later versions.
From your side looks to be correct, What I'm trying to point out is to not
trust at all cve-requests that never went under upstream eyes.
>
> > months later we have:
> > https://nvd.nist.gov/vuln/detail/CVE-2017-11720
> > "There is a division-by-zero vulnerability in LAME 3.99.5, caused by a
> > malformed input file."
>
> When we worked on your CVE ID request for the
> https://blogs.gentoo.org/ago/2017/06/17/lame-divide-by-zero-in-parse_wave_he
> ader-get_audio-c/ report, we had the information about the affected
> source-code pathname frontend/get_audio.c, and we had found the
> https://bugs.debian.org/777159 information about "this is all in the
> frontend code in frontend/get_audio.c:parse_wave_header() and not in
> the library." By contrast, the CVE-2017-11720 request had less
> technical detail about the source-code location, and the requester had
> checked the "Has vendor confirmed or acknowledged the vulnerability?"
This is right from your side, but looks to be false in the reality. The cve
was issued on 07/28/2017 while the first comment from upstream was on
08/13/2017 (https://sourceforge.net/p/lame/bugs/460/). Again do not entirely
trust request that never went under upstream eyes.
> Yes box on our https://cveform.mitre.org web site. In general, if a
> problem is only a divide-by-zero in a command-line program, but the
> upstream vendor decided to categorize it as a vulnerability, then it
> gets a CVE. Admittedly, there was no direct proof of "decided to
> categorize it as a vulnerability" here. Also, if a CVE is already
> populated, and is about this type of valid crash report, then we do
> not retroactively reject it, even if we learn more about exploitation
> relevance. We will update CVE-2017-11720 with your reference, to help
> to show that you were the original discoverer.
As said to Henri in my previous email, the problem is not the FPE itself or
something technical.
As you can clearly see I'm trying to include the asan output on each bug I
find, to make it easily-comparable and sometimes you can easily understand the
cause/nature of the issue. Unfortunately people do not do the same and this
causes the presence of duplicates.
--
Agostino Sarubbo
Gentoo Linux Developer
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.
