OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: KF (dotslash_at_snosoft.com)
Date: Thu Sep 19 2002 - 16:09:41 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html