Re: HP Full Disclosure Story

[full-disclosure () lists netsys com (full-disclosure () lists netsys com)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve, your interpretation is atrocious. Two simple facts:

1. Tamer is clearly not a native English speaker, this can be gleaned from his approach amongst other more direct things
2. Grove is a little dickhead wrapped up in his own self-importance (president of first, cfo of  first, Member Steering 
Committee) lamest .sig on the internet

1. Tamer submits a bug and says answer in 4 days or I go public
2. Grove or his boyfriend says hello, we answered you, okay?
3. 1 week goes by, Tamer contacts them again says hey what's happening
4. Grove comes back and says your bug is not so important we have other things to do
5. Tamer quite rightly says fuck you and makes it public

end of story

Grove should be fired on the spot. He's a disgrace to HP and as a shareholder in HP, I am going to lodge a complaint.

Steven, instead of beating this draft to death at every possible opportunity, could you focus on the CVE database? As 
it stands the format is woefully not user friendly. Viewing Candidates and Viewing ther other thing (i forget what its 
called), as html or text, it requires downloading the entire database everytime and then searching through it which is 
a pain. How about setting it up like this this pipermail list where it is broken off into quarters or weeks so that one 
can view this months candidates or accepted entries (i forget what its called. It is a pain to search the entire 
database when viewing in the browser everytime. Have a section for "this weeks" candidates and "this weeks approved 
entries (i forget what its called).  Thanks.

By the way, do you know what the next best next invention to the internet is? P2P networks. This morning i awoke with a 
craving to listen to neil young, so I fired up winmx and sought out the tunes I wanted to hear. Ah, feels good. Then I 
decided to burn them onto cd. Isn't that wonderful. Did you know that out of say dollar 30 for a cd, the artists get 
something like 50 cents or maybe a dollar. The rest goes to the recoding company and into the owners pocket. they claim 
it goes into advertising and marketing but I don't believe them. I mean when last was Southern Man advertised? A CD 
costs something like 3 to 5 cents in bulk from a Malaysian factory, so we have say 1.05 dollars costs at the most. 
Where;s the 28.95 go one wonders. I think that's why they call the rich fat cats "movie moguls" and "recording moguls".

Did you know that Skynard's "sweet home alabama" is in direct response to Young's "Southern Man",,,a lot of people 
don't know that.

A lot of people don't know a lot of things.


- -Original Message -----
Steven M. Christey sed:

[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 () hp 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 () hp 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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmcEARECACcFAj1nwIYgHGNob29zZS5hLmx1c2VybmFtZUBodXNobWFpbC5jb20ACgkQ
T4xCkuLXILpnaACfc7i1jgQNdDt0tny4GoSPTQpSY8UAniFMgR5MZ6tiZ3vSliOIIxe7
ka/7
=FfBu
-----END PGP SIGNATURE-----




Get your free encrypted email at https://www.hushmail.com