Message-ID: <427229B7.7050209@nospammail.net>
Date: Fri Apr 29 13:34:52 2005
From: spamproof at nospammail.net (Rob)
Subject: Questions about reporting a vulnerability

xyberpix wrote:
> Hey All,
> 
> Couple of questions on reporting vulnerabilities:
> 
> 1) Is there a damn template somewhere that can be used, as I'm pretty sure
> there was at one point, and I can't seem to find it? If so, could someone
> please let me know where this is located?
> 
> 2) Is it worth sending something out like a cookie storing usernames and
> passwords in clear text for a major vendor's piece of software?
> 
> 3) What's the correct procedure to go through reporting a vulnerability?
> 
> If all of these questions can be answered with one simple link, can
> someone please paste it, as I really need to know this info soon.
> 
> TIA
> 
> xyberpix

Good question, I looked a little and couldn't find a simple link. I like the slightly more narrative and editorial style of our own 
class 101 Jr. Researcher (you can search the FD archives for examples from them) but in general, I think we can make two lists (I'll 
label them to ease any further discussion). I'll start, but I'm not any kind of authority in the field:

======================================================
1) Some considerations regarding reporting a vulnerability:

a) Think about whether or not to report the vulnerability - some cases exist where people have been prosecuted and/or become a 
"person of intrst" for reporting vulnerabilities (I am sure will have opinions about this)

b) Decide what level of anonymity to use when reporting (see a above)

c) Decide whether to notify the vendor first and how much effort and how much time to wait before exposing the vulnerability further.
As has been discussed here recently, some people feel it is a moral imperative to give vendors at least a couple weeks before further 
disclosure. Other say screw the vendors, it is solely the spectre of full disclosure that keeps them honest at all.

d) If and/or when you decide to disclose, choose which lists or other venues to use for your disclosure.
Some don't like the freestyle atmosphere here at FD, others post to several lists simultaneously.

e) Check the CVE http://www.cve.mitre.org/ and other lists/databases to see if your "new" vulnerability is already listed or 
reported. See the FD list archives for numerous examples of re-runs. (Probably not applicable in your current case)

f) Decide whether to include POC exploit code and/or methodology to reproduce vulnerability. Some people publish reports without 
these details for various reasons.

g) Decide what, if any restrictions to put on exploit code and/or other parts of the report. Some people do this because they want to 
control what security companies put in their databases and lists. (See FD archives for examples)

==============================================
2) Things to Include in a Vulnerability Report:
(Hopefully others will chime in on these)

a) Overview/Summary - Nice but probably not necessary

b) Your Disclosure ID (If you track them and to prevent confusion for reports on the same product)

c) Date of Disclosure

d) Product Publisher and Product Name (or site) and link

e) List of tested versions, affected/at risk versions and patched/unaffected versions

f) Your estimate of Severity/Risk

g) Local or Remote Exploit (People have non-standard ways of reporting severity and local/remote/escalation risk)

h) General Description of the problem and/or the methods used in the process of working on the vulnerability.

i) Method of exposing vulnerability and/or POC code (Depending on your considerations from part 1)

j) Proposed fixes and/or patches

k) References - For instance, if you are discussing an obscure DNS vulnerability and you based some of your code on the ideas of Dan 
Kaminsky, you might reference http://www.doxpara.com/

l) Timeline - It is important (again using my moral compass) to give proper credit to all parties who helped with topics covered.
Some unscrupulous security "professionals" have, in the past, exaggerated their role in discovering vulnerabilities - which tends to 
piss off everyone who knows better, while the media at large tends to remain oblivious. Also, people like to document the timeline if 
the vendor never responded and several attempts were made to contact them and report the vulnerability/exposure.

m) Credit & Disclaimers - In this section make clear any restrictions you wish to try to impose on the information and/or code.

n) Greets, Props and Shouts - Some people like to acknowledge others in the field.

m) Misc Notes that don't fit other headings

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

That is all I can think of right now. Clear text user/password cookies are probably worth reporting (at least to the vendor) since 
some unaware user may login at a library or other public machine and expose their info (even if the connection uses SSL) - as one 
example of the multitude of ways the info could be exposed. If you can't find a way to report the vulnerability on their website, try 
security@...pany.blah or noc@...pany.blah since RFC 2412 says they are supposed to have those as working addresses.

Good Luck.

Powered by blists - more mailing lists