SRT2003-06-20-1232 - Progress 4GL Compiler datatype overflow

[KF <dotslash () snosoft com>]

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-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 research () secnetops com for information on how
to obtain exploit information.