Onderwerp: EEYE: XDR Integer Overflow

XDR Integer Overflow

Release Date:
March 19, 2003

Severity:
High (Remote Code Execution/Denial of Service)

Systems Affected:

Sun Microsystems Network Services Library (libnsl)
BSD-derived libraries with XDR/RPC routines (libc)
GNU C library with sunrpc (glibc)

Description:

XDR is a standard for the description and encoding of data which is used
heavily in RPC implementations. Several libraries exist that allow a
developer to incorporate XDR into his or her applications. Vulnerabilities
were discovered in these libraries during the testing of new Retina auditing
technologies developed by the eEye research department.

ADAM and EVE are two technologies developed by eEye to remotely and locally
audit applications for the existence of common vulnerabilities. During an
ADAM audit, an integer overflow was discovered in the SUN Microsystems XDR
library. By supplying specific integer values in length fields during an RPC
transaction, we were able to produce various overflow conditions in UNIX RPC
services.

Technical Description:

The xdrmem_getbytes() function in the XDR library provided by Sun
Microsystems contains an integer overflow. Depending on the location and use
of the vulnerable xdrmem_getbytes() routine, various conditions may be
presented that can permit an attacker to remotely exploit a service using
this vulnerable routine.

For the purpose of signature development and further security research a
sample session is included below that replicates an integer overflow in the
rpcbind shipped with various versions of the Solaris operating system.

char evil_rpc[] =

"\x23\x0D\xF6\xD2\x00\x00\x00\x00\x00\x00\x00\x02\ x00\x01\x86"
"\xA0\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\ x01\x00\x00"
"\x00\x20\x3D\xD2\xC9\x9F\x00\x00\x00\x09\x6C\x6F\ x63\x61\x6C"
"\x68\x6F\x73\x74\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x01\x86"
"\xa0\x00\x00\x00\x02\x00\x00\x00\x04"
"\xFF\xFF\xFF\xFF" // RPC argument length
"EEYECLIPSE2003";

Vendor Status:

Sun Microsystems was contacted on November 13, 2002 and CERT was contacted
shortly afterwards. Vendors believed to be vulnerable were contacted by CERT
during a grace period of several months. Due to some difficulties
communicating with vendors, after rescheduling several times a release date
was set for March 18, 2003.

eEye recommends obtaining the necessary patches or updates from vendors as
they become available after the release of this and the CERT advisory.

For a list of vendors and their responses, please review the CERT advisory
at: http://www.cert.org/advisories/CA-2003-10.html

You can find the latest copy of this advisory, along with other eEye
research at http://www.eeye.com/.

Credit:
Riley Hassell - Senior Research Associate

Greetings:
Liver destroyers of the world:
Barnes (DOW!), FX, and last but definitely not least, Heather and Jenn.

Copyright (c) 1998-2003 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail alert@eEye.com for
permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
info@eEye.com

Hi Marc,

I'm looking at the xdrmem_putbytes() from solaris 8 foundation source =
cd,
/cdrom/s8_foundation_src_en/osnet_volume/usr/src/lib/libnsl/rpc/xdr_mem.c=
line 168

