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.Lotterercw.com
Development Team, Cable & Wireless IS Operations Northern Europe

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]