Onderwerp: Vulnerability Disclosure Formats (was "Re: Funny article")

Systems Administrator <sysadmin@sunet.com.au> 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/c...uirements.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@mitre.org)
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.

If it was recommended to the public that they report their medical =
issues along some "guidelines", such as those suggested by Steve, people =
would be dropping like flies.

First, let me give a deep bow to Steve's ongoing and significant efforts =
in the vulnerability reporting arena. I don't think anyone thinks about =
this issue as much as he does.

That said, I think Steve spent too much time in school...;-]

He acknowledges;

"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."

and I agree, adoption of some format would help a lot. Adoption of a =
single language would help more, IMO, and so too would adoption of the =
concept that a vulnerability disclosure isn't anything more than =
empirical research, but we don't live in such a perfect world.

Instead we live with all sorts of Toms, Dicks, and Harriett's =
discovering all sorts of things, some actual vulnerabilities, some =
fodder for others to turn into vulnerabilities, and very little of it =
done for anything more than the pure exhilaration of discovery itself.

Given how far anyone who releases vulnerable code is from being able to =
prevent malicious attacks against their code from happening, the fact =
that anyone is willing to devote their own time and effort, for the pure =
fun of it, to helping them fix that ..."stuff"...has to be seen as pure =
gravy by those developers. Instead, unfortunately, its often not.

Appreciate that I think anyone who releases malicious code, be it in the =
form of Proof of Concept or actual worm, should serve time in a Russian =
prison. There's simply no excuse. eEye has done a great job of providing =
more than enough information about exploits over the past 2 years =
without, IMO, writing the basis for malicious code. IMO, they =
consciously choose to change the way they write their advisories. I've =
my own opinion about how disclosures turn into exploits which may be at =
odds with others, granted.

But to suggest that we need to place any more burden on discoverers, =
prior to us being able to acknowledge their will to not use their =
discoveries maliciously, is, IMO, insane.

There are very few discoveries that cannot be used for profit of the =
discoverer. To suggest they should consider posting it this way, or that =
way, only distances them further from disclosing. I'd rather get it raw =
in broken English, than to suggest they resubmit it in some "better" =
format. I'd also rather get it from them when their prepared to release =
it, rather than have them disclose it to who knows who to get it =
formatted better.

What Steve refers to, IMO, is the consumer of such reports (most of =
you), not the initial recipients (e.g. the lists who in turn forward it =
to you.)

Remember, Steve's goal is to make it simpler to use public reports to =
assess vulnerability. To minimize conflict between sellers of such =
information when an entity attempts to compare reports. This is all well =
and good for corporations who want to minimize the cost of assessing =
risk, it has nothing to do with discoverers who are reporting to the =
public for free (albeit they may have a motive.)

Despite the number of discoverers who regularly post to our lists for =
free, we, as receivers of such information, still need to make that =
process easier for them, and, more valuable to them. If we hope to keep =
such reports coming to the public realm free of charge, as opposed to =
dealing with 0-day worms that demonstrate newly discovered =
vulnerabilities, we must embrace the discoverers more than we already =
do. Asking them to do anything more than they already do, IMO, is =
counter-productive to that goal.

Thor Larholm proposed the idea of a "Union" to me. While I don't like =
the concept of union's in this day and age, our field is one that could =
benefit from such an idea wrt discoverers. They are far too often bashed =
(and I have been guilty of this), and often not recognized for what they =
do.

Granted, there are far too many of them who use their discoveries to get =
their 15 minutes of fame, a platform from which to castigate everyone =
who might consume their information. Shame, good researchers show =
themselves to be otherwise motivated sometimes. They don't do this due =
to improperly formatted advisories, we see it in their demands for =
letters for their resume suggesting they are great, or their inability =
to do anything other than recommend a feature be disabled.

OIS may be a great idea for how companies should ask for reports, and =
Steve's template thoughts make for a great basic format, but neither =
consider what happens when someone actually discovers something. The =
first thing they typically need is immediate confirmation. "Can you =
verify this?", "Does it work that way on all versions?". The discoverer, =
prior to actually submitting the discovery for public consumption wants =
to know the real scope of what they've discovered. They may be sitting =
there with their jaw dropped because their initial thinking is the =
world's going to come to an end due to what they've found.

On my list, first time or inexperienced discoverers frequently, more =
often than not, over dramatized the effects of their discovery. I'm not =
saying they are inexperienced, or unskilled, but it does seem that the =
effect of the discovery seems to make them over enthusiastic, or overly =
paranoid. They can envision a way for the exploit to be a killer, they =
haven't stopped to think about how likely that is to happen.

Sending it out for small peer review; which whether anyone other than me =
acknowledges it or not, happens when you send something to one of the =
security mailing lists...is their way of finding out whether they're =
full of it or not.

At this point in the process, I, as a receiver, don't care how its =
formatted. Of course the requisite information needs to be present (what =
OS, what product, how), but as long as the report is written credibly =
(i.e. it explains what they did and the effect they perceived it to =
have), its my job to figure the rest out. If not me, then who? The rest =
of the world should be sent in a tizzy because some schmoe claims =
something??

I don't perceive the task of Vendor X to be any different. If they =
receive a credible report, its their job to figure out if its true or =
not. That they might receive 10,000 reports a day, making the task of =
determining credible difficult, isn't the problem of the reporter. =
Imagine if 911 didn't do anything until you provided them with the =
suggested details Steve offers?

We aren't, IMO, anywhere near the time when we can suggest such things =
to discoverers. Before we do we have to announce a way for them to be =
acknowledged, compensated, and embraced. We have to differentiate them =
from the "hackers", "crackers", skript kiddiez", and other denigrating =
terms, more than we try already.

Microsoft announced a $5mm war chest to catch malcode writers, and I =
think that's a good idea. I would have liked, however, for them to =
announce a $5mm war chest to go to discoverers, like Netscape's old "Bug =
Bounty". Maybe they feel that would have been too quickly spent, but I =
know far too many discoverers who are still working on Windows 98 =
because the cost of researching on more modern platforms is prohibitive.

Anyway, bottom line, be thankful we get anything, in any format.

Cheers,
Russ - NTBugtraq Editor

Steven M. Christey wrote:

> 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/c...uirements.html
>
>
> Advisory and Notification Markup Language (ANML)
> http://www.opensec.org/anml/
>

I would also add to the list the

EISPP Common Advisory Format Description”, (EISPP-D3-001-TR), version
1.2, 28 march 2003 http://www.eispp.org/commonformat.pdf

Even if this one is slightly biased towards CERTs it could be used by
vendors too.

Regards

Javier Fernandez-Sanguino