From: dotslash at snosoft.com (KF)
Subject: iDEFENSE OSF1/Tru64 3.x vuln clarification

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

Powered by blists - more mailing lists