[NEWS] Progress 4GL Compiler Datatype Overflow

From: SecuriTeam (support_at_securiteam.com)
Date: 06/22/03

  • Next message: SecuriTeam: "[NEWS] New Ethereal Version Address Security Vulnerabilities" 
    To: list@securiteam.com
Date: 22 Jun 2003 16:26:07 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Beyond Security in Canada

    Toronto-based Sunrays Technologies is now Beyond Security's representative in Canada.
    We welcome ISPs, system integrators and IT systems resellers
    to promote the most advanced vulnerability assessment solutions today.

    Contact us at 416-482-0038 or at canadasales@beyondsecurity.com

    - - - - - - - - -

      Progress 4GL Compiler Datatype Overflow
    ------------------------------------------------------------------------

    SUMMARY

    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.

    DETAILS

    Vulnerable systems:
     * Progress 4GL Compiler version 9.1D06 and prior

    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, and 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
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAA00001111

    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 needs 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.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:dotslash@snosoft.com> KF.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NEWS] New Ethereal Version Address Security Vulnerabilities"

    Relevant Pages