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 (at) cw (dot) com [email concealed]
Development Team, Cable & Wireless IS Operations Northern Europe
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 (at) cw (dot) com [email concealed]
Development Team, Cable & Wireless IS Operations Northern Europe
[ reply ]