full-disclosure - Re: [CVE 2007-3816] [Advisory] Vulnerability Facts Related JWIG Advisory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.51.0707261723210.21841@faron.mitre.org>
Date: Thu, 26 Jul 2007 17:24:00 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: debasis.mohanty.listmails@...il.com, full-disclosure@...ts.grok.org.uk
Subject: Re: [CVE 2007-3816] [Advisory] Vulnerability
 Facts Related JWIG Advisory

[sorry for any duplication]

Regarding the JWIG issue: this seems more like a description of a
*class* of vulnerabilities that could apply to an application written
in JWIG, if the application allows an attacker to influence the
contents of a template (which seems quite possible).  CVE does not
handle vulnerability classes (that's more the job of CWE), so we
probably should not have assigned an identifier.

Speaking of CVE...

Debasis Mohanty said:

>this is not first time a CVE been assigned to a fake claims.

grep for "** DISPUTED **" in the descriptions, and you'll see this is
the case (over 250 by last count, which is about 1% of all publicly
reported issues, including some cases where the vendor disputes the
issue but it's probably legit).

>history has proven that many clowns in the past had their fake claim
>promoted by getting a CVE tagged.

In the vulnerability information management world, you basically have
three options when this kind of thing happens:

 - highlight the issue with dispute (CVE) or "Myth/Fake" (OSVDB)

 - delete the issue entirely without any tracing (others)

 - dedicate extensive resources to verify every claim, and/or don't
   publish until you're confident the claim is real (CERT and others)

When researchers seem to make frequent errors, we will put them on an
informal watch list, and de-prioritize their reports (when we're busy)
or try to verify or rebut them ourselves (when we've got time).

>It is understood that with more are more exponentially replicating
>clowns in the industry it is hard for mitre to validate all vague
>claims.

We cannot verify every claim, and certainly vague claims cannot be
verified.  NOBODY has the resources to verify every single claim (see
[1] if you care).

We rely on vendor contacts and public acknowledgements, public
commentary on mailing lists, other refined vulnerability information
sources, and our own analysis (where feasible).  We used to have
voting by the CVE Editorial Board, but that got too unwieldy for them
due to the volume.

Over the years, CVE's role has evolved to become something of a
universal bug tracker, so the percentage of closely-reviewed issues
has decreased, alas.  The growth of grep-and-gripe research is
definitely a factor, but as Simple Nomad said [2], the system of
disclosure-by-mailing-list still works.

- Steve

[1] Why Vulnerability Databases can't do everything
    http://marc.info/?t=112145271100004&r=1&w=2

[2] Re: local Calendar System v1.1 (lcStdLib.inc) Remote File Include
    http://seclists.org/bugtraq/2007/Jan/0662.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/