Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    Florian Lohoff
    DoS against DHCP infrastructure with isc dhcrelay
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    DoS against DHCP infrastructure with isc dhcrelay

    --dDRMvlgZJXvWKvBx
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable


    Hi,
    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 =
    as
    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 */
    =20
    /* 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;
    =20
    /* 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 ...

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

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

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

    iD8DBQE+JXQ2Uaz2rXW+gJcRAuFnAKDM/eWIEegfIgEHsdYGTMNh9aH3pgCfeYQG
    Z9zQE2MlEoCIXojqnw/kFl8=
    =uDcH
    -----END PGP SIGNATURE-----

    --dDRMvlgZJXvWKvBx--

  2. #2
    Thomas Lotterer
    DoS against DHCP infrastructure with isc dhcrelay
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: DoS against DHCP infrastructure with isc dhcrelay

    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

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics