Secure Network Operations, Inc. http://www.secnetops.com
Strategic Reconnaissance Team research_at_secnetops.com
Team Lead Contact kf_at_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-24-1532.txt
Product : Options Parsing Tool shared library
Version : <= opt-3.18
Vendor : http://nis-www.lanl.gov/~jt/
Class : local
Criticality : Low
Operating System(s) : Linux (other unix based?)
High Level Explanation
************************************************************************
High Level Description : Error messages can cause buffer overflow
What to do : recompile and link against newest libopt.a
Technical Details
************************************************************************
Proof Of Concept Status : No PoC needed for this issue.
Low Level Description :
The Options Parsing Tool shared library is a subroutine library which
facilitates the convenient input of parameters to a C or C++ program.
The package attempts to provide a direct and relatively full-featured
input interface to the end user of the program, and at the same time
impose a minimal amount of work on the programmer to "attach" the package
to his or her software.
I am not aware of any suid programs linking against this library but
at the very least Debian provides it as a .deb package. Obvious issues
are raised if a suid application makes use of the OPT libraries.
http://packages.debian.org/stable/devel/opt.html
The error messages in opt pass through one of several functions in order
to print the error to the screen. Either opt_warn_1(), opt_warn_2(),
opt_warn_3(), opt_fatal_1(), opt_fatal_2(), or opt_fatal_3() will be
used when an error occurs. Several similar functions could cause issues
with buffer overflows.
This simple test will show the problems associated with using <= opt-3.18
[dotslash_at_vegeta test]$ cat > test.c
main(int *argc, char **argv)
{
/* use lubc atoi() */
int x = atoi(argv[1]);
printf("atoi(): %i\n", x);
/* use OPT opt_atoi() */
int y = opt_atoi(argv[2]);
printf("opt_atoi(): %i\n", y);
}
[dotslash_at_vegeta test]$ cc -o test test.c ../src/libopt.a
[dotslash_at_vegeta test]$ ./test 1 2
atoi(): 1
opt_atoi(): 2
[dotslash_at_vegeta test]$ ./test `perl -e 'print "A" x 986'` B
atoi(): 0
OPT Warning: String [B] is not a valid integer, will use [0]
opt_atoi(): 0
[dotslash_at_vegeta test]$ ./test A `perl -e 'print "A" x 986'`
atoi(): 0
OPT Warning: String
[AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
is not a valid integer, will use [0]
opt_atoi(): 0
Segmentation fault
strace tells us that we are able to overwrite the eip.
[41414141] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
This occurs because of the following code is triggered when reading
input from the user.
long
opt_atoi(char *s)
{
int valid;
long x;
x = (long)atof(s); /* Call atof() whether or not string is valid,
* because some strings, eg '15x' can still be
* interpreted as numeric. But give a warning
* unless the string really is valid
*/
valid = opt_isvalidnumber(s);
if (!valid || (valid & OPT_NUM_FLOAT)) {
opt_warn_2("String [%s] is not a valid integer, will use [%ld]",s,x);
}
return x;
}
This particular segfault was caused by the opt_warn_2 definition in opt_p.h.
You can see that the data passed on by the user is used in a sprintf() into
a static sized buffer.
#define OPT_ERRMAXSTRLEN 1024 /* shouldn't be fixed length, but it is! */
...
#define opt_warn_2(fmt,var1,var2) do { \
char gstr[OPT_ERRMAXSTRLEN]; sprintf(gstr,fmt,var1,var2); \
opt_warning(gstr); } while(0)
A diff with the new version shows the implementation of snprintf as a valid fix.
< char gstr[OPT_ERRMAXSTRLEN]; sprintf(gstr,fmt,var1,var2,var3); \
---
> char gstr[OPT_ERRMAXSTRLEN]; \
> opt_snprintf_3(gstr,OPT_ERRMAXSTRLEN,fmt,var1,var2,var3); \
A quick test compile against the new version of libopt.a appears to take care
of the problem.
[dotslash_at_vegeta test]$ pwd
/home/dotslash/opt/opt-3.19/test
[dotslash_at_vegeta test]$ cc -o test test.c ../src/libopt.a
[dotslash_at_vegeta test]$ ltrace ./test A `perl -e 'print "A" x 1986'`
...
snprintf("String [AAAAAAAAAAAAAAAAAAAAAAAA"..., 1024, "String [%s] is not a valid integ"...
Patch or Workaround : Relink applications that use libopt.a against the
new version of opt at http://nis-www.lanl.gov/~jt/Software/opt/opt-3.19.tar.gz
Vendor Status : Author has responded and applied a fix to the problem.
Bugtraq URL : to be 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_at_secnetops.com for information on how
to obtain exploit information.
Received on Apr 24 2003
Intro
