iDEFENSE OSF1/Tru64 3.x vuln clarification

[dotslash () snosoft com (KF)]

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