Symlink attack with Solaris Update manager and Sun Patch Cluster

Larry W. Cashdollar

Vapid Labs http://vapid.dhs.org

1/24/2010

With the GUI Sun Update Manager being used to install patches on a system
local users can easily run scripts and create symlinks in an attempt to
clobber files and potentially escalate privileges as this application is
typically run in multi-user mode.
Many patches use insecure file creation in /tmp to store data during
installation. The easiest one to exploit is /tmp/CLEANUP which is used in a
handful of package installation scripts:

script code is typically:

CLEANUP_FILE=/tmp/CLEANUP
 echo "EXISTING_FILE_PRESERVED: ${dest} ${dest}.${TAG}" \
                        >> ${CLEANUP_FILE}
Similar code is found in:

./118833-36/SUNWcsr/install/i.renamenew
./118833-36/SUNWcsr/install/u.initd
./118833-36/SUNWcsr/install/i.initd
./118833-36/SUNWcsr/install/preinstall
./118833-36/SUNWintgige/install/i.renamenew
./118833-36/SUNWvolr/install/u.initd
./118833-36/SUNWvolr/install/i.initd
./118833-36/SUNWsndmu/install/postinstall
./118833-36/SUNWsacom/install/i.initd
./118833-36/SUNWsacom/install/u.initd
./118833-36/SUNWsndmr/install/postinstall
./118833-36/SUNWsndmr/install/i.renameold
./120272-26/SUNWsmmgr/install/u.initd
./120272-26/SUNWsmmgr/install/i.initd
./137093-01/SUNWcsr/install/i.renameold
./137137-09/SUNWnxge.u/install/i.renameold
./137137-09/SUNWcsr/install/i.renamenew
./137137-09/SUNWcsr/install/i.renameold
./137137-09/SUNWckr/install/i.renameold
./137137-09/SUNWnxge.v/install/i.renameold
./141444-09/SUNWixgbe/install/i.renamenew
./141444-09/SUNWnxge.u/install/i.renamenew
./141444-09/SUNWnxge.v/install/i.renamenew
./127127-11/SUNWtsg/install/preinstall
./127127-11/SUNWtsg/install/i.renamenew
./127127-11/SUNWtsu/install/i.renamenew
./127127-11/SUNWypr/install/i.renameold
./127127-11/SUNWcsr/install/i.group
./127127-11/SUNWcsr/install/i.pamconf
./127127-11/SUNWcsr/install/i.passwd
./127127-11/SUNWcsr/install/i.renamenew
./125555-06/SUNWcsu/reloc/usr/lib/patch/patch_override_dir/137137_SUNWnxge_i.renameold
./122660-10/SUNWcsr/install/preinstall
./119313-29/SUNWwbcor/install/i.initd
./119313-29/README.119313-29
./120011-14/SUNWckr/install/i.renameold
./120011-14/SUNWcsr/install/i.renamenew
./120011-14/SUNWcsr/install/i.renameold
./120011-14/SUNWcsr/install/preinstall
./120011-14/SUNWsndmu/install/postinstall
./120011-14/SUNWsndmr/install/i.renameold
./121453-02/undo_pkgs.pkg
./121453-02/payload.pkg
./121453-02/SUNWppror/install/i.initd
./122911-19/README.122911-19
./122911-19/SUNWapchr/install/i.initd
./122911-19/SUNWapchr/install/i.renamenew
./122911-19/SUNWapchr/install/u.initd
./122911-19/SUNWtcatr/install/i.renamenew
./139555-08/SUNWcsr/install/i.renamenew
./120543-15/SUNWapch2r/install/i.renamenew
./125215-03/SUNWwgetr/install/i.renamenew

If a user creates a symlink to a root owned file, /etc/shadow for example
it will be clobbered by the patch installation process if that patch
application applies to the system.

$ cd /tmp $ ln -s /etc/shadow CLEANUP

I was able to append the contents of CLEANUP to /etc/shadow.

There are other attackable files that are created as well. I have only
investigated the easiest one however.