[Full-Disclosure] Overflow in SunRPC-derived XDR libraries

From: hack4life@hushmail.com
Date: 03/16/03

  • Next message: Jason Coombs: "[Full-Disclosure] AOL's Billion SPAM March on Cyberspace"
    To: full-disclosure@lists.netsys.com
    From: hack4life@hushmail.com
    Date: Sun, 16 Mar 2003 07:06:12 -0800
    

    -----BEGIN PGP SIGNED MESSAGE-----

    Original release date: March xx, 2003
    Last revised: --
    Source: CERT/CC

    A complete revision history can be found at the end of this file.

    Systems Affected

    Applications using vulnerable implementations of SunRPC-derived XDR
    libraries, which include, but are not limited to:
    * Sun Microsystems network services library (libnsl)
    * BSD-derived libraries with XDR/RPC routines (libc)
    * GNU C library with sunrpc (glibc)

    Overview

    There is an integer overflow present in the xdrmem_getbytes() function
    distributed as part of the Sun Microsystems [1]XDR library. This
    overflow has been shown to lead to remotely exploitable buffer
    overflows in multiple applications, leading to the execution of
    arbitrary code. Although the library was originally distributed by Sun
    Microsystems, multiple vendors have included the vulnerable code in
    their own implementations.

    I. Description

    The XDR (external data representation) libraries are used to provide
    platform-independent methods for sending data from one system process
    to another, typically over a network connection. Such routines are
    commonly used in remote procedure call ([2]RPC) implementations to
    provide transparency to application programmers who need to use common
    interfaces to interact with many different types of systems. The
    xdrmem_getbytes() function in the XDR library provided by Sun
    Microsystems contains an [3]integer overflow that can lead to
    improperly sized dynamic memory allocation. Subsequent problems like
    buffer overflows may result, depending on how and where the vulnerable
    xdrmem_getbytes() function is used.

    This issue is currently being tracked as [4]VU#516825 by the CERT/CC
    and [5]CAN-2003-0028 in the Common Vulnerabilities and Exposures (CVE)
    dictionary.

    Note that this vulnerability is similar to, but distinct from,
    [6]VU#192995.

    II. Impact

    Because SunRPC-derived XDR libraries are used by a variety of vendors
    in a variety of applications, this defect may lead to a number of
    differing security problems. Exploiting this vulnerability will lead
    to denial of service, execution of arbitrary code, or the disclosure
    of sensitive information.

    Specific impacts reported include the ability to crash the rpcbind
    service and possibly execute arbitrary code with root privileges. In
    addition, intruders may be able to crash the MIT KRB5 kadmind or cause
    it to leak sensitive information, such as secret keys.

    III. Solution

    Apply a patch from your vendor

    [7]Appendix A contains information provided by vendors for this
    advisory. As vendors report new information to the CERT/CC, we will
    update this section and note the changes in our revision history. If a
    particular vendor is not listed below or in the [8]vulnerability note,
    we have not received their comments. Please contact your vendor
    directly.

    Note that XDR libraries can be used by multiple applications on most
    systems. It may be necessary to upgrade or apply multiple patches and
    then recompile statically linked applications.

    Applications that are statically linked must be recompiled using
    patched libraries. Applications that are dynamically linked do not
    need to be recompiled; however, running services need to be restarted
    in order to use the patched libraries.

    System administrators should consider the following process when
    addressing this issue:
    1. Patch or obtain updated XDR/RPC libraries.
    2. Restart any dynamically linked services that make use of the
    XDR/RPC libraries.
    3. Recompile any statically linked applications using the patched or
    updated XDR/RPC libraries.

    Disable access to vulnerable services or applications

    Until patches are available and can be applied, you may wish to
    disable access to services or applications compiled with the
    vulnerable xdrmem_getbytes() function.

    As a best practice, the CERT/CC recommends disabling all services that
    are not explicitly required.

    Appendix A. - Vendor Information

    This appendix contains information provided by vendors for this
    advisory. As vendors report new information to the CERT/CC, we will
    update this section and note the changes in our revision history. If a
    particular vendor is not listed below or in the individual
    [9]vulnerability notes, we have not received their comments.

    [VENDOR DETAILS OMITTED FROM DRAFT --CERT/CC]
    _________________________________________________________________

    Appendix B. - References

    1. [18]VU#192995
    2. [19]VU#516825
    3. [20]RFC1831
    4. [21]RFC1832
    _________________________________________________________________

    Thanks to Riley Hassell of [22]eEye Digital Security for discovering
    and reporting this vulnerability. Thanks also to Sun Microsystems for
    additional technical details.
    _________________________________________________________________

    Authors: [23]Chad Dougherty and Jeffrey Havrilla

    Copyright 2003 Carnegie Mellon University.

    Revision History
    Mar xx, 2003: Initial release

    References

    1. http://www.ietf.org/rfc/rfc1832.txt
    2. http://www.ietf.org/rfc/rfc1831.txt
    3. http://www.kb.cert.org/vuls/id/516825
    4. http://www.kb.cert.org/vuls/id/516825
    5. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0028
    6. http://www.kb.cert.org/vuls/id/192995
    7. file://localhost/XDR.html#vendors
    8. http://www.kb.cert.org/vuls/id/516825
    9. http://www.kb.cert.org/vuls/
    [VENDOR LINKS OMITTED FROM DRAFT --CERT/CC]
    18. http://www.kb.cert.org/vuls/id/192995
    19. http://www.kb.cert.org/vuls/id/516825
    20. http://www.ietf.org/rfc/rfc1831.txt
    21. http://www.ietf.org/rfc/rfc1832.txt
    22. http://www.eeye.com/
    -----BEGIN PGP SIGNATURE-----
    Version: Hush 2.2 (Java)
    Note: This signature can be verified at https://www.hushtools.com/verify

    wl4EARECAB4FAj51Az8XHGhhY2s0bGlmZUBodXNobWFpbC5jb20ACgkQgSjHzuae7+pj
    9ACggco8KRLn3NdxHs3pZInjVoe+f+0AoLK75A/uUVey9l8QxRjT74ljyvxU
    =0fVy
    -----END PGP SIGNATURE-----

    Concerned about your privacy? Follow this link to get
    FREE encrypted email: https://www.hushmail.com/?l=2

    Big $$$ to be made with the HushMail Affiliate Program:
    https://www.hushmail.com/about.php?subloc=affiliate&l=427
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: Jason Coombs: "[Full-Disclosure] AOL's Billion SPAM March on Cyberspace"

    Relevant Pages

    • Re: Web Application Scanners Comparison
      ... it should get a -5 if it didn't found a valid vulnerability. ... found it's better than rating the coverage of the application. ... applications seems to be the same type. ... 3 demo applications provided by the vendors ...
      (Pen-Test)
    • Re: Standard Library Interest?
      ... Not everyone is good at designing "libraries" for> general use, and so I would suggest that in a library sense,> some *are* more suitable for others. ... I would add that there needs> to be a more "general purpose computing" focus, to get Ada into> more mainstream use. ... :-)> If there is enough other interested parties, then perhaps a> "competition" of sorts between different teams could be> arranged. ... Like I mentionned elsewhere I'd be lying if I didn't wanna get paid for this effort especially if it's gonna help the vendors. ...
      (comp.lang.ada)
    • Re: Can MS listen to customers?
      ... IE is comprised of a set of libraries that other applications use. ... a HUGE portion of even a minimal install of Windows (or even in ... For Windows, Notepad, Paint, IE, OE, msconfig, Wordpad, Hearts, NT ...
      (microsoft.public.windowsxp.general)
    • Re: Standard Library Interest?
      ... >> You are willing to trust that the vendors will get things going. ... I finally received my printed copy of the Ada Letters last ... There is visible evidence that ACT is ... > or more - attempts to get various libraries of stuff started. ...
      (comp.lang.ada)
    • Re: Standard Library Interest?
      ... > and start calling it the Conventional Ada Library..." ... We definitaly need libraries of all kinds, ... architectures like ALSA woudl be a good idea too so that Ada developers can ... > I don't even think it would need to be all the vendors. ...
      (comp.lang.ada)