|
|
|
|
| |
Credit:
The information has been provided by Core Security Technologies Advisories.
The original article can be found at: http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1962
|
| |
Vulnerable Systems:
* OpenBSD version 4.0
* OpenBSD version 4.1
* OpenBSD version 4.2
Immune Systems:
* OpenBSD current as of October 9th, 2007 3:17 GMT
* The DHCP server from the Internet Software Consortium (ISC)
Solution/Vendor Information/Workaround:
The OpenBSD team has fixed the bug in all current versions of the vulnerable packages. The fix is committed to the source code tree and source code patches are available from OpenBSD s errata pages:
* OpenBSD 4.2: http://www.openbsd.org/errata42.html
* OpenBSD 4.1: http://www.openbsd.org/errata41.html
* OpenBSD 4.0: http://www.openbsd.org/errata40.html
Updated builds of the vulnerable OpenBSD versions have the problem fixed.
Technical Description / Proof of Concept Code:
DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. The term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server.
The Dynamic Host Configuration Protocol (DHCP) specification [1] indicates the requirements that a given DHCP implementation must fulfill. In summary, DHCP is designed to supply DHCP clients with the configuration parameters defined in the Host Requirements RFCs. After obtaining parameters via DHCP, a DHCP client should be able to exchange packets with any other host in the Internet. The TCP/IP stack parameters supplied by DHCP are listed in Appendix A of the corresponding RFC. Not all of these parameters are required for a newly initialized client. A client and server may negotiate for the transmission of only those parameters required by the client or specific to a particular subnet. DHCP allows but does not require the configuration of client parameters not directly related to the IP protocol. DHCP also does not address registration of newly configured clients with the Domain Name System (DNS).
The DCHP message definition includes a variable length field called options which are in turn indication of an additional variable length payload to the base DHCP message. The entire list of official DHCP options, also known as vendor extensions in BOOTP terminology, is provided in a companion RFC document to the protocol specification [3]. One such option is the maximum DCHP message size option (MMS). The protocol specification indicates that The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages .
OpenBSD s dhcpd fails to properly validate the value provided in the maximum message size option by the DHCP client and thus allowing an attacker to specify MMS values that result in a integer underflow followed by a call to memcpy(3) with a negative third argument which in turns overwrites arbitrary portions of process memory.
The problem is found in function responsible of processing DHCP option received from the client:
In src/usr.sbin/dhcpd/options.c
int
cons_options(struct packet *inpacket, struct dhcp_packet *outpacket,
int mms, struct tree_cache **options,
int overload, /* Overload flags that may be set. */
int terminate, int bootpp, u_int8_t *prl, int prl_len)
{
unsigned char priority_list[300];
int priority_len;
unsigned char buffer[4096]; /* Really big buffer... */
int main_buffer_size;
int mainbufix, bufix;
int option_size;
int length;
DHCP_FIXED_LEN is defined in dhcp.h
if (!mms &&
inpacket &&
inpacket->options[DHO_DHCP_MAX_MESSAGE_SIZE].data &&
(inpacket->options[DHO_DHCP_MAX_MESSAGE_SIZE].len >=
sizeof(u_int16_t)))
mms = getUShort(
inpacket->options[DHO_DHCP_MAX_MESSAGE_SIZE].data);
if (mms)
main_buffer_size = mms - DHCP_FIXED_LEN;
else if (bootpp)
main_buffer_size = 64;
else
main_buffer_size = 576 - DHCP_FIXED_LEN;
if (main_buffer_size > sizeof(buffer))
main_buffer_size = sizeof(buffer);
main_buffer_size is signed and controlled by the attacker. As long as main_buffer_size is a small positive integer (<= 4096) execution flow will continue normally
/* Copy the options into the big buffer... */
option_size = store_options(
buffer,
(main_buffer_size - 7 + ((overload & 1) ? DHCP_FILE_LEN : 0)+
((overload & 2) ? DHCP_SNAME_LEN : 0)),
options, priority_list, priority_len, main_buffer_size,
(main_buffer_size + ((overload & 1) ? DHCP_FILE_LEN : 0)),
terminate);
/* Put the cookie up front... */
memcpy(outpacket->options, DHCP_OPTIONS_COOKIE, 4);
mainbufix = 4;
Here, a small positive value of main_buffer_size (<= 7) will make store_options exit quickly and execution flow continues. Specifically, if the Maximum Segment Size value (mms) in the client packet satisfies the condition (DHCP_FIXED_LEN < mms < DHCP_FIXED_LEN+4) then main_buffer_size will be positive but less than 4.
if (option_size <= main_buffer_size - mainbufix) {
memcpy(&outpacket->options[mainbufix],
buffer, option_size);
mainbufix += option_size;
if (mainbufix < main_buffer_size)
outpacket->options[mainbufix++] = DHO_END;
length = DHCP_FIXED_NON_UDP + mainbufix;
} else {
outpacket->options[mainbufix++] = DHO_DHCP_OPTION_OVERLOAD;
outpacket->options[mainbufix++] = 1;
if (option_size >
main_buffer_size - mainbufix + DHCP_FILE_LEN)
outpacket->options[mainbufix++] = 3;
else
outpacket->options[mainbufix++] = 1;
memcpy(&outpacket->options[mainbufix],
buffer, main_buffer_size - mainbufix);
Triggering a memcpy(3) call with a negative third argument that results in large portions of the process memory been overwritten.
Report Timeline:
2007-10-03: Initial notification sent by CoreLabs to OpenBSD
2007-10-04: Notification acknowledged by OpenBSD
2007-10-04: Technical details provided to OpenBSD
2007-10-05: Patch with a proposed fix from OpenBSD provided for comments/confirmation
2007-10-05: Confirmation from CoreLabs that the patch fixed the problem.
2007-10-09: Email from OpenBSD indicating that the fix has been committed to the OpenBSD source tree and announced as a security fix in OpenBSD's errata page.
2007-10-10: Publication of CoreLabs advisory CORE-2007-0928
Additional Information/ Resources:
[1] Dynamic Host Configuration Protocol (DHCP)
- Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997.
- Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.
- Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, Bucknell University, October 1993.
[2] Bootstrap Protocol (BOOTP)
- Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,Stanford and SUN Microsystems, September 1985.
- Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993.
[3] VMWare DHCP Server Remote Code Execution Vulnerabilities:
- Neel Mehta and Ryan Smith of IBM X-Force, http://www.iss.net/threats/275.html
CVE Information:
CVE-2007-0063
|
|
|
|
|
