Vulnerability Disclosure Formats (was "Re: Funny article")
Systems Administrator <sysadmin@xxxxxxxxxxxx> said:
> Quick question: would it make sense to have somewhere:
>
>- A common (computer/human readable) format for vulnerability
> disclosures
>- A common format for bugfix publications
There are a couple proposals out there, but I don't think they've
gotten as much attention as they deserve:
Common Advisory Interchange Format
http://cert.uni-stuttgart.de/files/caif/requirements/split/requirements.html
Advisory and Notification Markup Language (ANML)
http://www.opensec.org/anml/
In addition, the Organization for Internet Safety (OIS) disclosure
guidelines have some brief recommendations for the type of information
to include:
http://www.oisafety.org/
One challenge is that there are many researchers who are first-timers,
so a common advisory format probably wouldn't find 100% adoption. But
it sure could help a lot.
Below are my own notes on the contents of security advisories.
- Steve
Security Advisory Template
--------------------------
Author: Steve Christey (coley@xxxxxxxxx)
Last Modified: February 10, 2003
Outline
-------
Here is an outline for the contents of your advisory:
- SUMMARY: critical information. Easy to scan.
- BACKGROUND: background information of the vulnerable product
- DESCRIPTION: general description of vulnerabilities
- DETAILS: additional details of the vulnerabilities
- FIXES: information on fixes, patches, or workarounds
- REFERENCES: cross-references to other documents or identifiers
- HISTORY: history of the discovery, resolution, and disclosure of the issue
- POLICY: the disclosure policy that was followed by the author
- AUTHOR: information about the author
- SIGNATURE: cryptographic signature of the advisory
Formatting
----------
THIS TEMPLATE'S FORMAT DOES NOT HAVE TO BE FOLLOWED. IT IS THE
INFORMATION IN THE TEMPLATE THAT IS IMPORTANT.
The purpose of this template is to suggest what types of information
will be useful to a varying audience. Many advisories have unique
formats.
Any format can be used, but it should
- cleanly separate major sections
- make it easy for the reader to find the most critical information.
====================== SUMMARY ========================
The summary section appears at the top of the advisory. It is
designed to make it easy for someone to quickly identify the most
important information.
Title: [Document Title here; indicate multiple issues if needed]
Date: [Date that the advisory is released to the public]
Advisory ID: [Symbolic Identifier for this document]
URL: [URL for the permanent location of this document]
Author: [Author names and email addresses]
Revision: [document's revision number]
Product: [Product name here]
OS/Platform: [Operating system and platform here]
Vendor: [Vendor name here]
Vendor URL: [URL to vendor or product site]
Vendor Status: [was the vendor informed? when? is a fix available?]
Affects: [list of versions that exhibit the problem; use specific
version numbers, not "wildcards" like 4.x]
Fixed in: [list of versions that fix the issue; avoid "wildcards"]
Risk: [would it be Critical/High/Medium/Low for most admins?
Don't use numbers unless you specify which number
means "worst risk" - is 1 high risk or low risk?]
Impact: [what can be done by exploiting the issue? Who can do it?]
Vulnerability Description: [a short description of the vulnerability,
only about 2 or 3 lines.]
Keywords: include at least "security" and "vulnerability" so that your
advisory can be found easily using search engines. This is especially
important if your advisory is published on a large or complex web
site.
Cross References: [list of alternate identifiers (e.g. CVE or Bugtraq
ID), and references to other reports on the same issue]
Where do credits go?
How about advisory version numbers?
====================== BACKGROUND ========================
Include a short description of the product:
- What does it do?
- How is it typically used? Who typically uses it?
- Include a description of the components that are affected by the
vulnerability.
=============== PROBLEM DESCRIPTION ==================
If you are reporting multiple vulnerabilities, then give each
vulnerability a short title, and clearly separate each one. Clearly
link each vulnerability with its cross-references.
For each vulnerability, include basic information such as:
- Type of vulnerability (buffer overflow, etc.)
- Who can exploit it? (Anybody? Only authenticated users? Only
users with certain privileges or group memberships? Must they be
logged on to the local system, or can they exploit it across the
network?)
- What can the attacker do as a result of exploiting the problem?
(execute commands, read or modify data, cause a crash, etc.)
- If the attacker's actions are unique to the affected component,
then explain how those actions can affect the overall product (not
every reader will understand the details of how the product works)
- Is the affected component/feature commonly used? Is it enabled by
default?
The following information is most useful in distinguishing between
closely related vulnerabilities:
- affected software version(s)
- the specific component, program, or feature that is affected
- the type of vulnerability
- cross-references
- the name of the affected argument(s) or commands
- when available, the name of the specific function(s) in which the
vulnerability resides
- any previously announced attack vectors of the issue (example:
someone might report an issue in program X, when the real problem
is in library L; mention that program X is affected)
================ ADDITIONAL DETAILS ==================
Provide additional details of the vulnerability.
This might include:
1) How easy is it to exploit the problem?
2) Are there any mitigating factors, e.g. is the problem only exposed
in certain configurations or compiler settings? Are there any
previously published issues that *appear* to be similar to this
one?]
3) Include suggestions for how an administrator may be able to tell if
their version of the product is vulnerable.
4) Demonstration information. This information will vary depending on
who is writing the advisory. Is there a way that you can
demonstrate that the vulnerability exists, without writing a
complete exploit program?
FOR RESEARCHERS AND THIRD PARTIES:
5) If the vendor disagrees with (disputes) some technical aspects of
the vulnerability (e.g., the severity or the likelihood of
exploitation), then include a vendor statement, if available.
FOR VENDORS AND DEVELOPERS:
6) If several issues have been reported at the same time for the same
package:
- Explicitly list which issues do not affect your product. This
can help reduce confusion in which customers cannot be certain
whether you're vulnerable or not.
- Include any other "less risky" vulnerabilities that you have
addressed, but which are not the focus of your advisory.
=================== FIX INFORMATION ===================
Include the following information about how the vulnerability can be
fixed or mitigated.
1) Say how administrators can obtain patches (include a URL if
available), and/or include a reference to the vendor's advisory.
2) If no official patches are available, include references to
unofficial fixes, if available.
3) Identify if there are workarounds available (such as enabling or
disabling a feature, or changing other configuration). What impact
will the workaround have on the product?
4) Include suggestions for how an administrator can tell if a fix has
been applied.
FOR VENDORS:
5) Include cryptographic checksums for your patches.
================ DISCLOSURE POLICY ==================
Identify which disclosure policy you follow (e.g. RFPolicy,
Christey/Wysopal Responsible Disclosure, or your own version).
Include a URL to the policy.
=================== DISCLOSURE HISTORY =====================
Provide a short history of how the vulnerability was discovered,
communicated to vendors and third parties, resolved, and disclosed.
Where applicable, include dates, especially:
- the date that the vendor was notified (or when notification was
attempted)
- when the vendor initially responded (including automatic and
human responses)
- when the vendor acknowledged that the issue exists
- when the vendor published a fix
- whether the release was coordinated with the vendor
When reporting dates, use any format but MM/DD/YYYY or DD/MM/YYYY
(since it is unclear whether "07/11/02" is July 11, or November 7th).
This information is useful for understanding how quickly it takes for
vendors to resolve an issue (currently, there aren't any good
statistics available). Vendors rarely report this information
themselves.
If you are a notifier/response team, you may want to include
additional information on the vendor status:
- Did you attempt to notify the vendor?
- Who did you attempt to notify? (Email, web form, phone number,
etc.)
- Were you able to identify the proper people? If not, why not?
- Did the vendor agree with the vulnerability report?
- Did the vendor fix the problem?
====================== REFERENCES ========================
List the cross-references to vulnerability identifiers or other
documents that discuss the issue.
For each reference, include:
- the name of the individual or organization
- document title or name
- date
- URL
The name, title, and date will become useful if the URL changes in the
future.
The set of references may include:
- The original announcement of the vulnerability
- Security response team
- Related vendor advisories
- Identifiers such as CVE name, Bugtraq ID, CERT VU number, etc.
- Background information (e.g. "white papers" on the type of
vulnerability found)
================ AUTHOR INFORMATION ================
Include information about yourself and/or your organization.
Authors are strongly encouraged to minimize the amount of "marketing"
or promotional material in their advisories.
================ CRYPTOGRAPHIC SIGNATURE ================
If you publish multiple advisories and wish to prove their
authenticity, then use a cryptographic signature for your advisory.
Use well-known signature methods (such as PGP or GPG) that have
publicly verifiable key archives.