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: <200209192044.QAA23325@linus.mitre.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