[VIM] Vuln info from public sources and VDB rules?

Steven M. Christey coley at linus.mitre.org
Tue Jul 26 16:15:57 EDT 2005


On Mon, 25 Jul 2005, security curmudgeon wrote:

> This has come up in the past, and again more recently. Is information
> found on a vendor website, such as a changelog or bugzilla entry, fair
> game for inclusion in a vulnerability database? Some vendors seem to think
> this material is off limits.

I can understand the argument for bugzilla entries, as they could be
regarded as part of a largely internal process.  When developers ask us
for CVE ID's for issues that haven't been put in public advisories yet,
CVE considers Bugzilla entries "not sufficiently public"  although some
vendors don't seem to mind.

As a side note, I suspect that open bug reports are one of the causes of
bias in open source vs.  closed source comparisons, as all open source
bugs are public to one degree or another.

But a changelog is meant to be read by consumers, isn't it?  They're
telling their consumers that there's a vuln.

A related ethical question is the followup research that we occasionally
do to figure out specific details of a vuln, e.g. the affected executable
or the bug type.

> If a person keeps a directory of material
> regarding vulnerabilities, and it is not password protected or restricted
> in any way, are we to assume it may be private in some fashion?

Well...  if it can be linked to from the front page or obtained by reading
a download ZIP archive, that's public to me.

> The recent complaint does bring up another issue though; assigning
> vulnerable versions to the database entry.

This is extremely difficult.  First and foremost, sometimes even the
VENDORS don't know which versions are vulnerable, at least which versions
the bugs were introduced in.  Add the usual "Four I's"  problems of
inaccuracy, incompleteness, inconsistency, and incomprehensibility in
advisories, and there's a lot of guesswork.

This is just a guess, but I suspect that some VDB's are designed in ways
to support highly customized notification to customers.  So if you're a
customer who says "notify me about problems in version 1.34 of product X,"
then version completeness in the VDB is required, and it's probably safer
to notify a customer of a possible vuln in their version.

> VDBs using public information such as bugtrackers and changelogs may have
> a long term negative impact though. The Caudium Group has closed its
> bugtracker to the public in response to Secunias vulnerability listing. If
> more vendors follow suit, this will make more detailed information
> unavailable to VDBs and impact the quality of the information we can
> provide.

This is already a big problem with many vendors, though, and I don't think
it's solvable.  We encountered a lot of difficulties in early CVE because
we made certain content decisions that required perfect and
complete information, but the reality is that it's rarely available -
whether by intentional or accidental omission.

And it's a damned-if-we-do damned-if-we-don't problem.  Either way we
don't get good coverage.

Good point, though - I should have added it to my "why VDB's don't do
everything" rant :)

- Steve


More information about the VIM mailing list