full-disclosure - iDEFENSE Security Advisory 09.18.2002: Security Vulnerabilities in OSF1/Tru64 3.

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]

From: coley at linus.mitre.org (Steven M. Christey)
Subject: iDEFENSE Security Advisory 09.18.2002: Security Vulnerabilities in OSF1/Tru64 3.

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