linux-kernel - klibc ipconfig misbehavior in a network with DHCP snooping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 6 Dec 2007 14:50:14 -0500
From:	"Ken Simon" <ninkendo@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: klibc ipconfig misbehavior in a network with DHCP snooping

(H. Peter Anvin was CC'd in the original message, but the lkml mailer
rejected it because of an html subpart... sorry)

Bear with me, because I'm no DHCP expert, nor any sort of kernel/networking
expert in any sense. (This is actually my first post to the lkml or to any
kernel developer.)

I found a problem with klibc's "ipconfig" program, or at least, behavior
that breaks DHCP on my thin clients (LTSP 5.0). It has to do with setting
the giaddr field on dhcp_send in dhcp_proto.c, line 164.

[snip]
static int dhcp_send(struct netdev *dev, struct iovec *vec)
{
 struct bootp_hdr bootp;

 memset(&bootp, 0, sizeof(struct bootp_hdr));

 bootp.op = BOOTP_REQUEST;
 bootp.htype = dev->hwtype;
 bootp.hlen = dev->hwlen;
 bootp.xid = dev->bootp.xid;
 bootp.ciaddr = dev->ip_addr;
 bootp.giaddr = dev-> bootp.gateway; //<-- HERE
 bootp.secs = htons(time(NULL) - dev->open_time);
 memcpy(bootp.chaddr, dev->hwaddr, 16);
...
[/snip]

I'm not sure why the giaddr field should be set on a DHCP request, but it
causes a Cisco relay agent with DHCP snooping turned on to drop the
request. I know ipconfig has options to both manually set a gateway and
configure the interface via dhcp, but IMO it shouldn't be sending it as part
of the DHCPREQUEST packet.

When I went to Cisco about the issue, this is exactly what they explained:

[QUOTE]
This looks like the thin client is not following the standards for DHCP
relay information specified in RFC3046. This RFC states the following:

A DHCP relay agent may receive a client DHCP packet forwarded from a
 BOOTP/DHCP relay agent closer to the client. Such a packet will have
 giaddr as non-zero, and may or may not already have a DHCP Relay
 Agent option in it.

 ***Relay agents configured to add a Relay Agent option which receive a
 client DHCP packet with a nonzero giaddr SHALL discard the packet if
 the giaddr spoofs a giaddr address implemented by the local agent
 itself.***

 Otherwise, the relay agent SHALL forward any received DHCP packet
 with a valid non-zero giaddr WITHOUT adding any relay agent options.
 Per RFC 2131 <
;http://www.faqs.org/rfcs /rfc2131.html>, it shall also NOT modify the
giaddr value.

The part that I highlighted specifies that a relay agent should discard
the packet if the giaddr address is spoofs a giaddr address implemented
by the relay agent. This appears to be the case due to the fact that
the DHCP request packet has a giaddr address of the relay agent
specified in the DHCP offer.
[/QUOTE]

Now, when I changed the noted line above to:

bootp.giaddr = INADDR_ANY;

then recompile, and rebuild my initrd, the relay agent forwards the DHCP
request just fine.

Can anyone comment on why giaddr needs to be set on a DHCP request? Is this
a simple bug, or is there something deeper going on here?

-- 
Ken
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/