Date: Thu, 6 May 1999 16:01:17 -0700
From: John Ritchie <[email protected]>
To: [email protected]Subject: Oracle Security Followup, patch and FAQ: setuid on oratclsh
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to [email protected] for more info.
--=====================_926048157==_
Content-Type: TEXT/ENRICHED; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email protected]>
All,
The following message and patch was sent to us from Oracle regarding the
oratclsh setuid vulnerability. If you're an Oracle Metalink member you
can get this patch off their website; if not then here it is.
Note that this removes oratclsh completely, and removes setuid bits from a
whole bunch of other executables. I see this is a good sign: maybe Oracle
is starting to get as nervous about weak setuid protections as we all are.
:^)=20
I've removed all the HTML formatting from the following FAQ.
John Ritchie
Systems Software Analyst
Oregon University System
---------- Forwarded message ----------
[Oracle contact names removed to protect the innocent]
This e-mail is in response to your concern expressed in your e-mail
entitled: "*Huge* security hole in Oracle 8.0.5 with Intellegent agent".=
=20
The Oracle Security Development team, along with the Oracle Worldwide
Support group have looked into this issue. We've done research and found
the setuid issue extended a bit beyond the oratclsh file.=20
So, attached is a patch in the form of a shell script which we are
issuing today to our customers via our Worldwide Customer Support web
page (MetaLink). Also below this message is the FAQ about this patch,
which is also being posted to MetaLink.=20
[more Oracle Support name info deleted]
-----=20
Q: I've heard about a setuid security issue with the Oracle database?=20
What is this all about?=20
A: On Unix platforms, some executable files have the setuid bit on. It
may be possible for a very knowledgeable user to use these executables to
bypass your system security by elevating their operating system privileges
to that of the Oracle user.=20
Q: I've also heard about a security issue with the Intelligent Agent?=20
What is this all about?
A: It=92s basically the same problem as above, but specifically applies to =
a
utility executable called oratclsh which is included in your Intelligent
Agent installation. It is a separate program that is not used by the
Intelligent Agent.
Q: Which releases are affected by this problem?
A: This problem affects Oracle data server releases 8.03, 8.0.4, 8.0.5,
and 8.1.5 on UNIX=99 platforms only.
Q: Can I correct this problem or do I need a patch?
A: This problem can easily be corrected. The customer can download the
patch from the Oracle MetaLink webpages at
<<http://www.oracle.com/support/elec_sup>;http://www.oracle.com/support/elec=
_sup.=20
The patch is a UNIX=99 shell script. This shell script should be run
<italic>immediately</italic>, and also run <italic>after each
relink</italic> of Oracle.
Q: Is the Oracle Intelligent Agent secure?
A: Yes, the Oracle Intelligent Agent is secure. All tasks performed by
the Intelligent Agent require username/password authentication. The
Intelligent Agent can only perform a task for which appropriate
credentials -- for the operating system and/or database -- have been
provided.
Q: What is Oracle doing to fix this problem?
A: Effective immediately, Oracle will provide the patch on Oracle=92s
Worldwide Support Web pages. Oracle will ensure the patches are
incorporated into future releases of Oracle8<italic>i</italic> (8.1.6) and
Oracle8.0 (8.0.6)=20
Q: What is Oracle doing to notify users about this problem now?
A: Oracle is notifying all supported customers, via the Oracle Worldwide
Support Web pages, of this issue so they can address it as required.
--=====================_926048157==_
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email protected]>
Content-Description: setuid_patch.sh
#!/bin/sh
#
# NAME
# setuid_patch.sh
#
# DESCRIPTION
# Provided as a patch to 8.0.X and 8.1.5 to fix bugs 701297, 714293.
# These bugs introduce a security hole by changing the permissions
# to affect the effective user id for executables which should not
# be set this way.
#
# PRECONDITIONS
# if ORACLE_HOME is not set, doesn't exist, or points to an
# invalid location, script exits.
#
# HOW TO USE
# This script must be run as the oracle user who installed the 8.0.3
# 8.0.4, 8.0.5 or 8.1.5 software.
#
# To run, change directories into the the directory that contains this
# file.
# % cd <patch_location_directory>
#
# Add execute permission to the patch.
# % chmod 744 setuid_patch.sh
#
# Then, invoke the script.
# % ./setuid_patch.sh
#
# MODIFIED (MM/DD/YY)
# menash 5/3/99 Initial creation
##---------------------
## VARIABLE DEFINITIONS
#-----------------------------
# potentially platform specific variables
CHMOD="/bin/chmod"
FIND="/bin/find"
CHMOD_S="$CHMOD -s" # remove set id bit
RM_F="/bin/rm -f"
LS_L="/bin/ls -l"
LS_N="/bin/ls -n" # gives uid number for owner
SED="/bin/sed"
AWK="/bin/awk"
GREP="/bin/grep"
GREP_C="$GREP -c"
GREP_V="$GREP -v"
MV="/bin/mv"
TMP_DIR="/tmp"
EXECS_TO_UNSET="lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl cmadmin cmgw names namesctl otrccref otrcfmt otrcrep otrccol oracleO"
EXECS_NOT_TO_UNSET="oracle dbsnmp"
EXECS_TO_REMOVE="oratclsh osh"
LIKELY_SUFFIXES="0 O"
ROOT_SH_815="$ORACLE_HOME/root.sh"
ROOT_SH_805="$ORACLE_HOME/orainst/root.sh"
if [ x${ORACLE_HOME} = x ] -o [ ${ORACLE_HOME} = "" ] ; then
echo "ORACLE_HOME is either unset or empty."
echo "Exiting ..."
exit 1
fi
#--------------
# usage message
SCRIPTNAME=setuid_patch.sh
USAGE="Usage: $SCRIPTNAME [-h]"
if [ $# -gt 1 ] ; then
echo
echo $USAGE
exit 2
fi
##-----------#
## FUNCTIONS #
##-----------#
# ----------
# setuid_off
# Assumes executable is in $ORACLE_HOME/bin
#
# Usage: setuid_off <executable>
#------------
setuid_off () {
exe=$1
full_path_exe=$ORACLE_HOME/bin/$exe
if [ -r $full_path_exe ] ; then
perm=`$LS_L $full_path_exe | $SED 's;r-.*;;'`
if [ $perm = "-rws" ] ; then
$CHMOD_S $full_path_exe
echo " removing set-ID from $full_path_exe"
fi
fi
}
#-----------
# remove_exe
# Assumes executable is in $ORACLE_HOME/bin
# Removes if owned by root, otherwise, calls setuid_off
# Usage: remove_exe <executable>
remove_exe () {
full_path_exe=$ORACLE_HOME/bin/$1
if [ -r $full_path_exe ] ; then
owner=`$LS_N $full_path_exe | $AWK '{print $3}'`
if [ $owner = "0" ] ; then
$RM_F $full_path_exe
echo " removing $full_path_exe..."
else
setuid_off $1
fi
fi
}
#-----------
# search_for_others
#
# Finds other executables n $ORACLE_HOME/bin which have 4000, 6000,
# or 2000 permissions except for those we expects, and warns the
# user that they should be removed manually
# Usage: search_for_others
search_for_others () {
all_others="`$FIND $ORACLE_HOME/bin -perm -2000`"
others=""
if [ x"${all_others}" != x ] ; then
for other in $all_others; do
match="false"
for exe in $EXECS_NOT_TO_UNSET; do
if [ $other = $ORACLE_HOME/bin/$exe ] ; then
match="true"
fi
done
if [ $match = "false" ] ; then
others="$others $other"
fi
done
if [ x"${others}" != x ] ; then
echo "The following executables remain with set-ID."
echo "You may need to change the permissions manually:"
for executable in $others; do
echo " $executable"
done
fi
fi
}
#--------
# remove_from_root_sh
# For each parameter it is passed, remove_from_root_sh removes all
# lines with references to that string.
# Usage: remove_from_root_sh [ string1, string2, etc. ]
remove_from_root_sh () {
strings=$*
tmp_file="root.sh.$$"
$RM_F $TMP_DIR/$tmp_file
for string in $strings; do
if [ `$GREP_C $string $ROOT_SH` != "0" ] ; then
echo " removing $string from $ROOT_SH"
fi
$GREP_V $string $ROOT_SH > $TMP_DIR/$tmp_file
$MV $TMP_DIR/$tmp_file $ROOT_SH
done
}
################
# MAIN EXECUTION
################
# Turn setuid bit off for the appropriate executables and their
# likely backups
for exe in $EXECS_TO_UNSET; do
setuid_off $exe
for suf in $LIKELY_SUFFIXES; do
setuid_off $exe$suf
done
done
# Remove files entirely which should be removed
for exe in $EXECS_TO_REMOVE; do
remove_exe $exe
done
# Determine version -- 8.0.5 or 8.1.5
# Backup existing root.sh into root.sh.old, removing references
# to EXECS_TO_REMOVE
if [ -r $ROOT_SH_805 ] ; then
ROOT_SH=$ROOT_SH_805
else
if [ -r $ROOT_SH_815 ] ; then
ROOT_SH=$ROOT_SH_815
else
echo "No root.sh found in $ORACLE_HOME"
fi
fi
if [ x${ROOT_SH} != x ] ; then
remove_from_root_sh $EXECS_TO_REMOVE
fi
# Check one last time to see if any setuid executables are left
search_for_others
--=====================_926048157==_--
