Attachment 21354 Details for Bug 56975

2004-06-18_1.txt

2004-06-18_1.txt (text/plain), 8.19 KB, created by Thomas Biege on 2004-06-18 16:35:54 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2004-06-18 16:35:54 UTC

Size: 8.19 KB

patch

obsolete

>Hello,
>
>I want to take this chance to clarify what the vulnerabilities are here.
>
>We want to ensure that you understand that the only DHCP 3.0.1rc12 and
>3.0.1rc13 are exploitable. Prior versions of DHCP 3 contain the flawed
>code, but are not exploitable due to the fact that only the last hostname
>option provided by the client is logged. This is truncated to 255 bytes,
>and is not long enough to cause an overflow.
>
>Since the preconditions for both of these vulnerabilities is the same, and
>VU#317350 occurs in the code preceding VU#654390, there is no clear
>pathway to exploit VU#654390. Only systems that used the 'interim' patch
>provided this weekend to resolve VU317350 would have a clear exploit path
>to VU#654390. No systems should be doing this, and no distribution from
>ISC has done this.
>
>The flawed code for VU#654390 is present in DHCP 2.x, but these versions
>is no longer supported. We can see using the following format control of
>vsprintf to potentially form the stack address values. However, it appears
>that the mbuf buffer is declared "static" and therefore resides in the
>data section, not on the stack.
>
>This means that you may be able to corrupt some data or a pointer value
>stored in the data section. You could not overwrite a return address
>unless you overwrote a bit of the data section, heap and a few other bits
>and pieces of memory (architecture dependent) to get into the stack. Looks
>like it could be exploitable to cause a denial of service or corrupt other
>variables, but that execution of arbitrary code could be hard.
>
>To try and be clear, I am including a *rough draft* of our two
>vulnerability notes below. Please feel free to comment if there are any
>glaring mistakes. Note that these will change, and are drafts. They are
>not for further distribution.
>
>Thanks for all of your cooperation on this.
>
>Thank you,
>	Jason Rafail
>
>==============================
>Member of the Technical Staff
>CERT Coordination Center
>Software Engineering Institute
>Carnegie Mellon University
>4500 Fifth Avenue
>Pittsburgh, PA 15213
>1-412-268-7090
>==============================
>
>
>***DRAFT***
>[Please DO NOT DISTRIBUTE this text as it is still subject
>to change and is not intended for release (yet). Thanks.]
>
>VU#317350 - ISC DHCPD contains a stack buffer overflow vulnerability
>in handling log lines containing ASCII characters only
>
>CVE: CAN-2004-0460
>
>OVERVIEW
>
>The Internet Systems Consortium's (ISC) Dynamic Host Configuration
>Protocol (DHCP) 3 application contains a buffer overflow
>vulnerability. Exploitation of this vulnerability can cause a denial
>of service condition to the DHCP Daemon (DHCPD) and may permit a
>remote attacker to execute arbitrary code on the system with the
>privileges of the DHCPD process.
>
>DESCRIPTION
>
>As described in RFC 2131, "the Dynamic Host Configuration Protocol
>(DHCP) provides a framework for passing configuration information to
>hosts on a TCP/IP network."
>
>ISC DHCPD syslogs every DHCP packet in transactions along with
>several pieces of descriptive information. The client's DISCOVER and
>the resulting OFFER, REQUEST, and ACK are all logged as well as any
>NAKs.  In all of these messages, if the client supplied a hostname
>then it is also included in the logged line. If the client supplies
>multiple hostname options these options will be concatenated
>together. If the hostname and options contain only ASCII characters,
>then the string will pass non-ASCII character filters and be
>temporarily stored in 1024 byte fixed-length buffers on the stack.
>
>It is possible that if enough hostname options are supplied by the
>client, and other text is logged in the same line, then the static
>buffer will be overflown, writing over the stack. If non-ASCII or
>non-printable characters are supplied, then there are other checks
>and filters that will prevent this buffer overflow from occurring.
>
>Only ISC DHCP 3.0.1rc12 and ISC DHCP 3.0.1rc13 are  believed to be
>vulnerable for all operating systems and configurations. All versions
>of ISC DCHP 3, including all snapshots, betas, and release
>candidates, contain the flawed code. However,  since these versions
>discard of all but the last hostname option provided by the client,
>it is not believed that these versions are exploitable.
>
>IMPACT
>
>A remote attacker with the ability to send a crafted packet to the
>DHCPD listening port (typically port 67/UDP), they may be able to
>crash the ISC DHCP daemon, causing a denial of service. It may be
>possible to execute arbitrary code on the vulnerable server with the
>privileges of the DHCPD process (typically root).
>
>SOLUTION
>
>ISC has released DHCP 3.0.1rc14 which resolves this issue. Versions prior
>to ISC DHCP 3 are no longer supported. All users of ISC DHCP are
>encouraged to update to the latest version.
>
>CREDIT
>
>Thanks to Gregory Duchemin and Solar Designer for discovering,
>reporting and resolving this vulnerability. Thanks also to David
>Hankins of ISC for notifying us of this vulnerability and the
>technical information provided to create this document.
>
>This document was created by Jason A Rafail and based on the
>technical information provided by David Hankins of ISC.
>
>---------
>
>
>***DRAFT***
>[Please DO NOT DISTRIBUTE this text as it is still subject
>to change and is not intended for release (yet). Thanks.]
>
>VU#654390 - ISC DHCP contains C Includes that define  vsnprintf() to
>vsprintf() creating potential buffer overflow conditions
>
>CVE: CAN-2004-0461
>
>OVERVIEW
>
>The Internet Systems Consortium's (ISC) Dynamic Host Configuration
>Protocol (DHCP) 3 application contains several potential buffer
>overflow vulnerabilities. Exploitation of this vulnerability can
>cause a denial of service condition to the DHCP Daemon (DHCPD) and
>may permit a remote attacker to execute arbitrary code on the system
>with the privileges of the DHCPD process.
>
>DESCRIPTION
>
>ISC DHCP makes use of the vsnprintf() for writing various log file
>strings. For systems that do not support vsnprintf(), a C include file was
>created that defines the vsnprintf() function to vspringf() as such:
>
>  #define vsnprintf(buf, size, fmt, list) vsprintf (buf, fmt, list)
>
>vsprintf() is a function that does not check bounds therefore the
>size is discarded creating the potential for a buffer overflow when
>client provided data is supplied. Note that the vsnprintf()
>statements are defined after the vulnerable code that is discussed in
>VU#317350. This means that VU#317350 would be triggered prior to
>these potential buffer overflows, unless a client could specify
>content to a vsnprintf() statement not associated with logging. It is
>believed that there aren't any other vsnprintf() statements
>vulnerable to this type of exploitation. Note that this vulnerability
>was discovered and exploitable once VU#317350 was resolved.
>
>Only ISC DHCP 3.0.1rc12 and ISC DHCP 3.0.1rc13 are  believed to be
>vulnerable for all operating systems and configurations. Similar to
>VU#317350, all versions of ISC DCHP 3, including all snapshots,
>betas, and release candidates, contain the flawed code. However,
>since these versions discard of all but the last hostname option
>provided by the client, it is not believed that these versions are
>exploitable.
>
>IMPACT
>
>A remote attacker with the ability to send a crafted packet to the
>DHCPD listening port (typically port 67/UDP), they may be able to
>crash the ISC DHCP daemon, causing a denial of service. It may be
>possible to execute arbitrary code on the vulnerable server with the
>privileges of the DHCPD process (typically root).
>
>SOLUTION
>
>ISC has released DHCP 3.0.1rc14 which resolves this issue. For systems
>that do not support vsnprintf(), DHCP now implements it's own bounded
>function. DHCP will not compile and link if it does not believe that it is
>linking to a bounds checking function. While it has been verified that the
>#define statements are present in DHCP 2.x, it is not clear if this
>vulnerability could be exploited. Versions prior to ISC DHCP 3 are no
>longer supported. All users of ISC DHCP are encouraged to update to the
>latest version.
>
>CREDIT
>
>Thanks to Gregory Duchemin and Solar Designer for discovering,
>reporting and resolving this vulnerability. Thanks also to David
>Hankins of ISC for notifying us of this vulnerability and the
>technical information provided to create this document.
>
>This document was created by Jason A Rafail and based on the
>technical information provided by David Hankins of ISC.
>
>
>****

Actions: View

Attachments on bug 56975: 21118 | 21119 | 21120 | 21122 | 21123 | 21124 | 21126 | 21160 | 21196 | 21254 | 21301 | 21307 | 21354 | 21425 | 21634 | 21635 | 21636