Bekijk Volledige Versie : DoS against DHCP infrastructure with isc dhcrelay

Florian Lohoff
21/01/03, 09:46
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

i discovered a bug in the dhcrelay causing it to send a continuing packet
storm towards the configured dhcp server(s) in case of a malicious bootp
packet. I have seen this on Linux Kernel 2.2 and 2.4 with the isc dhcp
3.0rc9 relay (I havent tested rc10 but the diff shows no obvious fix).

In case the dhcp-relay receives a bootp request it will forward it through
LPF to the dhcp server using the broadcast mac address ff:ff:ff:ff:ff:ff
which causes the LPF to reflect the packet back into the socket. To
prevent loops the dhcrelay checks the giaddr to be itself. In case it
receives a packet with a set giaddr it will not alter this address and
forward the packet. On reception of that packet the giaddr is not itself
so it will continue forwarding.

My fix was to limit the hopcount which is counted up until 255 and
continues to loop. My impression of a hop count is that it should get
dropped when reached. There are possible other ways to prevent looping
(Dropping our mac address on reception, forwarding layer 2 unicast to
the default gw).

With this workaround you can steer the amplification of the bootp requests =
for every malicious bootp packet hopcount relays happen.

--- dhcp3-3.0+3.0.1rc9/relay/dhcrelay.c Sat Apr 27 05:34:20 2002
+++ dhcp3-3.0+3.0.1rc9.flo/relay/dhcrelay.c Wed Oct 16 14:29:04 2002
@@ -88,6 +88,7 @@
did not match any known circuit ID. */
int missing_circuit_id =3D 0; /* Circuit ID option in matching RAI option
was missing. */
+int max_hop_count =3D 255; /* Maximum hop count */
/* Maximum size of a packet with agent options added. */
int dhcp_max_agent_option_packet_length =3D 576;
@@ -182,6 +183,15 @@
quiet_interface_discovery =3D 1;
} else if (!strcmp (argv [i], "-a")) {
add_agent_options =3D 1;
+ } else if (!strcmp (argv [i], "-c")) {
+ int hcount;=09
+ if (++i =3D=3D argc)
+ usage ();
+ hcount =3D atoi(argv[i]);=09
+ if (hcount <=3D255)
+ max_hop_count=3Dhcount;
+ else
+ usage ();
} else if (!strcmp (argv [i], "-A")) {
if (++i =3D=3D argc)
usage ();
@@ -425,6 +435,8 @@
packet -> giaddr =3D ip -> primary_address;
if (packet -> hops !=3D 255)
packet -> hops =3D packet -> hops + 1;
+ if (packet -> hops >=3D max_hop_count)
+ return;
/* Otherwise, it's a BOOTREQUEST, so forward it to all the
servers. */

This problem has been reported to the dhcp-server list on 20021016

Date: Wed, 16 Oct 2002 19:29:21 +0200
From: Florian Lohoff <flo@rfc822.org>
To: dhcp-server@isc.org
Subject: [PATCH] dhcp-relay patch to limit hop count

and to dhcp-bugs on 20021211

Date: Wed, 11 Dec 2002 22:48:38 +0100
From: Florian Lohoff <flo@rfc822.org>
To: dhcp-bugs@isc.org
Subject: [PATCH] bootp request loop in dhcp-relay

No answers so far ...

Florian Lohoff flo@rfc822.org +49-5201-669912
Heisenberg may have been here.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org



Thomas Lotterer
03/02/03, 19:10
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.

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.

Development Team, Cable & Wireless IS Operations Northern Europe