[28724] in bugtraq
Re: DoS against DHCP infrastructure with isc dhcrelay
daemon@ATHENA.MIT.EDU (Thomas Lotterer)
Mon Feb 3 13:11:57 2003
Date: Mon, 3 Feb 2003 10:54:09 +0100
From: Thomas Lotterer <thl@dev.de.cw.com>
To: bugtraq@securityfocus.com
Message-ID: <20030203095409.GA50293@dev.de.cw.com>
Reply-To: thl@dev.de.cw.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I examined this issue to eventually create a security patch but i failed
when diving deeper into the material. Shortly said, i'm not lucky with
the patch and here are my considerations.
IMHO, when a relay forwards a BOOTREQUEST it must not use the MAC
broadcast as a destination - unless the system administrator configured
the IP local broadcast address as the destination he likes the requests
to be forwarded to. Filling the packet with a MAC broadcast destination
is exactly what the Linux packet filter code in ISC dhcpd/relay
currently does. This is the ultimate reason for the broadcast storm to
appear and this has to be fixed. The current patch just defeats the
symptom and is not a solution for this specific problem.
However, the patch really addresses another problem, a violation of
RFC1542 currently present in the code by not checking the "hops" field.
ftp://ftp.rfc-editor.org/in-notes/rfc1542.txt
4.1.1 BOOTREQUEST Messages
The relay agent MUST silently discard BOOTREQUEST messages whose
'hops' field exceeds the value 16. A configuration option SHOULD be
provided to set this threshold to a smaller value if desired by the
network manager. The default setting for a configurable threshold
SHOULD be 4.
I hope ISC or a third party will provide a proper patch soon. Operating
System vendors alread started to give out security advisories based on
this "symptom defender patch", i.e.
http://www.debian.org/security/2003/dsa-245
--
Thomas.Lotterer@cw.com
Development Team, Cable & Wireless IS Operations Northern Europe
