[VulnWatch] SRT2003-06-20-1232 - Progress 4GL Compiler datatype overflow

From: KF (dotslash_at_snosoft.com)
Date: 06/20/03

  • Next message: dong-h0un U: "[VulnWatch] GNATS (The GNU bug-tracking system) multiple buffer overflow vulnerabilities."
    Date: Fri, 20 Jun 2003 13:54:10 +0000
    To: vulnwatch@vulnwatch.org, 0day <0day@nothackers.org>
    
    

    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.


  • Next message: dong-h0un U: "[VulnWatch] GNATS (The GNU bug-tracking system) multiple buffer overflow vulnerabilities."

    Relevant Pages