Scribd
Upload
14 views1 page

Gray Hat Hacking 87

Chapter 3 outlines the procedures for vendors when a reported flaw is confirmed, disproved, or remains inconclusive. Vendors must provide details on affected products and fix distribution if a flaw is confirmed, while they must validate their disproof with evidence if the flaw is disproved. If unable to confirm or disprove, vendors should inform the finder and provide investigative evidence, allowing the finder to either clarify the vulnerability or release their findings publicly.

Uploaded by

digapo7593
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views1 page

Gray Hat Hacking 87

Chapter 3 outlines the procedures for vendors when a reported flaw is confirmed, disproved, or remains inconclusive. Vendors must provide details on affected products and fix distribution if a flaw is confirmed, while they must validate their disproof with evidence if the flaw is disproved. If unable to confirm or disprove, vendors should inform the finder and provide investigative evidence, allowing the finder to either clarify the vulnerability or release their findings publicly.

Uploaded by

digapo7593
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Chapter 3: Proper and Ethical Disclosure

59
Confirmation of the Flaw

PART I
In the event that the vendor confirms the flaw does indeed exist, it must follow up this
statement with the following action items:

• A list of products/versions affected by the confirmed flaw


• A statement on how a fix will be distributed
• A timeframe for distributing the fix

Disproof of the Flaw


In the event that the vendor disproves the reported flaw, the vendor then must show the
finder that one or both of the following are true:

• The reported flaw does not exist in the supported product.


• The behavior that the finder reported exists, but does not create a security
concern. If this statement is true, the vendor should forward validation data to
the finder, such as:
• Product documentation that confirms the behavior is normal or
nonthreatening.
• Test results that confirm the behavior is only a security concern when the
product is configured inappropriately.
• An analysis that shows how an attack could not successfully exploit this
reported behavior.
The finder may choose to dispute this conclusion of disproof by the vendor. In this
case, the finder should reply to the vendor with its own testing results that validate its
claim and contradict the vendor’s findings. The finder should also supply an analysis of
how an attack could exploit the reported flaw. The vendor is responsible for reviewing
the dispute, investigating it again, and responding to the finder accordingly.

Unable to Confirm or Disprove the Flaw


In the event the vendor cannot confirm or disprove the reported flaw, the vendor should
inform the finder of the results and produce detailed evidence of any investigative work.
Test results and analytical summaries should be forwarded to the finder. At this point,
the finder can move forward in the following ways:

• Provide code to the vendor that better demonstrates the proposed vulnerability.
• If no change is established, the finder can move to release their VSR to the
public. In this case, the finder should follow appropriate guidelines for
releasing vulnerability information to the public (covered later in the chapter).

Resolution
In cases where a flaw is confirmed, the vendor must take proper steps to develop a solu-
tion to fix the problem. Remedies should be created for all supported products and
versions of the software that are tied to the identified flaw. Although not required by

You might also like