Full Disclosure mailing list archives

SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow


From: KF <dotslash () snosoft com>
Date: Thu, 03 Apr 2003 04:43:57 -0500


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.



Current thread: