repost: SRT2003-04-01-1231 - Progress DLC overflows

From: KF (dotslash@snosoft.com)
Date: 04/09/03

  • Next message: drG4njubas: "Ocean12 ASP Guestbook Manager v1.00"
    Date: Wed, 09 Apr 2003 04:58:32 -0500
    From: KF <dotslash@snosoft.com>
    To: bugtraq@securityfocus.com
    
    
    

    For some reason this post did not show up in the archive for April (it
    was sent out on the 1st)
    http://www.securityfocus.com/archive/1/2003-03-29/2003-04-04/1 ... I
    also did not see it in the http://www.securityfocus.com/bid
    listing so I am sending it out again... I am sorry if you have already
    seen this.

    -KF

    
    

    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-04-01-1231
    Product : Progress Database
    Version : Versions 6 to 9.1D05
    Vendor : progress.com
    Class : local
    Criticality : High (to all Progress users)
    Operating System(s) : Linux, SunOS, SCO, TRU64, *nix

    High Level Explanation
    ************************************************************************
    High Level Description : Poor bounds checking leads to local root compromise
    What to do : Apply Progress patch 9.1D05 which is available from
    http://www.progress.com/patches/patchlst/91D-156v.htm

    Technical Details
    ************************************************************************
    Proof Of Concept Status : SNO has NUMEROUS exploits for the described situation
    Low Level Description :

    In the past Progress Software (http://www.progress.com) has had a number of security vulnerabilities.
    Most of these issues have been cross platform and spread across multiple versions of the Progress
    database. The current Progress policy is to fix the vulnerability in the most recent and supported
    version of the software in question. In efforts to illustrate the importance of upgrading your
    Progress installation I am going to detail one such cross version and cross platform vulnerability.
     
    In the Progress environment the DLC variable tells Progress where it can find the base installation
    directory. (Un)fortunately when Progress binaries request and use the DLC variable there is a lack
    of user input verification in the form of bounds checking. In both lab and customer environments
    SNOSoft has been able to use this flaw to run our shellcode (machine instructions) of choice. The
    result of our testing shows that a full root compromise is quite plausible.

    Our testing was conducted on the following Progress versions under unix based environments:

    PROGRESS Developer's Toolkit Version 6.2K02 as of Fri Dec 6 20:00:11 EST 1991
    "The PROGRESS 4GL&RDBMS" Version 6.3E14 as of Thu Sep 08 23:46:06 EDT 1994
    PROGRESS Version 7.3E as of Thu Apr 17 18:12:18 EDT 1997
    PROGRESS Version 8.2C as of Fri Feb 20 16:25:13 EST 1998
    PROGRESS Version 8.3A as of Wed Aug 5 19:01:15 EDT 1998
    PROGRESS Version 9.1C as of Wed Jun 6 20:42:24 EDT 2001
    PROGRESS Version 9.1D as of Wed May 8 16:47:54 EDT 2002

    Debugger output :

    The below information confirms the issue is valid across all versions between v6 and v9. The results
    vary depending on the stack layout of the host operating system and endian of the processor.

    First set an overly long DLC variable
    bash-2.03$ export DLC=`perl -e 'print "A" x 9000'`

    Make sure PROMSGS variable is set or you recieve the following error
    bash-2.03$ /u/dlctk/_proutil
    msgopn: unable to open PROMSGS

    bash-2.03$ export PROMSGS=/path/to/promsgs

    Earlier versions (v6) may not be exploitable (on SCO OpenServer at least) however this can not
    be confirmed at this time

    bash-2.03$ /u/dlctk/_proutil
    SYSTEM ERROR: strent request for more than 32K (893)
    ** Please save file named core for analysis by PSC. (439)
    Quit (core dumped)

    bash-2.03$ /u/dlc6/_mprosrv
    11:48:07 SYSTEM ERROR: strent request for more than 32K (893)
    11:48:07 ** Please save file named core for analysis by PSC. (439)
    Quit

    on versions beyond v7 the behavior changes to a positively exploitable situation

    # /u/dlc7/bin/_mprosrv
    (hangs and must be sent a kill signal)
    Killed

    Starting program: /u/dlc7/bin/_mprosrv

    Program received signal SIGSEGV, Segmentation fault.
    0x6fc93 in getenv ()
    (gdb) bt
    #0 0x6fc93 in getenv ()
    #1 0x6f6fa in _tz_info ()
    #2 0x75c59 in tzset ()
    #3 0x6e3f1 in localtime_r ()
    #4 0x6e2f0 in localtime ()
    #5 0x4aebb in uthms ()
    #6 0x286c in dblgm ()
    #7 0x8664 in Iomsgw ()
    #8 0x79c3 in msgout ()
    #9 0x7782 in msgn ()
    #10 0x8221 in drpfile ()
    #11 0x82c1 in drstartpf ()
    #12 0x41414141 in ?? ()
    Cannot access memory at address 0x41414141.

    # /u/dlc8/bin/_mprosrv
    (hangs and must be sent a kill signal)
    Killed

    Starting program: /u/dlc8/bin/_mprosrv
    (no debugging symbols found)...(no debugging symbols found)...
    (no debugging symbols found)...
    Program received signal SIGSEGV, Segmentation fault.
    0x80021c2d in getenv ()
    (gdb) bt
    #0 0x80021c2d in getenv ()
    #1 0x8001f2da in _tz_info ()
    #2 0x8004e5c2 in tzset ()
    #3 0x8004e4ba in _localtime_r ()
    #4 0x8001db5f in localtime ()
    #5 0x80a9d57 in uthms ()
    #6 0x804d698 in dblgm ()
    #7 0x805495d in .text ()
    #8 0x8053b73 in msgout ()
    #9 0x805394c in msgn ()
    #10 0x80544d1 in drpfile ()
    #11 0x8054581 in drstartpf ()
    #12 0x41414141 in ?? ()
    Cannot access memory at address 0x41414141.

    # /u/dlc9/bin/_mprosrv
    (hangs and must be sent a kill signal)
    Killed

    Starting program: /u/dlc9/bin/_mprosrv

    Program received signal SIGSEGV, Segmentation fault.
    Cannot remove breakpoints because program is no longer writable.
    It might be running in another process.
    Further execution is probably impossible.
    0x80087e40 in ?? ()Cannot access memory at address 0x8005400c.
    (gdb) bt
    #0 0x80087e40 in ?? ()Cannot access memory at address 0x8005400c.
    (gdb) i r
    eax 0x8131e80 135470720
    ecx 0x54 84
    edx 0x8045adc 134503132
    ebx 0x800dcc4c -2146579380
    esp 0x8044d5c 0x8044d5c
    ebp 0x800da78c 0x800da78c
    esi 0x800da78c -2146588788
    edi 0x41414141 1094795585
    eip 0x80087e40 0x80087e40
    ps 0x10206 66054
    cs 0x17 23
    ss 0x1f 31
    ds 0x1f 31
    es 0x1f 31
    fs 0x0 0
    gs 0x0 0

    Patch or Workaround : Upgrade to Progress version 9.1D05

    Recently Progress addressed the above mentioned issue in the latest 9.1D patch. Our understanding is
    that in order to receive protection from the DLC buffer overflow customers should upgrade to 9.1D05
    as soon as possible. No plans have been made to roll these fixes back to previous versions. It is
    also our understanding that the product known as 9.1C will be "retired" soon.

    Patches to the 9.1D version are available here:
    http://www.progress.com/patches/patchlst/91D-156v.htm

    The patch description is as follows:
    20021204-055 * DB - signal services

    The $DLC environment variable can be used to mount a buffer-overflow attack on Progress privileged
    binaries.

    A patched system should respond as follows:

    sh-2.05b# export DLC=`perl -e 'print "A" x 9000'`
    sh-2.05b# export PROMSGS=/usr/dlc/promsgs
    sh-2.05b# /usr/dlc/bin/_mprosrv
    12:01:06 The DLC environment variable exceeds it's maximum length of 4095 bytes
    (11001).

    a valid work around to nearly any Progress security hole is to remove the suid bit from all binaries

    Vendor Status : Patched
    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: drG4njubas: "Ocean12 ASP Guestbook Manager v1.00"

    Relevant Pages

    • [Full-Disclosure] SRT2003-04-01-1231 - Progress DLC overflows
      ... Secure Network Operations offers expertise in Networking, ... In the past Progress Software has had a number of security vulnerabilities. ...
      (Full-Disclosure)
    • Re: Question on the Love of Networking
      ... Lots of Guinness. ... Remember that as you progress, you'll start noticing that everything you learn isn't as new as it once was - a natural progression that shows you're gaining experience. ... Integrate opensource into your toolbag - it'll sharpen a number of skills along with your network skills. ... I'd suggest that you sit down with your manager and have a heart-to-heart. ...
      (comp.dcom.sys.cisco)
    • Re: Television probably wont survive beyond 2040 [OPINION]
      ... progress takes everything into account, not just production values. ... you picked what to compare Shakespeare to. ... a cable network would be lucky to get just one show squeak in at No. ...
      (rec.arts.tv)
    • Re: RWC Televised in the USA
      ... Yes, it is progress. ... ever shown on network TV in the USA. ... This time, most of the the games are on USN, which most cable companies ... a step back to the 1991 RWC, ...
      (rec.sport.rugby.union)
    • Re: Ntpd in uninterruptible sleep?
      ... That's progress, ... We need to see where ntpd is ... starting it again under gdb and breaking into gdb once it hangs. ... ntpdmain (that is, is hopefully on the correct ntpd thread, and not ...
      (comp.protocols.time.ntp)