The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Stack-Based Buffer Overflow Vulnerability in OpenBSD's DHCP Server
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
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>
http://www.openbsd.org/errata42.html
* OpenBSD 4.1: <http://www.openbsd.org/errata41.html>
http://www.openbsd.org/errata41.html
* OpenBSD 4.0: <http://www.openbsd.org/errata40.html>
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> http://www.iss.net/threats/275.html
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0063>
CVE-2007-0063
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@coresecurity.com>
Core Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1962>
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1962
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
