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.
ndhc will fork off an ifchd child that it will communicate with via
pipes rather than by connecting to a SO_PEERCRED AF_UNIX socket.
The advantages include:
1. Simpler configuration. Much easier for users and packagers to set up.
2. Drastically less complex code for the ifch functionality. More code
is removed than added, and the result is a lot less complex.
3. Potentially better security. The ifch can only service the parent
ndhc process, and it is restricted to issuing modifications to
the single interface that ndhc manages.
4. Less memory used on systems that allow overcommit.
The downsides:
1. Possibly more memory used on systems that run multiple ndhcs and use
strict commit limits.
At the same time, use netlink rather than ioctls so that the
interface ip, subnet, and broadcast address can be set simultaneously.
This change reduces the netlink notification spam greatly.
The current code builds but isn't yet complete. Subsequent commits will
flesh things out and polish out some remaining issues.
to set the interface ip, subnet, and broadcast address simultaneously.
The advantage of this approach is that a single netlink notification
will be sent rather than multiple messages as the ip, subnet,
and broadcast address are set one at a time.
Currently this function is not used, as it will require a wire format
change that will be introduced in a subsequent commit.
