Re: [CVEPRI] Handling new vulnerabilities discovered by Steve Christey

[Adam Shostack <adam@homeport.org>]

Alice discovers a vulnerability, and wants to tell Bob, but thinks Bob 
may steal it.  As a cryptographer, I see an easy solution.  Alice
takes her description of the problem, hashes it, and publishes the
hash result in a widely archived forum.  (I'd suggest Bugtraq or
NTbugtraq, if their moderators are willing to let these through.)  If
Bob cheats, Alice publishes the file containing the description, and
anyone can see that she had that description when she published the
hash.

Now, this doesn't address the issue of Alice and Bob discovering the
same thing at the same time, but it ensures that Alice can demonstrate 
that she had the information at some early time.

Adam


On Wed, Sep 20, 2000 at 08:10:45PM -0400, Steven M. Christey wrote:
| All:
| 
| I recently discovered some new vulnerabilities in some software.  I
| have been working with the software vendor to ensure that a fix is
| made available before I publicize it to the usual places.  I also plan
| to include candidate numbers in my initial announcement.
| 
| Due to the increased analysis going on behind the scenes for CVE
| candidates, as well as some other non-CVE work I'm involved in with
| respect to developing source code analysis tools, it is likely that I
| or another member of the CVE content team will discover more
| vulnerabilities in the future.
| 
| There are some potential areas in which there may be a real or
| perceived conflict of interest that I wanted to review with Board
| members.  Your feedback is appreciated, and you can reply directly to
| me if you wish to make private comments.
| 
| 1) I am somewhat concerned that if I disclose these vulnerabilities,
|    then it may discourage others from requesting CVE candidate numbers
|    from me in the future.  Some people may fear that if they provide
|    me with details when requesting a candidate, that I could turn
|    around and announce it, then claim that I was the discoverer.  This
|    is a concern because we will be opening candidate reservation
|    (formerly called private candidate assignment) up to more people in
|    the coming months.
| 
|    I assume that Board members would not have this problem of trusting
|    me :-) However, candidate reservation will be available to anyone
|    who asks, including individuals who may not trust me.  If such an
|    event were to theoretically happen, it would be my word against
|    theirs.
| 
|    A mitigating factor in this is that I would expect to personally
|    notify and work with vendors on all newly discovered
|    vulnerabilities, in which case the vendor could be a neutral third
|    party.  In addition, those who request candidate numbers do not
|    necessarily need to provide me with any details.
| 
| 2) Diligence Level 1 for CVE candidate reservation allows the
|    assignment of 1 CVE candidate number to an unknown party.  (See
|    http://cve.mitre.org/board/archives/2000-05/msg00179.html).  Since
|    I have not announcced any vulnerabilities in the past, in that
|    sense I am an unknown party, and my diligence level would be 1.
|    However, in the case of my discovery, 2 separate vulnerabilities
|    will be disclosed.  To be established at diligence level 2,
|    however, I would need to have announced at least 3 new security
|    problems.
| 
|    Should an exception be made for "trusted people who haven't
|    announced 3 new security vulnerabilities" (assuming I'm trusted ;-)
|    Or should I be forced to only use one candidate?  Does anybody care
|    about diligence levels anyway?
| 
| 3) Regardless of how I obtain a candidate number before announcement,
|    the candidate will move through the remainder of the Editorial
|    Board review process like any other candidate, subject to the same
|    voting requirements as others.
| 
| Let me know what you think.  I believe the vendor will have the fixes
| ready in a few days.
| 
| Thanks,
| - Steve

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume