Bugtraq mailing list archives
iDEFENSE OSF1/Tru64 3.x vuln clarification
From: KF <dotslash () snosoft com>
Date: Thu, 19 Sep 2002 17:09:41 -0400
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.txtThis 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 libraryVU#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.txtThis 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
Current thread:
- Re: [Full-Disclosure] iDEFENSE Security Advisory 09.18.2002: Security Vulnerabilities in OSF1/Tru64 3. Steven M. Christey (Sep 19)
- iDEFENSE OSF1/Tru64 3.x vuln clarification KF (Sep 19)