[VulnWatch] SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow

From: KF (dotslash@snosoft.com)
Date: 04/03/03

  • Next message: KF: "[VulnWatch] SRT2003-04-04-1106 - AOLServer Proxy Daemon API unformatted syslog() call"
    Date: Thu, 03 Apr 2003 07:57:56 -0500
    From: KF <dotslash@snosoft.com>
    To: vulnwatch@vulnwatch.org
    
    
    

    
    

    Secure Network Operations, Inc. http://www.secnetops.com
    Strategic Reconnaissance Team research@secnetops.com
    Team Lead Contact kf@secnetops.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.

    Quick Summary:
    ************************************************************************
    Advisory Number : SRT2003-04-03-1300
    Product : Interbase Database
    Version : IB6.x
    Vendor : borland.com
    Class : local
    Criticality : High (to Interbase users)
    Operating System(s) : Linux (tested)

    High Level Explination
    ************************************************************************
    High Level Description : ISC_LOCK_ENV variable overflow
    What to do : fix strcat() call in gds.c or chmod -s gds_lock_mgr

    Technical Details
    ************************************************************************
    Proof Of Concept Status : We have working PoC for the described situation
    Low Level Description :

    The Interbase gds_lock_mgr checks for the ISC_LOCK_ENV upon init. This
    variable has been defined as "INTERBASE_LOCK". If the ISC_LOCK_ENV is
    over 1024 chars in length a segfault will occur. We have successfuly
    exploited this issue and have been able to run our own shellcode.

    This problem lies in one of many strcat() calls in gds.c:

    ./common.h:#define MAXPATHLEN 1024
    ./gds.c:714:#define ISC_LOCK_ENV "INTERBASE_LOCK"
    ./gds.c:425:static char ib_prefix_lock_val[MAXPATHLEN];

    void API_ROUTINE gds__prefix_lock (
        TEXT *string,
        TEXT *root)
    /********************************************************
     *
     * g d s _ $ p r e f i x _ l o c k ( n o n - V M S )
     *
     ********************************************************
     *
     * Functional description
     * Find appropriate InterBase lock file prefix.
     * Override conditional defines with the enviroment
     * variable INTERBASE_LOCK if it is set.
     *
     **************************************/
    string [0] = 0;

    if (ib_prefix_lock == NULL)
        {
        if (!(ib_prefix_lock = getenv (ISC_LOCK_ENV)))
            {
            ib_prefix_lock = ib_prefix_lock_val;
            gds__prefix(ib_prefix_lock, "");
            }
        else
            {
            strcat (ib_prefix_lock_val, ib_prefix_lock); // PROBLEM HERE
            ib_prefix_lock = ib_prefix_lock_val;
            }
        }

    During exploit development we ran into one setback. The result was the
    lack of an interactive shell. We instead run a program of in /tmp.

     [elguapo@rh8 tmp]$ cat sh.c
     main(){setuid(0);setgid(0);system("/usr/bin/id > /tmp/SNO");}
     [elguapo@rh8 tmp]$ cc -o sh sh.c
     [elguapo@rh8 tmp]$ id
     uid=500(elguapo) gid=500(elguapo) groups=500(elguapo)
     [elguapo@rh8 tmp]$ ls -al ./gds_lock_mgr
     -rwsr-sr-x 1 root root 116723 Nov 26 20:31 ./gds_lock_mgr
     [elguapo@rh8 tmp]$ ./gds_lock_mgr_ex.pl
     [elguapo@rh8 tmp]$ cat SNO
     uid=0(root) gid=0(root) groups=500(elguapo)

    Patch or Workaround : chmod -s /path/to/gds_lock_mgr or
    edit the above mentioned strcat() call in gds__prefix_lock() from ./gds.c
    to make use of strncat().

    strncat (ib_prefix_lock_val, ib_prefix_lock, sizeof(ib_prefix_lock_val)-1);

    Vendor Status : Borland was emailed several months ago. As with previous
    security contact to Borland no response was provided by the vendor.

    Bugtraq URL : not yet assigned.

    ------------------------------------------------------------------------
    This advisory was released by Secure Network Operations,Inc. as a matter
    of notification to help administrators protect their networks against
    the described vulnerability. Exploit source code is no longer released
    in our advisories. Contact research@secnetops.com for information on how
    to obtain exploit information.


  • Next message: KF: "[VulnWatch] SRT2003-04-04-1106 - AOLServer Proxy Daemon API unformatted syslog() call"

    Relevant Pages