iDEFENSE OSF1/Tru64 3.x vuln clarification

From: KF (dotslash@snosoft.com)
Date: 09/19/02


Date: Thu, 19 Sep 2002 17:09:41 -0400
From: KF <dotslash@snosoft.com>
To: "Steven M. Christey" <coley@linus.mitre.org>

I did send an non-formal release of the information in which did go into
explicit detail.... http://online.securityfocus.com/archive/1/290115 if
you did not open the .tar file contained within I will paste the
important information below...

I certainly stand corrected on the -xrm and -s long strings to uucp and
dxterm...

Also for those of you not aware the exploits are available on our web
site...
http://www.snosoft.com/research/source/TRU64_xkb.txt
http://www.snosoft.com/research/source/TRU64_nlspath.txt
http://www.snosoft.com/research/source/TRU64_dxterm.txt
http://www.snosoft.com/research/source/TRU64_dtterm.txt
http://www.snosoft.com/research/source/TRU64_dtprintinfo.txt
http://www.snosoft.com/research/source/TRU64_dtaction.txt
http://www.snosoft.com/research/source/TRU64_su.txt

This was the information CERT STILL has not released... (included in our
labor day release)

 VU#158499 - csh vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable
 VU#510235 - dtsession vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#846307 - dxsysinfo vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable
 VU#671627 - dxchpwd vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#836275 - dtaction vulnerable to buffer overflow via long string of
characters supplied as "-contextDir" command line argument

 VU#600699 - dtprintinfo vulnerable to buffer overflow via long string
of characters supplied as "-p" command line argument
 VU#320067 - dtterm vulnerable to heap overflow via long string of
characters supplied as "-tn" command line argument

 VU#931579 - dxterm vulnerable to heap overflow via long string of
characters supplied as "-customization" command line argument

 VU#193347 - Compaq Tru64 non-executeable stack contains buffer overflow
in SIA libraries

 VU#435611 - /usr/bin/at command vulnerable to buffer overflow via long
string of characters supplied as command line argument

 VU#202939 - dtterm vulnerable to buffer overflow via long string of
characters supplied as "DISPLAY" environment variable

 VU#693803 - dxpause contains buffer overflow in _XKB_CHARSET library

 VU#569987 - dxconsole contains buffer overflow in _XKB_CHARSET library

 VU#584243 - dtsession contains buffer overflow in _XKB_CHARSET library

 VU#567963 - imapd vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#592515 - inc vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#448987 - uucp vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#437899 - uux vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#531355 - rdist vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#416427 - deliver vulnerable to buffer overflow via long string of
characters supplied as $NLSPATH environment variable

 VU#177067 - Compaq Tru64 "/usr/bin/passwd" vulnerable to buffer
overflow via long string of characters

 VU#864083 - Compaq Tru64 "/bin/chsh" vulnerable to buffer overflow via
long string of characters

 VU#137555 - chfn vulnerable to buffer overflow via long string of
character supplied as command line argument

-KF

Steven M. Christey wrote:

>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
>
>
>
>



Relevant Pages