Subnet mask improperly validated
name: Bug report
about: Create a report to help us improve
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to security-office(at)isc(dot)org. If you really need to report it here, please set the confidential field to true.
Describe the bug Subnet masks are not completely validated for proper formatting. Thus the system accepts an IP address such as 10.254.130.65 as a subnet mask in certain cases. This causes several issues as hosts from the "wrong" subnet will be percieved to belong to this subnet and overall wreak havoc in the network
To Reproduce Steps to reproduce the behavior:
create the following subnet:
subnet 10.254.130.64 netmask 10.254.130.65 {
option subnet-mask 10.254.130.65;
option domain-name-servers 135.227.24.250, 152.148.152.45, 152.148.152.38;
option interface-mtu 1600;
}
and then this host:
host CLIENT1 { hardware ethernet AA:00:CC:11:EE:22; fixed-address 10.254.170.192; }
Starting dhcpd will not complain at all. Accepting the configuration.
When client1 sends a DHCP discover, it will be offered the 10.254.170.192 address but the subnet mask of 10.254.130.65
shows the subnet mask being sent to the client
My config is quite scaled (but I can provide the complete config file if needed).
So there are two issues:
- Invalid subnet masks are accepted
- These invalid subnet masks create issues where hosts are mapped to the wrong subnet and get options from those subnets
Expected behavior
- Subnet masks should be validated to be "contiguous ones" when seen in binary
- host-to-subnet validation seems to have to be revisited
Environment:
- ISC DHCP version: which release? if it's compiled from git, which revision. Use
dhcpd --version
to find out.
[root@wfnupxe1 ~]# dhcpd --version
isc-dhcpd-4.2.5
[root@wfnupxe1 ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
Installed from RPM
Additional Information I can provide the config files separately but due to the size, its difficult to anonymise.. Also, they are quite large but I think this small sample should be enough to reproduce.
I have not checked the code for the DHCP client to see if it accepts the non-standard mask, but at least both the intel PXE dhcp agent as well as the ATEN IPMI DHCP seem to have accepted the subnet mask and thus result in broken connectivity.
Additional context Add any other context about the feature request here.
Contacting you How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
contact me at garci66@gmail.com or diego.garcia_del_rio@nokia.com