Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 May 2023 11:06:01 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com, Sam Bull <9m199i@...bull.org>
Subject: Re: Perl's HTTP::Tiny has insecure TLS cert default,
 affecting CPAN.pm and other modules

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@...rddimension.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@...cle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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.