SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.



[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux