Minimizing error cascades in vulnerability information management
Most of the recent disclosures for a WebSphere XSS issue
(CVE-2006-2431) mention the "faultfactor" element, including the NISCC
report, the ProCheckUp announcement, and various vulnerability
databases.
However, ProCheckUp's announcement also shows the vulnerable output:
<faultactor>
i.e., "actor" not "factor".
A web search quickly suggests that "faultactor" is, in fact, a valid
SOAP element, whereas "faultfactor" is not.
I'm only mentioning this to remind people how errors can cascade
throughout vulnerability disclosure, and it's not just grep-and-gripe
researchers who make blatant errors in remote file inclusion reports
(yes, it's a challenge for us at CVE too.) Many security advisories
demonstrate the Four-I's principle: they are either Incomplete,
Inaccurate, Inconsistent, or Incomprehensible.
Once these errors are made, one of the best defenses against repeating
them is to "trust but verify," which is not always feasible due to
limited time or resources. Another powerful defense is to identify
important discrepancies, and seek to resolve them. In this case, a
spelling discrepancy in the original ProCheckUp report triggered some
followup research. Resolving discrepancies is one of the ongoing
tasks of post-disclosure vulnerability analysis. Informative
discrepancies are frequently related to attack vectors, bug types,
affected versions, disclosure dates, and researcher credits.
- Steve