[29626] in bugtraq
SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow
daemon@ATHENA.MIT.EDU (KF)
Thu Apr 3 17:43:08 2003
Message-ID: <3E8C025D.8070204@snosoft.com>
Date: Thu, 03 Apr 2003 04:43:57 -0500
From: KF <dotslash@snosoft.com>
MIME-Version: 1.0
To: bugtraq@securityfocus.com
Content-Type: multipart/mixed;
boundary="------------030405040300090702070701"
--------------030405040300090702070701
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
--------------030405040300090702070701
Content-Type: text/plain;
name="SRT2003-04-03-1300.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="SRT2003-04-03-1300.txt"
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.
--------------030405040300090702070701--
