Message-ID: <200208232042.QAA05003@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: HP Full Disclosure Story

[the main parties have been blind CC'ed to ensure their awareness, but
also so they don't receive double copies of responses to this email]


Georgi Guninski said:

>This clearly illustrates why the responsibility RFC is a really evil
>thing.
>
>They are using funny arguments, but consider what threats they shall
>make if they have a RFC at hand.

I have broken down this scenario relative to the details of the
Responsible Vulnerability Disclosure document.  It demonstrates that
both parties have deviated from that document to some extent.

As many have discussed on this list and elsewhere, every disclosure
scenario is different, and it has been a challenge to try and cover
reasonable scenarios in the RVD document (some have said that this
means we shouldn't even try to write a document because of this, but
I'm not so quick to give up.)  The current document does not cover
everything that appears to have occurred in this case, however it does
demonstrate a number of issues.

DISCLAIMER: This discussion assumes that the HP emails are accurately
portrayed.

- Steve


===================================================================

Sahin>I a sending my first security anouncement to security-alert@...com and
Sahin>i am specifying that in at least 4 days, if there is no response, i
Sahin>will publish this vulnerebility without any patch. (this time is like
Sahin>a law that is not ruled. in "vulnerability disclosure" procedure)

Sahin's expectation conflicts with section 3.4.1, #2, which implies
that vendor should respond within 7 calendar days.

[RVD]   2) The Vendor MUST provide the Reporter and involved Coordinators
[RVD]   with a Receipt within 7 days. 


===================================================================

HP>Thanks for the notification.  We are investigating the issue now.
HP>Hopefully this message is the response you were looking for by
HP>the four day deadline.

HP acts in accordance with 3.4.1 #2.

===================================================================

Sahin>And a week passes and there is no response from HP SECURITY
Sahin>RESPONSE TEAM.  I send a mail and i say them that the time passes over
Sahin>and if they do not publish a patch i will publish the hole in the
Sahin>security mailing lists.

3.4.1 #4 suggests that vendor should provide a clear response to the
reporter within 10 days of the initial notification date.  The dates
aren't clear here, so it isn't completely certain whether the 10 days
have passed.

[RVD]   4) Within 10 days of initial notification, the Vendor's Security
[RVD]   Response Capability SHOULD provide a clear response to the Reporter
[RVD]   and any involved Coordinators. 


===================================================================

HP>We did reply, and you are making the assumption that your issue is the
HP>only one we have to work on, and that it is the most important.

RVD 4.1, vendor policy statement, recommends that the vendor publish
the following information:

[RVD]   2) The typical amount of time after notification that the Vendor
[RVD]   requires to produce a resolution. 
[RVD]
[RVD]   3) The Grace Period, if any, that the Vendor wishes to observe. 
[RVD]
[RVD]   4) How the Vendor determines whether a reported problem is serious
[RVD]   enough to merit a security advisory. 

I do not know of any such document being published by any vendor.
However, it could have helped clarify expectations right up front -
for Sahin, and for HP's customers.

Here, the tones of the emails begin to change due to conflicting
expectations.

The HP comment is reflective of the following item from 3.6.2 #1:

[RVD]   1) The Reporter SHOULD recognize that it may be difficult for a
[RVD]   Vendor to resolve a vulnerability within 30 days if (1) the problem
[RVD]   is related to insecure design, (2) the Vendor has a diverse set of
[RVD]   hardware, operating systems, and/or product versions to support, or
[RVD]   (3) the Vendor is not skilled in security. 


===================================================================

HP>Regardless, we do not respond to threats of publishing exploits, and
HP>we do not give out advance patch code unless we need it to be beta
HP>tested, which is rare.

This is in conflict with RVD 3.5.1 #6:

[RVD]   6) The Vendor SHOULD provide status updates to the Reporter and any
[RVD]   involved Coordinators every 7 days.  The Vendor MAY negotiate with
[RVD]   the parties for less frequent updates. 

As well as RVD 3.5.1 #7:

[RVD]   7) The Vendor MUST notify the Reporter and any involved Coordinators
[RVD]   when the Vendor is able to reproduce the vulnerability. 

As well as RVD 3.6.1 #6:

[RVD]   6) The Vendor SHOULD provide the Reporter and involved Coordinators
[RVD]   with any patches ("Patch Testing"). 

