[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Perl's HTTP::Tiny has insecure TLS cert default, affecting CPAN.pm and other modu
From:       Alan Coopersmith <alan.coopersmith () oracle ! com>
Date:       2023-05-04 18:06:01
Message-ID: 407acc1c-dc56-d223-7ca9-d8d57532d145 () oracle ! com
[Download RAW message or body]

On 5/4/23 10:15, Sam Bull wrote:
> On Wed, 2023-05-03 at 15:54 -0400, David A. Wheeler wrote:
>>> On May 3, 2023, at 3:15 PM, Reid Sutherland <reid@thirddimension.net> wrote:
>>> Who actually decides when something receives a CVE?
>>
>> There's a process for assigning CVEs. Anyone who wants to be able to assign CVEs - that
>> is, to become a CVE Numbering Authority (CNA) - has to follow various processes.
>>
>>>   This can be used to defame projects and products as in this case.
>>
>> Identifying a vulnerability does not defame a project.
> 
> But, reporting a CVE where there is no vulnerability wastes a lot of time for the project
> maintainers, as we had last year with this CVE:
> https://github.com/aio-libs/aiohttp/issues/6801
> 
> As far as we could tell, it seems a random user reported a DoS vulnerability to Github
> (maybe?) and got a CVE assigned, with no reproducer or any evidence of a vulnerability,
> and just a link to an issue which was never considered a security issue by anybody. None
> of us involved with the project were notified of the report either, we learnt about the
> CVE from other users asking us about it.
> 
> It took months to get that satisfactorily revoked and stop getting users asking us about
> it (apparently there's no standardised way to tell if CVEs are revoked, so seems DB
> maintainers have to remove them on a case-by-case basis, making the process much longer).
> So, something somewhere is not fully working in the process.
The CVE process is designed with a primary goal of simply providing a unique id
for each claimed vulnerability - it's intended to not have much deeper meaning
than creating a UUID.   There is no requirement that the claimed vulnerability
be well described, proven, accepted, fixed, or anything else beyond not being a
duplicate of an existing CVE entry.

Unfortunately, many CVE consumers assume a far greater level of meaning to CVEs
than the CVE project intends by them.

-- 
         -Alan Coopersmith-                 alan.coopersmith@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[prev in list] [next in list] [prev in thread] [next in thread]