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.
but simply return a bool indicating whether the destination received
a truncated copy of the source (true if truncation occurs else false).
The change in return value semantics allows these functions to stop
scanning the source string early when truncation occurs, stopping the
program from scanning a possibly arbitrary-length source string.
I rarely use these return values in my own programs, so it won't be
very hard to bulk convert with no risk of regressions.
Further, the different namespace allows me to not depend on the presence
or absence of strlc(py|at) in the standard libraries.
DHCP messages anyway, since the IPv4 min MTU is 576 bytes and the max DHCP
message size + IP and UDP headers is less than that, but it is still worth
checking.
