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)

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:

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.