Re: [TECH] Candidate Numbering Authorities

["Steven M. Christey" <coley@linus.mitre.org>]

Shawn Hernan asked:

>If a candidate is assigned, and the report is later found to be bogus
>or duplicative, are there any obligations on the CNA to account for
>the "missing number?" Or can it just be sent to /dev/null?

We've effectively done this a couple of times already.  I'll "release"
a candidate by silently making a final decision.  I've removed a few
duplicate candidates this way, before they were ever proposed to the
Board; there were other cases in which the entity reserving the
candidate didn't need it any more.  There isn't a public account of
what happened to the number, but it was never public anyway.

I think that a CNA would need to tell MITRE that one of their
candidates got "released" just to help with bookkeeping.

If a candidate has been publicized, though, I think it needs to go
through the normal review process by the Board, in order to provide a
public record of what happened to it.  That means that there if
someone reserves and then publicizes a candidate for a duplicate
issue, that candidate would still need to be proposed to the Editorial
Board for the sole purpose of rejecting it.  This almost happened with
CAN-2001-0145 (the Outlook vcard buffer overflow), which was a
rediscovery of CAN-2000-0756.  But in that case, CAN-2001-0145 was
more authoritative, as it was associated with a Microsoft advisory.
(See the voting record for more detail.)  In that case, I didn't check
for a duplicate when assigning the candidate, and @stake hadn't found
a duplicate either.  This is why both researcher and CNA should be
responsible for making sure the problem isn't a duplicate.

>Must numbers within the pool be handed out sequentially? Will the pool
>necessarily be contiguous? One of the things we are mildly concerned
>with is leaking information about who (particularly vendors) knew what
>when as regards a vulnerability.

This also has happened.  In that case, I released the older candidates
and provided new ones shortly before the advisory was released.  I
understand that some Board members may prefer the use of "older"
candidates, as they can become concrete proof of how long it takes a
vendor to fix a problem.  However, it was not appropriate at the time
for me to mention that this had happened, as it could have made it
easier for someone to infer who the affected vendor was.  However,
there have been 170 candidates reserved, and 18 others released, so it
seems reasonable to discuss this particular issue.

With respect to the assignment of contiguous blocks, this has worked
to some extent with Microsoft, the only other de facto CNA at this
time.  Some "older" candidates do show up this way on occasion; for
example I think Microsoft once released a CAN-2001-02xx when we were
somewhere in the 400's.  But that happened because the particular
candidate happened to be one of the last ones in the block.

The rationale for providing blocks is to minimize the chance that a
CNA needs a candidate "right away" from MITRE, but MITRE for whatever
reason is not able to respond immediately.  I've given out candidates
less than 3 hours before publication of an issue, but I can't
personally guarantee that type of responsiveness.  Others on the CVE
content team will be helping to keep that level of responsiveness, but
there is always the chance of a delay which could adversely impact the
disclosure process.

We could provide smaller blocks or individual candidates to another
CNA in accordance with their own needs for timeliness.  In the early
discussions of candidates, some people suggested having a web site
where users (possibly only trusted users) could reserve a candidate
when they needed it.  Others recently mentioned this approach to me as
well.  It seems reasonable to consider providing this sort of
functionality.

>>   - suspected researcher abuses

>Although we can report a "faulty" number, we can't report on
>individuals' intentions if they wish to remain anonymous. Does this
>imply a requirement to disclose researcher identities for those who
>wish to remain anonymous?

Ummm... uhhhhh...  At the least if the CNA is confident of abuse, then
the CNA probably should not provide that individual with candidates
anymore.  An interesting question.

>>   - they should not publish CVE candidate numbers in a manner which
>>     might provide them with any economic or political advantage over
>>     their competitors

>"might provide...any" is a little broad.

It's intentional, partially because it's difficult to think of a
concrete scenario :-) But consider an organization that provides a
commercial alerting service, which also functions as a CNA.  If the
organization provides candidates as a "value added" for their service
while intentionally delaying the disclosure of those candidates to
others, then that seems like abuse to me.  It doesn't seem like it
should be a problem with issues that impact "critical infrastructure."
This issue is very fuzzy.

>We sometimes disclose information to sponsors and collaborators
>privately under NDA before public dissemination, and we support that
>practice in general. It seems reasonable to me that a candidate number
>could be part of that private disclosure. Would such disclosure be
>prohibited?

This situation has also happened already.  Someone reserved a
candidate very early in the process, knowing that it would be months
before it became public, but with the intention of publishing the
candidate once the problem was appropriately addressed.  I don't see
much of a problem with it, besides the evidence that the number itself
would give of the "age" of an issue.

One of the challenges that we face with candidate reservation in
general is that it may expose or publicize how the disclosure process
works "behind the scenes."


>>   - obtain the candidate from the vendor, if the vendor is a CNA
>
>What about when the vulnerability affects multiple vendors? Would any
>of the vendor CNAs be appropriate?

I think that this is one of the more complex issues: how multiple
affected vendors can coordinate and share the same candidate.


>>   - publish through known reliable channels (vendor or response team),
>>     or known public channels with peer review (Bugtraq or NTBugtraq)
>
>I assume the parenthetical clauses are just examples, right? A paper at
>Crypto would be just fine, wouldn't it? Or do you mean to require the
>availability of this information freely on the web?

In most cases I would think that issues that were published at a
conference would have vendor acknowledgement, which itself would
involve a web-based reference.  The CVE "style" has gravitated towards
using web-based references, but I was just providing examples.


- Steve