static bool_t
xdrmem_getbytes(XDR *xdrs, caddr_t addr, int len)
{
int tmp;

trace2(TR_xdrmem_getbytes, 0, len);
if ((tmp =3D (xdrs->x_handy - len)) < 0) { <--- VULNERABILITY
syslog(LOG_WARNING,
.....=09
.....
return (FALSE);
}
xdrs->x_handy =3D tmp;
(void) memcpy(addr, xdrs->x_private, len); <--- VULNERABILITY
xdrs->x_private +=3D len;
trace1(TR_xdrmem_getbytes, 1);
return (TRUE);
}


It's clear that "len" is a signed integer and if "len" is negative this =
problem will=20
lead into an overflow since:
if ((tmp =3D (xdrs->x_handy - len)) < 0) { --> This check will be =
evaded!!

and we'll end up in:
memcpy(addr, xdrs->x_private, len);

BUT I must tell you; your argument about remote code execution does NOT =
seem to be correct=20
in Solaris/SPARC (especially in rpcbind) Unless you can prove me =
otherwise.=20

memcpy() will die with a negative len (even with 0x80000000) and Sun's =
memcpy() implementation=20
ain't ghetto like Free/Open/NetBSD so no cool tricks like GOBBLES' =
nose-job/scalp will work on it!

please enlighten us how come this is exploitable (Remote Code Execution =
in your words) ????


Regards,
Sinan=20



-----Original Message-----
From: Marc Maiffret [mailto:marc@eeye.com]
Sent: Wednesday, March 19, 2003 12:20 PM
To: BUGTRAQ
Subject: EEYE: XDR Integer Overflow


XDR Integer Overflow

Release Date:
March 19, 2003

Severity:
High (Remote Code Execution/Denial of Service)

Systems Affected:

Sun Microsystems Network Services Library (libnsl)
BSD-derived libraries with XDR/RPC routines (libc)
GNU C library with sunrpc (glibc)

Description:

XDR is a standard for the description and encoding of data which is used
heavily in RPC implementations. Several libraries exist that allow a
developer to incorporate XDR into his or her applications. =
Vulnerabilities
were discovered in these libraries during the testing of new Retina =
auditing
technologies developed by the eEye research department.

ADAM and EVE are two technologies developed by eEye to remotely and =
locally
audit applications for the existence of common vulnerabilities. During =
an
ADAM audit, an integer overflow was discovered in the SUN Microsystems =
XDR
library. By supplying specific integer values in length fields during an =
RPC
transaction, we were able to produce various overflow conditions in UNIX =
RPC
services.

Technical Description:

The xdrmem_getbytes() function in the XDR library provided by Sun
Microsystems contains an integer overflow. Depending on the location and =
use
of the vulnerable xdrmem_getbytes() routine, various conditions may be
presented that can permit an attacker to remotely exploit a service =
using
this vulnerable routine.

For the purpose of signature development and further security research a
sample session is included below that replicates an integer overflow in =
the
rpcbind shipped with various versions of the Solaris operating system.

char evil_rpc[] =3D

"\x23\x0D\xF6\xD2\x00\x00\x00\x00\x00\x00\x00\x02\ x00\x01\x86"
"\xA0\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\ x01\x00\x00"
"\x00\x20\x3D\xD2\xC9\x9F\x00\x00\x00\x09\x6C\x6F\ x63\x61\x6C"
"\x68\x6F\x73\x74\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x01\x86"
"\xa0\x00\x00\x00\x02\x00\x00\x00\x04"
"\xFF\xFF\xFF\xFF" // RPC argument length
"EEYECLIPSE2003";

Vendor Status:

Sun Microsystems was contacted on November 13, 2002 and CERT was =
contacted
shortly afterwards. Vendors believed to be vulnerable were contacted by =
CERT
during a grace period of several months. Due to some difficulties
communicating with vendors, after rescheduling several times a release =
date
was set for March 18, 2003.

eEye recommends obtaining the necessary patches or updates from vendors =
as
they become available after the release of this and the CERT advisory.

For a list of vendors and their responses, please review the CERT =
advisory
at: http://www.cert.org/advisories/CA-2003-10.html

You can find the latest copy of this advisory, along with other eEye
research at http://www.eeye.com/.

Credit:
Riley Hassell - Senior Research Associate

Greetings:
Liver destroyers of the world:
Barnes (DOW!), FX, and last but definitely not least, Heather and Jenn.

Copyright (c) 1998-2003 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express =
consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail alert@eEye.com =
for
permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There =
are
NO warranties with regard to this information. In no event shall the =
author
be liable for any damages whatsoever arising out of or in connection =
with
the use or spread of this information. Any use of this information is at =
the
user's own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
info@eEye.com