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