|
This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C39EE1.368C4B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "KF" <dotslash@snosoft.com> To: "bugtraq" <bugtraq@securityfocus.com> Sent: Friday, June 20, 2003 5:47 AM Subject: SRT2003-06-20-1232 - Progress 4GL Compiler datatype overflow > http://www.secnetops.biz/research > > > ---------------------------------------------------------------------------- ---- > 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. > > ------=_NextPart_000_00C3_01C39EE1.368C4B20 Content-Type: text/plain; name="SRT2003-06-20-1232.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="SRT2003-06-20-1232.txt" Secure Network Operations, Inc.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = http://www.secnetops.com Strategic Reconnaissance Team=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = research@secnetops.com Team Lead = Contact=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 kf@secnetops.com Our Mission: ************************************************************************ Secure Network Operations offers expertise in Networking, Intrusion=20 Detection Systems (IDS), Software Security Validation, and=20 Corporate/Private Network Security. Our mission is to facilitate a=20 secure and reliable Internet and inter-enterprise communications=20 infrastructure through the products and services we offer.=20 Quick Summary: ************************************************************************ Advisory Number=A0=A0=A0=A0=A0=A0=A0=A0 : SRT2003-06-20-1232 Product=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Progress 4GL = Compiler Version=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : <=3D 9.1D06 Vendor=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : progress.com Class=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : local / = trivial remote Criticality=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Medium (to all = Progress users) Operating System(s)=A0=A0=A0=A0 : WIn32, *nix High Level Explanation ************************************************************************ High Level Description=A0 : Compiler datatype buffer overflow What to do=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Do not compile = untrusted Progress .p files Technical Details ************************************************************************ Proof Of Concept Status : SNO has exploits for the described situation Low Level Description=A0=A0 : Both the WIN32 and Unix variants of the Progress Application Compiler=20 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.=20 An example of a valid datatype would be "char", "integer", "date", etc.=20 When the compiler attempts to parse an invalid datatype the user is = presented=20 with the following message.=20 ** 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.=20 If however the length of the invalid datatype is beyond 364 chars the=20 Progress Compiler will segfault due to poor usage of memmove(). An = example=20 of such a data type is as follows.=20 def var andrew as = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= A AAAAAAAAAAAA00001111 In the above example 0000 is the location of the ebp and 1111 represents = where we wish the eip to point to.=20 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.=20 On Win32 exploitation can occur from within the Progress Application=20 Compiler tool which simply invokes "prowin32.exe -p". Again privs of the user running prowin32 would be obtained.=20 This issue has added risk for Win32 users due to the fact that when = using=20 the Progress Application Compiler the user is prompted to supply a file or directory name for compilation. If a directory name if provided the=20 compiler will search for *.p and attempt to compile every instance that = is=20 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.=20 The following output is a sample exploitation scenario.=20 [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=20 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=20 supply shellcode that binds a shell to a port for example.=20 As a final note Progress does have the ability to "compile on the fly" = so=20 it may be possible for users of frontend Progress applications to cause = the=20 server to execute malicious machine code.=20 Vendor Status=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Patch will be in a future = release=A0 (v10 ?) Bugtraq URL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 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. ------=_NextPart_000_00C3_01C39EE1.368C4B20--