Date: Fri, 30 Apr 1999 14:11:39 +0100 From: Anthony Clarke To: BUGTRAQ@netspace.org Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed oracle-digested ------------- Begin Forwarded Message ------------- Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed >From: Dan Sugalski Date: Thu, 29 Apr 1999 08:34:30 -0700 X-Message-Number: 46 Subject: oracle-digested Folks, This is a big heads up for everyone. If you're running Oracle 8.0.5 on a Unix box, do *not* install and configure the Intellegent Agent option. If you have, find the bin/oratclsh file and REMOVE THE SUID BIT! oratclsh is a Tcl app that provides full access to Tcl. It's also installed as suid root. Running oratclsh gives anyone with even the most modest Tcl knowledge the ability to execute arbitrary Tcl commands *while running as root*! This includes the exec command, which spawns off a subshell (as root) to run any command on the system. Anyone with half a brain is exactly three commands away from full root access. Anyone with a whole brain is exactly *one* command away from full root access. This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It probably exists in all Unix versions of 8.0.5. Whether it exists in later versions is unknown. (I don't believe it exists in 8.0.4, but I can't verify that at the moment) I also don't know if it affects non-Unix versions of 8.0.5. Once again, Intellegent Agent only needs to be *installed* (and the root.sh part of the setup run) to open this hole. The agent does *not* need to be started--just installed. Dan ---------------------------------------------"it's like this"-------------- Dan Sugalski (541) 737-3346 even samurai SysAdmin have teddy bears Oregon University System and even the teddy bears sugalskd@ous.edu get drunk ---------------------------------------------------------------------- ------------- End Forwarded Message ------------- ============ ================================== Ian Harrison Phone: +44 (0)181 214 2121 Oracle DBA Fax: +44 (0)181 214 4473 One2One Email: ian.harrison@one2one.co.uk ============ ================================== ------------- End Forwarded Message ------------- ----------------------------------------------------------------------------------- Date: Sat, 1 May 1999 11:18:34 +0200 From: Markus Friedl To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote: > This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It > probably exists in all Unix versions of 8.0.5. Whether it exists in later > versions is unknown. (I don't believe it exists in 8.0.4, but I can't > verify that at the moment) verified: the sbit-hole _does_ exists version 8.0.4/solaris, too: ORATCLSH for Solaris: Version 8.0.4.0.0 - Production on 01-MAY-99 11:14:41 -markus ----------------------------------------------------------------------------------- Date: Fri, 30 Apr 1999 16:49:03 -0700 From: John Ritchie To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent On Fri, 30 Apr 1999, Anthony Clarke wrote: > ------------- Begin Forwarded Message ------------- > > Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed > From: Dan Sugalski > Date: Thu, 29 Apr 1999 08:34:30 -0700 > X-Message-Number: 46 > Subject: oracle-digested > > Folks, > > This is a big heads up for everyone. If you're running Oracle 8.0.5 on a > Unix box, do *not* install and configure the Intellegent Agent option. If > you have, find the bin/oratclsh file and REMOVE THE SUID BIT! > > oratclsh is a Tcl app that provides full access to Tcl. It's also installed > as suid root. Running oratclsh gives anyone with even the most modest Tcl > knowledge the ability to execute arbitrary Tcl commands *while running as > root*! This includes the exec command, which spawns off a subshell (as > root) to run any command on the system. Anyone with half a brain is exactly > three commands away from full root access. Anyone with a whole brain is > exactly *one* command away from full root access. > > This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It > probably exists in all Unix versions of 8.0.5. Whether it exists in later > versions is unknown. (I don't believe it exists in 8.0.4, but I can't > verify that at the moment) I also don't know if it affects non-Unix > versions of 8.0.5. > > Once again, Intellegent Agent only needs to be *installed* (and the root.sh > part of the setup run) to open this hole. The agent does *not* need to be > started--just installed. > > Dan > Here's the followup for this (rather, the original story): I opened a TAR with Oracle on this and, after typical Oracle shuffling ("It's not a bug it's a feature", "We don't know how that got there", "You'll have to file an Enhancement Request", etc) they finally got back to me today to say that this will be fixed in future releases (8.0.6, etc.). On current releases one should just chown the $ORACLE_HOME/bin/oratclsh to oracle (or whoever the install userid is); on Linux and Solaris that will also remove the suid bit. When I pressed them as to whether or not they would release patches and information to users who already have 8.0.5 installed they said they had no mechanism to do that. In other words, YOYO. (They could learn something about patch releases and access from their good buddies at Sun). So if you've installed Oracle's Intelligent Agent or aren't sure if it's installed then check your oratclsh and fix that bit. The only systems I've had experience on are 8.0.5 for Solaris and Linux but I'd check any 8.x release on any platform if it were mine. John Ritchie Systems Software Analyst Oregon University System ----------------------------------------------------------------------------------- Date: Mon, 3 May 1999 14:31:46 +0000 From: David Adrian To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent John Ritchie wrote: > On Fri, 30 Apr 1999, Anthony Clarke wrote: > > > When I pressed them as to whether or not they would release patches and > information to users who already have 8.0.5 installed they said they had > no mechanism to do that. In other words, YOYO. (They could learn > something about patch releases and access from their good buddies at Sun). > > So if you've installed Oracle's Intelligent Agent or aren't sure if it's > installed then check your oratclsh and fix that bit. The only systems > I've had experience on are 8.0.5 for Solaris and Linux but I'd check any > 8.x release on any platform if it were mine. > > John Ritchie > Systems Software Analyst > Oregon University System I patched my Linux version of oracle to 8.0.5.1. When I checked for this vulnerability, the suid bit was not set, and the ownership of oratclsh was oracle.oracle. So it seems likely that upgrading to 8.0.5.1 will fix the problem. On Linux, this was necessary to fix many other nasty bugs anyway. David Adrian temp99@mstg.net ----------------------------------------------------------------------------------- Date: Mon, 3 May 1999 08:34:45 -0500 From: Dave Diehl To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested > On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote: >> This hole has been verified on both Linux and Solaris with Oracle 8.0.5. >> It probably exists in all Unix versions of 8.0.5. Whether it exists in >> later versions is unknown. (I don't believe it exists in 8.0.4, but I >> can't verify that at the moment) > verified: this hole exists under Oracle 8.0.5 on Digital Unix. -Dave Diehl Systems/Network Manager Carleton College ----------------------------------------------------------------------------------- Date: Mon, 3 May 1999 18:31:36 -0500 From: Jeff Long To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent David Adrian wrote: > > John Ritchie wrote: > > > On Fri, 30 Apr 1999, Anthony Clarke wrote: > > So if you've installed Oracle's Intelligent Agent or aren't sure if it's > > installed then check your oratclsh and fix that bit. The only systems > > I've had experience on are 8.0.5 for Solaris and Linux but I'd check any > > 8.x release on any platform if it were mine. > I patched my Linux version of oracle to 8.0.5.1. When I checked for this > vulnerability, the suid bit was not set, and the ownership of oratclsh was > oracle.oracle. > So it seems likely that upgrading to 8.0.5.1 will fix the problem. On Linux, > this was necessary to fix many other nasty bugs anyway. Well, I patched to 8.0.5.1 on Digital Unix a while ago and discovered on Friday that oratclsh was still suid root so at least on my platform 8.0.5.1 did not solve the problem. Jeff Long ----------------------------------------------------------------------------------- Date: Tue, 4 May 1999 09:41:24 -0400 From: Paul Diehl To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote: > This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It > probably exists in all Unix versions of 8.0.5. Whether it exists in later > versions is unknown. (I don't believe it exists in 8.0.4, but I can't > verify that at the moment) This hole exists for Oracle 8.0.3 on Solaris as well. Paul Diehl Oracle Database Administrator Sumaria Systems, Inc. Contractor F-16 System Program Office (ASC/YPOM) DSN 785-8719, COMM (937) 255-8719 diehlpb@paranor.wpafb.af.mil ----------------------------------------------------------------------------------- Date: Tue, 4 May 1999 02:56:04 +0200 From: Kis-Szabo Andras To: BUGTRAQ@netspace.org Subject: Re: Oracle Intellegent agent installedoracle-digested On Mon, 3 May 1999, Dave Diehl wrote: =- > On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote: =- >> This hole has been verified on both Linux and Solaris with Oracle 8.0.5. =- >> It probably exists in all Unix versions of 8.0.5. Whether it exists in =- >> later versions is unknown. (I don't believe it exists in 8.0.4, but I =- >> can't verify that at the moment) Oracle8i 8.1.5 Solaris 7 -rwsr-s--x 1 root dba 1402152 May 3 01:08 /oracle/bin/oratclsh After the install. This version never run here before. -- Kis-Szabo Andras Technical University of Budapest -----------------------------/ Schonherz Zoltan Dormitory kisza@sch.bme.hu /-------------------------------3OO---->>.Info Fingerprint = 97 D7 32 CE F9 74 5C A0 E5 F4 09 29 67 9F A8 78 ----------------------------------------------------------------------------------- Date: Wed, 5 May 1999 00:22:34 -0400 From: Chris Hallenbeck To: BUGTRAQ@netspace.org Subject: Re: Oracle Intellegent agent installedoracle-digested On Tue, 4 May 1999, Kis-Szabo Andras wrote: > Oracle8i 8.1.5 Solaris 7 > -rwsr-s--x 1 root dba 1402152 May 3 01:08 /oracle/bin/oratclsh > > After the install. This version never run here before. Solaris 2.6 with Oracle8.0.5 ...installed by the userid "oracle", hence we have: -rwsr-s--x 1 oracle dba 1492432 Jan 7 08:19 oratclsh Solution? Try running the majority of the install as the "oracle" user. Comments? HTH! -Chris Hallenbeck -- ---------------------------------------------------------- Chris Hallenbeck UNIX Systems Administrator Computing Services cthallen@binghamton.edu Binghamton University Phone: 607-777-6188 Binghamton, NY 13902-6000 Fax: 607-777-4009 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ----------------------------------------------------------------------------------- Date: Wed, 5 May 1999 16:52:44 +0800 From: Yung-Sheng Tang To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested On Tue, 4 May 1999, Paul Diehl wrote: > On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote: > > This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It > > probably exists in all Unix versions of 8.0.5. Whether it exists in later > > versions is unknown. (I don't believe it exists in 8.0.4, but I can't > > verify that at the moment) > > This hole exists for Oracle 8.0.3 on Solaris as well. > Maybe not. Our Oracle 8.0.3 on Solaris doesn't have root-owned oratclsh. ----------------------------------------------------------------------------------- Date: Wed, 5 May 1999 14:04:38 +0200 From: "Peter.Fredriksson@Skriptor.com" To: BUGTRAQ@netspace.org Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested -----Original Message----- From: Anthony Clarke [SMTP:Anthony.Clarke@one2one.co.uk] Sent: Friday, April 30, 1999 3:12 PM To: BUGTRAQ@netspace.org Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It probably exists in all Unix versions of 8.0.5. Whether it exists in later versions is unknown. (I don't believe it exists in 8.0.4, but I can't verify that at the moment) I also don't know if it affects non-Unix versions of 8.0.5. -----Original Message----- And is now verified on AIX. Oracle 8i 8.0.5 on AIX 4.3.1.0 running on a RS/6000 F50: -rwsr-xr-x 1 root dba 6849934 Jul 13 1998 oratclsh My best regards, Peter Fredriksson Systems administrator Skriptor AB email - Peter.Fredriksson@Skriptor.com ----------------------------------------------------------------------------------- Date: Thu, 6 May 1999 13:36:33 -0700 From: John Ritchie To: BUGTRAQ@netspace.org Subject: Re: Oracle Intellegent agent installedoracle-digested On Wed, 5 May 1999, Chris Hallenbeck wrote: > On Tue, 4 May 1999, Kis-Szabo Andras wrote: > > > Oracle8i 8.1.5 Solaris 7 > > -rwsr-s--x 1 root dba 1402152 May 3 01:08 > /oracle/bin/oratclsh > > > > After the install. This version never run here before. > > Solaris 2.6 with Oracle8.0.5 ...installed by the userid "oracle", hence > we have: > -rwsr-s--x 1 oracle dba 1492432 Jan 7 08:19 oratclsh > > Solution? Try running the majority of the install as the "oracle" user. > > Comments? > > HTH! > > -Chris Hallenbeck The root setuid gets set when you run the post-install root.sh as root (per the install instructions). If you don't run root.sh as root (directly after the Intelligent Agent install - remember Oracle creates a new root.sh with every install) then the file will be owned by the installer ID (typically oracle). I would suggest that setuid oracle on that file is bad enough. The simple exploit will then get you oracle:dba privs instead of root, but that would be enough to have full control of the database. Oracle's recommended fix of removing the setuid bit would still apply. John Ritchie Oregon University System ----------------------------------------------------------------------------------- Date: Thu, 6 May 1999 16:01:17 -0700 From: John Ritchie To: BUGTRAQ@netspace.org Subject: Oracle Security Followup, patch and FAQ: setuid on oratclsh Parts/Attachments: 1 Shown ~92 lines Text (charset: ISO-8859-1) 2 Shown 225 lines Text, "setuid_patch.sh" ---------------------------------------- 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. :^) 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". 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. 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. [more Oracle Support name info deleted] ----- Q: I've heard about a setuid security issue with the Oracle database? What is this all about? 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. Q: I've also heard about a security issue with the Intelligent Agent? What is this all about? A: It^Òs 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^Ù 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. The patch is a UNIX^Ù shell script. This shell script should be run immediately, and also run after each relink 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^Òs Worldwide Support Web pages. Oracle will ensure the patches are incorporated into future releases of Oracle8i (8.1.6) and Oracle8.0 (8.0.6) 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. [ Part 2: "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 # # 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 #------------ 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 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