Hi Steven,
> For example, there appears to be distinct difference in editorial
> policy between Oracle and Microsoft in terms of publishing
> vulnerabilities that the vendors discovered themselves, instead of
> third parties. This might produce larger numbers for Oracle, which
> appears to include internally discovered vulnerabilities in their
> advisories, whereas this is not necessarily the case for Microsoft
> [2], [3].

Oracle do not report issues they've found internally in their alerts. Every
DBn in their alerts marries up to "public" flaws.

> In both cases, the lack of details can mean that multiple
> issues wind up with one public identifier; for example, Oracle Vuln#
> DB01 from CPU Jul 2006 (CVE-2006-3698) might involve 10 different
> issues, and this is not an isolated case. This can further muddy the
> waters.

...which is why I broke every actual flaw down in the document. For example
the following flaws are all covered by CVE-2002-0154

xp_proxiedmetadata overflow CAN-2002-0154 MS02-020
xp_mergelineages overflow CAN-2002-0154 MS02-020
xp_controlqueueservice overflow CAN-2002-0154 MS02-020
xp_createprivatequeue overflow CAN-2002-0154 MS02-020
xp_createqueue overflow CAN-2002-0154 MS02-020
xp_decodequeuecmd overflow CAN-2002-0154 MS02-020
xp_deleteprivatequeue overflow CAN-2002-0154 MS02-020
xp_deletequeue overflow CAN-2002-0154 MS02-020
xp_displayqueuemesgs overflow CAN-2002-0154 MS02-020
xp_oledbinfo overflow CAN-2002-0154 MS02-020
xp_readpkfromqueue overflow CAN-2002-0154 MS02-020
xp_readpkfromvarbin overflow CAN-2002-0154 MS02-020
xp_repl_encrypt overflow CAN-2002-0154 MS02-020
xp_resetqueue overflow CAN-2002-0154 MS02-020
xp_unpackcab overflow CAN-2002-0154 MS02-020

If someone is willing to sit down and do the research the details are "out
there" and in a paper such as the comparison it was imperative to have these
details.
Cheers,
David Litchfield

[ reply ]