KF asked: >How is this different from what we disclosed? >http://packetstorm.decepticons.org/advisories/misc/TRU64_advisory.txt This advisory does not have specific details, besides the overflow through the NLSPATH environment variable, and it isn't clear whether NLSPATH affects *all* the programs listed, or just some of them. The advisory alludes to "multiple overflows," and it appears to say that NLSPATH is "[just] one of the issues," but the advisory does not specifically mention long -s arguments (uucp) or -xrm (dxterm), as iDEFENSE did. Or maybe by "multiple overflows," the advisory meant "multiple executables have overflows through the same NLSPATH variable." Without the specific details, it's difficult or impossible to know whether they're the same problems or not. This is one of the challenges that are encountered when security advisories don't have precise details. For CVE, we have found that the following information is critical for 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, but library L is to blame. This is why vague vendor advisories pose such a challenge in knowing which vulnerabilities have been fixed by the vendor. The careful reader has to do a lot of research or guesswork. Without these sorts of details, it's difficult or impossible to distinguish between multiple vulnerabilities in the same product or executable. This is one reason why CVE, which strives for correctness, will not link a vague vendor acknowledgement to a more specific vulnerability report without sufficient proof or direct confirmation by the vendor... and also why we've started explicitly labeling CVE candidates when they come from vague advisories, because there's insufficient information to know whether they're duplicates of other issues or not. The lack of sufficient details should be a big deal to sysadmins and security researchers who may think they're patching one vulnerability, when in fact they may be patching something completely different. - Steve
