Stack-based buffer overflow vulnerability in OpenBSD's DHCP server

Stack-based buffer overflow vulnerability in OpenBSD's DHCP server

Stack-based buffer overflow vulnerability in OpenBSD™s DHCP server


Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/


Advisory Information
Title: Stack-based buffer overflow vulnerability in OpenBSD’s DHCP server
Advisory ID:  CORE-2007-0928
Date published: 2007-10-10
Date of last update: 2007-10-11
Vendors contacted: OpenBSD
Release mode: Coordinated release


Vulnerability Information
Class: Input validation error
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID:  25984
CVE Name: CVE-2007-0063

Vulnerability Description
OpenBSD’s DHCP server, dhcpd, implements the Dynamic Host Configuration Protocol (DHCP) [1] and the Internet Bootstrap Protocol (BOOTP) [2].  DHCP allows hosts on a TCP/IP network to request and be assigned IP addresses, and also to discover information about the network to which they are attached.  BOOTP provides similar functionality, with certain restrictions. The DHCP protocol allows a host which is unknown to the network administrator to be automatically assigned a new IP address out of a pool of IP addresses for its network.  In order for this to work, the network administrator allocates address pools in each subnet and enters them into the dhcpd’s configuration file. OpenBSD’s implementation of the DHCP server is based on an early version of ISC’s dhcpd that the OpenBSD project further developed to incorporate additional security features such as privilege separation and the ability to synchronize provisioning of IP addresses to clients with updates to PF firewall filtering rules to effectively implement egress and ingress filtering based on live client IP addresses on the network served by dhcpd.

A vulnerability found in OpenBSD’s dhcpd allows attackers on the local network to remotely cause the DHCP server to corrupt its process memory and crash; or continue functioning erratically thus denying service to all DHCP clients on the network and, if PF updates are in use, potentially affecting egress/ingress filtering as well.

Although after an initial cursory analysis the vulnerability does not seem usable for anything other than a Denial of Service attack against the server to terminate the dhcpd process,  the possibility of using it to execute arbitrary code on vulnerable systems was not investigated in-depth and should not be disregarded. In general, exploitation of stack-based buffer overflow bugs in OpenBSD for remote code execution is prevented or at least mitigated by various security features of the operating system but the effectiveness of such mechanisms should be analyzed on a case by case basis taking into account the details of the specific vulnerable code at hand. Such detailed in-depth analysis was not performed in this case.

The vulnerability was found while investigating reports of multiple vulnerabilities in the DHCP server implementation of VMware products. Detailed inspection revealed that VMware’s DHCP server is based on OpenBSD’s dhcpd, which in turn led to source code inspection to identify the vulnerability and to development of a proof of concept exploit to confirm its existence on live systems in test lab. Since the original security advisory [3] disclosing multiple bugs in VMware’s DHCP server did not provide enough technical details to uniquely identify this bug among the three bugs disclosed in the report, Core has arbitrarily picked one CVE name to identify it.


Vulnerable packages
OpenBSD 4.0
OpenBSD 4.1
OpenBSD 4.2

 

Non-vulnerable packages
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:


Updated builds of the vulnerable OpenBSD versions have the problem fixed.

 

Credits
This vulnerability was discovered by Nahuel Riva and Gerardo Richarte from the CORE IMPACT Exploit Writers Team (EWT).

The VMware vulnerabilities that originally triggered research and subsequent discovery of the buffer overflow vulnerability in OpenBSD’s dhcpd were found by Neel Mehta and Ryan Smith from IBM X-Force [3]. Since the advisory from IBM X-Force lists 3 apparently distinct bugs (using 3 different CVE names) but provides no technical details to uniquely identify each one of them we’ve decided to roll a dice and picked CVE-2007-0063 as the one to identify the bug reported in this advisory. gracias.zip.

 

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. DCHP communication s on a local network use UDP ports 67 and 68.

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

 

References
[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

About Corelabs
CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies.
We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs/

About Core Security Technologies
Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.

 

DISCLAIMER
The contents of this advisory are copyright (c) 2007 CORE Security Technologies and (c) 2007 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

PGP/GPG KEYS
This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at /legacy/files/attachments/core_security_advisories.asc