In addition, because of the lack of timing information, Tamer Sahin
would not be able to tell whether the vendor will be able to follow
this recommendation:

[RVD]   8) The Vendor SHOULD attempt to resolve the vulnerability within 30
[RVD]   days of initial notification. 

And because of the lack of communication, #9 is not possible:

[RVD]   9) If the Vendor cannot resolve the vulnerability within 30 days,
[RVD]   then the Vendor MUST provide the Reporter and involved Coordinators
[RVD]   with specific reasons why the vulnerability cannot be resolved. 


===================================================================

At this stage, a third-party coordinator might have become useful, as
suggested in 3.5.2 #6, but it does not appear that either party chose
to use one.

[RVD]   6) If the Vendor is unresponsive or disagrees with the Reporter's
[RVD]   findings, then the Reporter SHOULD involve a Coordinator. 

and 3.6.1 #6:

[RVD]  7) If the Reporter is unresponsive or uncooperative, or a dispute
[RVD]   arises, then the Vendor SHOULD work with a Coordinator to identify
[RVD]   the best available resolution for the vulnerability. 

As discussed in 3.5.3, a coordinator's responsibilities in this
situation would include:

[RVD]   1) The Coordinator MUST attempt to resolve any conflicts or technical
[RVD]   disagreements that arise between the Reporter and the Vendor. 

[RVD]   2) If a Vendor is unresponsive or does not appear to be acting in
[RVD]   good faith to resolve the vulnerability, then the Coordinator SHOULD
[RVD]   attempt to convince the Vendor to follow the proper process. 

[RVD]   3) If a Reporter is unresponsive or does not appear to be acting in
[RVD]   good faith to resolve the vulnerability, then the Coordinator SHOULD
[RVD]   attempt to convince the Reporter to follow the proper process. 


===================================================================

HP> we do not discuss anything with the submitter (dates for
HP> patches, timelines, our solution, etc...) except if we have
HP> further technical questions to help us understand the problem.

This in conflict with RVD 3.5.1 #6, as previously discussed.

===================================================================

Sahin>I won't publish this anouncement and waiting reply for your solution
Sahin>or a patch.

This is in conjunction with the spirit of 3.6.1 #6:

[RVD]   2) The Reporter SHOULD grant time extensions to the Vendor if the
[RVD]   Vendor is acting in good faith to resolve the vulnerability. 

If Sahin did not believe that HP was acting in good faith at this
time, then this demonstrates an extra level of effort on his part.

===================================================================

HP>to further set expectations, we do not discuss anything with the
HP>submitter (dates for patches, timelines, our solution, etc...) except
HP>if we have further technical questions to help us understand the
HP>problem.

As discussed before, this is in conflict with various RVD
recommendations.

===================================================================

HP>I am currently out of my office until February 11th, and can
HP>only get on line randomly as I'm traveling in the western USA.
HP>So please send all communication to securtiy-alert@...com
HP>so that the team in the office sees the emails and can respond.

This demonstrates that HP has set up a Security Response Capability
(SRC), in accordance with 3.3.1 #2:

[RVD]   2) The Vendor SHOULD establish a Security Response Capability (SRC)
[RVD]   that consists of one or more individuals or groups that are
[RVD]   responsible for responding to vulnerability reports, verifying
[RVD]   vulnerabilities, releasing bulletins, etc. 

===================================================================

Sahin>Just after this mail i published the security alert on
Sahin>my site and other secuity sites. and instantaneously,
Sahin>after 2 days, they puslished the security anouncement.
Sahin>That is to say, they can be so fast if they want!!

So it appears that HP fixed the issue within 30 days of initial
notification, as recommended in 3.5.1 #8:

[RVD]   8) The Vendor SHOULD attempt to resolve the vulnerability within 30
[RVD]   days of initial notification. 


===================================================================
===================================================================
===================================================================
===================================================================

The interpretation of these results is an exercise for the reader.
Much of Sahin's actions are validated by the RVD document.  The
primary conflicts are in terms of how much time Sahin was willing to
give to HP.  Unfortunately, the current RVD document is not clear on
what's "responsible" when there is a conflict between the vendor and
reporter, and that's part of the complexity of disclosure practices.

Powered by blists - more mailing lists