Original release date: March 19, 2003<br>
Last revised: April 9, 2003<br>
Source: CERT/CC<br>
<p>A complete revision history can be found at the end of this file.</p>
<br>
<a name="affected"></a>
<h3>Systems Affected</h3>
Applications using vulnerable implementations of SunRPC-derived XDR
libraries, which include
<ul>
<li>Sun Microsystems network services library (libnsl)
<li>BSD-derived libraries with XDR/RPC routines (libc)
<li>GNU C library with sunrpc (glibc)
</ul>
<br>
<a name="overview"></a>
<h2>Overview</h2>
<p>
There is an integer overflow in the <i>xdrmem_getbytes()</i> function
distributed as part of the Sun Microsystems <a
href="http://www.ietf.org/rfc/rfc1832.txt">XDR library</a>. This
overflow can cause 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.
</p>
<a name="description"></a>
<h2>I. Description</h2>
<p>
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 (<a
href="http://www.ietf.org/rfc/rfc1831.txt">RPC</a>) implementations to
provide transparency to application programmers who need to use common
interfaces to interact with many different types of systems. The
<i>xdrmem_getbytes()</i> function in the XDR library provided by Sun
Microsystems contains an <a
href="http://www.kb.cert.org/vuls/id/516825">integer overflow</a> that
can lead to improperly sized dynamic memory allocation. Depending on
how and where the vulnerable <i>xdrmem_getbytes()</i> function is
used, subsequent problems like buffer overflows may result.
</p>
<p>Researchers at <a href="http://www.eeye.com/">eEye Digital
Security</a> discovered this vulnerability and have also published an
<a
href="http://www.eeye.com/html/Research/Advisories/AD20030318.html">advisory</a>.
This issue is currently being tracked as <a
href="http://www.kb.cert.org/vuls/id/516825">VU#516825</a> by the
CERT/CC and as <a
href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0028">CAN-2003-0028</a>
in the Common Vulnerabilities and Exposures (CVE) dictionary. Note
that this vulnerability is similar to, but distinct from, <a
href="http://www.kb.cert.org/vuls/id/192995">VU#192995.
</p>
<a name="impact"></a>
<h2>II. Impact</h2>
<p>
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
security problems. Exploiting this vulnerability will lead to denial
of service, execution of arbitrary code, or the disclosure of
sensitive information.
</p>
<p>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.
</p>
<a name="solution"></a>
<h2>III. Solution</h2>
<h4>Apply a patch from your vendor</h4>
<p>Apply the appropriate patch or upgrade as specified by your vendor. See <a href="#vendors">Appendix A</a> below and the <a href="http://www.kb.cert.org/vuls/id/516825#systems">Systems Affected</a> section of VU#516825 for further information.
</p>
<p>
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.
</P>
<p>
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.
</P>
<p>
System administrators should consider the following process when
addressing this issue: <br>
<ol>
<li>Patch or obtain updated XDR/RPC libraries.
<li>Restart any dynamically linked services that make use of the XDR/RPC libraries.
<li>Recompile any statically linked applications using the patched or updated XDR/RPC libraries.
</ol>
</p>
<h4>Disable access to vulnerable services or applications</h4>
<p>Until patches are available and can be applied, you may wish to
disable access to services or applications compiled with the
vulnerable <i>xdrmem_getbytes()</i> function.
<p>
As a best practice, the CERT/CC recommends disabling all services
that are not explicitly required.
</p>
<a name="vendors"></a>
<h2>Appendix A. - Vendor Information</h2>
<p>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, we have not received their
comments.
<a name="apple"></a>
<h4>Apple Computer, Inc.</h4>
<p>
Mac OS X and Mac OS X Server do not contain
the vulnerabilities described in this report.
</p>
<!-- end vendor -->
<a name="Cray"></a>
<h4>Cray, Inc.</h4>
<p>
Cray Inc. may be vulnerable and has opened spr's
724153 and 724154 to investigate.
</p>
<!-- end vendor -->
<a name="Fujitsu"></a>
<h4>Fujitsu</h4>
<p>
We are currently investigating how the vulnerability reported under
VU#516825 affects the Fujitsu UXP/V O.S. We will update this
statement as soon as new information becomes available.
</p>
<!-- end vendor -->
<a name="glibc"></a>
<h4>GNU glibc</h4>
<p>Version 2.3.1 of the GNU C Library is vulnerable. Earlier versions
are also vulnerable. The following patches have been installed into the
CVS sources, and should appear in the next version of the GNU C
Library. These patches are also available from the following URLs:<br>
<blockquote>
<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/rpc/xdr.h.diff?r1=1.26&r2=1.27&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/rpc/xdr.h.diff?r1=1.26&r2=1.27&cvsroot=glibc</a>
<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_mem.c.diff?r1=1.13&r2=1.15&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_mem.c.diff?r1=1.13&r2=1.15&cvsroot=glibc</a>
<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_rec.c.diff?r1=1.26&r2=1.27&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_rec.c.diff?r1=1.26&r2=1.27&cvsroot=glibc</a>
<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_sizeof.c.diff?r1=1.5&r2=1.6&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_sizeof.c.diff?r1=1.5&r2=1.6&cvsroot=glibc</a>
<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_stdio.c.diff?r1=1.15&r2=1.16&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sunrpc/xdr_stdio.c.diff?r1=1.15&r2=1.16&cvsroot=glibc</a>
</blockquote>
</p>
<p>
<pre>
2002-12-16 Roland McGrath <roland@redhat.com>
* sunrpc/xdr_mem.c (xdrmem_inline): Fix argument type.
* sunrpc/xdr_rec.c (xdrrec_inline): Likewise.
* sunrpc/xdr_stdio.c (xdrstdio_inline): Likewise.
2002-12-13 Paul Eggert <eggert@twinsun.com>
* sunrpc/rpc/xdr.h (struct XDR.xdr_ops.x_inline): 2nd arg
is now u_int, not int.
(struct XDR.x_handy): Now u_int, not int.
* sunrpc/xdr_mem.c: Include <limits.h>.
(xdrmem_getlong, xdrmem_putlong, xdrmem_getbytes, xdrmem_putbytes,
xdrmem_inline, xdrmem_getint32, xdrmem_putint32):
x_handy is now unsigned, not signed.
Do not decrement x_handy if no change is made.
(xdrmem_setpos): Check for int overflow.
* sunrpc/xdr_sizeof.c (x_inline): 2nd arg is now unsigned.
(xdr_sizeof): Remove cast that is now unnecessary, now that
x_handy is unsigned.
</pre>
[ text of diffs available in the links included above --CERT/CC ]
</p>
<!-- end vendor -->
<a name="HP"></a>
<h4>Hewlett-Packard Company</h4>
<p>
RE: HP Case ID SSRT2439
<p>
At the time of writing this document,
Hewlett Packard is currently investigating
the potential impact to HP's released Operating
System software products.
<p>
As further information becomes available HP
will provide notice of the availability of any
necessary patches through standard security
bulletin announcements and be available from
your normal HP Services support channel.
</p>
<!-- end vendor -->
<a name="Hitachi"></a>
<h4>Hitachi</h4>
<p>
Hitachi's GR2000 gigabit router series - is NOT vulnerable.<br>
<br>
Hitachi's HI-UX/WE2 - is NOT vulnerable, because it does not support RPC/XDR Library.<br>
</p>
<!-- end vendor -->
<a name="ibm"></a>
<h4>IBM Corporation</h4>
<p>
The AIX operating system is vulnerable to the issues discussed in
CERT vulnerability note VU#516825 in releases 4.3.3, 5.1.0 and 5.2.0.
<p>
IBM provides the following official fixes:
<p>
<blockquote>
APAR number for AIX 4.3.3: IY38524<br>
APAR number for AIX 5.1.0: IY38434<br>
APAR number for AIX 5.2.0: IY39231<br>
</blockquote>
<p>
Please contact your local IBM AIX support center for any assistance.
</p>
<!-- end vendor -->
<a name="Ingrian"></a>
<h4>Ingrian Networks</h4>
<p>
Ingrian Networks products are not succeptable to the
vulnerabilities in VU#516825.
</p>
<!-- end vendor -->
<a name="kerberos-mit"></a>
<h4>MIT Kerberos Development Team </h4>
<p>It may be possible for a remote attacker to exploit an integer
overflow in xdrmem_getbytes() to crash the kadmind server process by a
read segmentation fault. For this to succeed, the kadmind process
must be able to allocate more than MAX_INT bytes of memory. This is
believed to be unlikely, as most installations are not likely to
permit that the allocation of that much memory.
</p>
<p>
It may also be possible for a remote attacker to exploit this integer
overflow to obtain sensitive information, such as secret keys, from
the kadmind process. This is believed to be extremely unlikely, as
there are unlikely to be ways for the information, once improperly
copied, of being returned to the attacker. In addition, the above
condition of the kadmind being able to allocate huge amounts of memory
must be satisfied.
</p>
Please see <a href="http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-003-xdr.txt">http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-003-xdr.txt</a>
<p>
This patch may also be found at:<br>
<a href="http://web.mit.edu/kerberos/www/advisories/2003-003-xdr_patch.txt">http://web.mit.edu/kerberos/www/advisories/2003-003-xdr_patch.txt</a>
<p>
The associated detached PGP signature is at:<br>
<p>
<a href="http://web.mit.edu/kerberos/www/advisories/2003-003-xdr_patch.txt.asc">http://web.mit.edu/kerberos/www/advisories/2003-003-xdr_patch.txt.asc</a>
<!-- end vendor -->
<a name="NEC"></a>
<h4>NEC Corporation</h4>
<p>
[Server Products]
* EWS/UP 48 Series operating system
- is NOT vulnerable.
</p>
<!-- end vendor -->
<a name="netbsd"></a>
<h4>NetBSD</h4>
<p>
The length types of the various xdr*_getbytes functions were made consistent
somewhere back in 1997 (all u_int), so we're not vulnerable in that area.
</p>
[Note: the NetBSD project has released <a href="ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-008.txt.asc">NetBSD Security Advisory 2003-008</a> in response to this issue --CERT/CC]
<!-- end vendor -->
<a name="netapp"></a>
<h4>Network Appliance</h4>
<p>NetApp products are not vulnerable to this issue.</p>
<!-- end vendor -->
<a name="nokia"></a>
<h4>Nokia</h4>
<p>
This issue has no relationship to the product we ship.
</p>
<!-- end vendor -->
<a name="nortel"></a>
<h4>Nortel Networks</h4>
<p>The following Nortel Networks Wireless products are potentially
affected by the vulnerability identified in VU#516825:
</p>
CDMA SDMX<br>
CS2000 SSPFS<br>
GBMD (GSM Billing Mediation Device)<br>
GSM CIPC<br>
SS7IP Gateway<br>
OAM&P Main & Performance Servers<br>
<p>
Nortel Networks recommends applying the latest Sun Microsystems
patches in accordance with that vendor's recommendations.
</p>
<p>
Other Nortel Networks products are being investigated to determine if
they are potentially affected by the vulnerability identified in
VU#516825 and this statement will be updated as more information
becomes available.
</p>
<!-- end vendor -->
<a name="openwall"></a>
<h4>Openwall GNU/*/Linux</h4>
<p>
The xdrmem_getbytes() integer overflow discovered by eEye Digital
Security was present in the glibc package on Openwall GNU/*/Linux
until 2003/03/23 when it was corrected for Owl-current (with a
back-port from the glibc CVS) and documented as a security fix in the
system-wide change log available at:</p>
<blockquote>
<a href="http://www.openwall.com/Owl/CHANGES-current.shtml">http://www.openwall.com/Owl/CHANGES-current.shtml</a>
</blockquote>
<p>
Please note that Owl does not include any RPC services (but it does
include a few RPC clients). It has not been fully researched whether
an Owl install with no third-party software added is affected by this
vulnerability at all.
</p>
<!-- end vendor -->
<a name="sgi"></a>
<h4>SGI</h4>
<p>SGI acknowledges receiving CERT VU#516825 and is currently investigating.
This is being tracked as SGI Bug# 880925. No further information is
available at this time.
<p>
For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and any
necessary patch(es) or release streams are available for all vulnerable
and supported SGI operating systems. Until SGI has more definitive
information to provide, customers are encouraged to assume all security
vulnerabilities as exploitable and take appropriate steps according to
local site security policies and requirements. As further information
becomes available, additional advisories will be issued via the normal
SGI security information distribution methods including the wiretap
mailing list on <a href="http://www.sgi.com/support/security/">http://www.sgi.com/support/security/</a>
</p>
<p>
[Note: SGI has subsequently released SGI Security Advisory <a href="ftp://patches.sgi.com/support/free/security/advisories/20030402-01-P">20030402-01-P</a> in response to this issue. Users are encouraged to review this advisory and apply the patches it refers to. --CERT/CC]
</p>
<!-- end vendor -->
<a name="sun"></a>
<h4>Sun Microsystems</h4>
<p>
Solaris 2.6, 7, 8 and 9 are vulnerable to VU#516825.<br>
<br>
Sun will be publishing a Sun Alert for the issue at the following location
shortly:<br>
<a href="http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsalert/51884">http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsalert/51884</a>
<br>
<br>
The Sun Alert will be updated with the patch information as
soon as the patches are available.<br>
<br>
At that time, the patches listed in the Sun Alert will be available from:
<a href="http://sunsolve.sun.com/securitypatch">http://sunsolve.sun.com/securitypatch</a>
</p>
<!-- end vendor -->
<a name="toplayer"></a>
<h4>Top Layer Networks</h4>
<p>Top Layer Networks products do not contain the vulnerabilities described in this CERT Advisory.
</p>
<!-- end vendor -->
<hr noshade>
<a name="refs"></a>
<h2>Appendix B. - References</h2>
<ol>
<li><a name="eeye"></a><a href="http://www.eeye.com/html/Research/Advisories/AD20030318.html">AD20030318.html</a> - http://www.eeye.com/html/Research/Advisories/AD20030318.html
<li><a name="vul-note"></a><a href="http://www.kb.cert.org/vuls/id/192995">VU#192995</a> - http://www.kb.cert.org/vuls/id/192995
<li><a name="vul-note"></a><a href="http://www.kb.cert.org/vuls/id/516825">VU#516825</a> - http://www.kb.cert.org/vuls/id/516825
<li><a name="rpc"></a><a href="http://www.ietf.org/rfc/rfc1831.txt">RFC1831</a> - http://www.ietf.org/rfc/rfc1831.txt
<li><a name="xdr"></a><a href="http://www.ietf.org/rfc/rfc1832.txt">RFC1832</a> - http://www.ietf.org/rfc/rfc1832.txt
</ol>
<hr noshade>
<p>Thanks to Riley Hassell of <a href="http://www.eeye.com">eEye Digital Security</a> for discovering and reporting this vulnerability. Thanks also to Sun Microsystems for additional technical details.</p>
<p></p>
<hr noshade>
<p>Authors: <a
href="mailto:cert@cert.org?subject=CA-2003-10%20Feedback%20VU%23516825">Chad Dougherty and Jeffrey Havrilla</a>
<p></p>
<!--#include virtual="/include/footer_nocopyright.html" -->
<p>Copyright 2003 Carnegie Mellon University.</p>
<p>Revision History
<pre>
Mar 19, 2003: Initial release
Mar 20, 2003: Updated vendor statement from Hitachi
Mar 24, 2003: Added vendor statement for Openwall GNU/*/Linux
Apr 01, 2003: Added vendor statement for Top Layer Networks, updated vendor statement for NetBSD
Apr 09, 2003: Added vendor statement for Nortel Networks, updated vendor statement for SGI
</pre>
</p>
|