DHCP-assigned IP, broadcast, and subnet.
The nl_foreach_nlmsg() gains a seq parameter that when set to non-0 will
cause nl_foreach_nlmsg() to ignore any nlmsg that has a seq number
that does not match the caller-supplied seq argument.
zeroing the send buffer. It's less finicky than special-casing the
ip4 command to use strnkcpy instead of strnkcat.
At the same time, centralize the command print code on the send side.
It can just live in pipewrite() rather than the callers.
Also, background() and setup_signals_ndhc() are moved from sys.c to ndhc.c.
background() also no longer attempts to re-configure signals; signals are
always set up on initial ndhc initialization.
subprocesses. ndhc-ifch can then use the stored interface index when
setting the interface ip/subnet/broadcast via netlink instead of having
to use ioctl to re-fetch the interface index.
not be longer than the total option length.
A lying field sent by the DHCP server could possibly read data past the end of
the options field in the dhcp packet into the returned options data buffer.
It's hard to see how this could lead to an exploit because the total length
of data read into the options data buffer was indeed properly length-checked
so that it is impossible to overrun the destination buffer. Thus, this
problem is at worst a read-too-far with no ability to write to unexpected
locations.
The worst possible outcome is a program crash/DoS, depending on memory
layout. Information disclosure is not an issue because this is on the
path where the consumer of the destination buffer is ndhc, not the remote
DHCP server.
signed value where values <0 are errors and >= 0 are lengths. Convert
to an unsigned length value if the return is a length.
Further, there is a real bug if get_(raw|cooked)_packet() returns
an error. handle_packet() should return rather than continuing to validate
the packet. The packet validation will almost surely fail, and the
negative values of len are constrained to [-1,-2], and the values are
determined by errors that are hard to control, so it is extremely
unlikely that there are any security issues with this bug.
The fix is trivial; the obviously-missing return statement bails out when
there's a problem fetching a packet and ndhc immediately goes back to
listening for another packet.
