Full Disclosure mailing list archives
Overflow in SunRPC-derived XDR libraries
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
Current thread:
- Overflow in SunRPC-derived XDR libraries hack4life (Mar 16)