http://www.secnetops.biz/research Secure Network Operations, Inc. http://www.secnetops.com Strategic Reconnaissance Team researchat_private Team Lead Contact kfat_private 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-06-20-1232 Product : Progress 4GL Compiler Version : <= 9.1D06 Vendor : progress.com Class : local / trivial remote Criticality : Medium (to all Progress users) Operating System(s) : WIn32, *nix High Level Explanation ************************************************************************ High Level Description : Compiler datatype buffer overflow What to do : Do not compile untrusted Progress .p files Technical Details ************************************************************************ Proof Of Concept Status : SNO has exploits for the described situation Low Level Description : Both the WIN32 and Unix variants of the Progress Application Compiler suffer from a buffer overflow in the definition of datatypes. The compiler can be accessed in a number of ways, for example using the "-p" option with _progres or prowin32.exe, as well as from within the Procedure Editor. An example of a valid datatype would be "char", "integer", "date", etc. When the compiler attempts to parse an invalid datatype the user is presented with the following message. ** Invalid datatype -- sample types are: char, integer, date, logical (222) ** overflow.p Could not understand line 1. (196) Immediately after this message the application prompts the user to press the space bar to continue, then it promptly exits. If however the length of the invalid datatype is beyond 364 chars the Progress Compiler will segfault due to poor usage of memmove(). An example of such a data type is as follows. def var andrew as AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA00001111 In the above example 0000 is the location of the ebp and 1111 represents where we wish the eip to point to. On *nix platforms the _progres binary is suid root however the application does drop root privs before executing the .p file. Exploiting this issue would only grant privs of the user running _progres. On Win32 exploitation can occur from within the Progress Application Compiler tool which simply invokes "prowin32.exe -p". Again privs of the user running prowin32 would be obtained. This issue has added risk for Win32 users due to the fact that when using the Progress Application Compiler the user is prompted to supply a file or directory name for compilation. If a directory name if provided the compiler will search for *.p and attempt to compile every instance that is found. If compiling occurs from a shared drive this could become an issue because an attacker only need to drop a malicious .p file into the compile tree. Shortly after clicking the "Start Compile" button you will notice that the Progress Application Compiler is no longer responding if someone has planted such a file. The following output is a sample exploitation scenario. [elguapo@rootme dlc]$ cat /usr/dlc/version PROGRESS Version 9.1D05 as of Sun Feb 2 17:14:07 EST 2003 [elguapo@rootme dlc]$ grep system compiler_exploit.pl system("echo $buf > overflow.p"); system("gdb /usr/dlc/bin/_progres"); [elguapo@rootme dlc]$ ./compiler_exploit.pl (gdb) r -p overflow.ped Program received signal SIGTRAP, Trace/breakpoint trap. 0x40000b30 in _start () from /lib/ld-linux.so.2 (gdb) c Continuing. sh-2.05b$ As you can see above executing code is fairly easy. The trick is getting the user to compile the malicious .p. Please note that the line triggering the overflow could easily be hidden amongst many thousands of lines of code thus making it difficult to determine the malicious intent. Obviously running /bin/sh would do an attacker no good however it is very easy to supply shellcode that binds a shell to a port for example. As a final note Progress does have the ability to "compile on the fly" so it may be possible for users of frontend Progress applications to cause the server to execute malicious machine code. Vendor Status : Patch will be in a future release (v10 ?) 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 researchat_private for information on how to obtain exploit information. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Fri Jun 20 2003 - 12:00:40 PDT