A flaw in DHCP was reported by ISC: A badly formed packet with an invalid IPv4 UDP length field can cause a DHCP server, client, or relay program to terminate abnormally. Nearly all IPv4 DHCP clients and relays, and most IPv4 DHCP servers are potentially affected. Acknowledgements: Red Hat would like to thank ISC for reporting this issue. Upstream acknowledges Sebastian Poehn of Sophos as the original reporter.
Created attachment 1113518 [details] rt41267-4.1-ESV-R12-P1.patch
Created attachment 1113519 [details] rt41267-4.3.3-P1.patch
Created attachment 1113520 [details] rt41267-general.patch
This problem is in the decode_udp_ip_header() function. The function receives a buffer pointer buf and its length in buflen. It then computes endbuf pointing to after the end of the buffer as: endbuf = buf + bufix + buflen; (bufix is index where buffer parsing should start. If bufix is non-0, function caller is responsible for ensuring that buflen does not indicate full buffer size, but full size minus bufix. We will ignore bufix in the following discussion as it's not relevant for this issue.) Subsequently, the function does boundary checks using endbuf using code that can be simplified to: if (buf + offset > endbuf) return error; The buf + offset addition may overflow / wraparound under certain circumstances, leading to the bypass of the boundary checks, resulting in out of bounds read which can cause dhcp do crash as reported in the upstream advisory. The offset is attacker controlled, as it contains values read from the packet being parsed. However, its maximum value is very limited - it can only be around 64k (2^16), derived from the maximum UDP packet length. Therefore for wraparound to happen, buf needs to be placed close to the address space limit. Its end - indicated by endbuf - should be above ~ (2^32 - 2^16) or ~ (2^64 - 2^16) depending on the architecture. As buf is stack based, that is theoretically possible. However, part of the address space is normally not accessible to user space application and is reserved for kernel. E.g. on i386, there's 3:1 memory split, leaving the topmost 1gb of memory reserved for kernel. Similarly, on x86_64 and other architectures, stack memory is placed far from the end of the address space. In those cases, wraparound can not happen and hence they are not affected by this problem. This may be an issue when running 32bit application on 64bit system as memory reserved for kernel is above 2^32. In such case, stack memory can be placed close enough to the end of address space to possibly allow triggering of this problem. ASLR (address space layout randomization) is likely to cause only some invocations of the program to be affected and other having stack memory end far enough from the address space end. As Red Hat does not provide 32bit dhcp packages builds for 64bit versions of Red Hat Enterprise Linux 6 and 7, this is not relevant for the Red Hat provided and supported versions of dhcp.
Public now via upstream advisory. External References: https://kb.isc.org/article/AA-01334
Created dhcp tracking bugs for this issue: Affects: fedora-all [bug 1298077]
Given the lack of practical impact (see comment 5 above), this is not currently planned to be addressed in future Red Hat Enterprise Linux dhcp packages updates.
dhcp-4.3.3-8.P1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Statement: This issue is not planned to be addressed in the dhcp packages as shipped with Red Hat Enterprise Linux 5, 6, or 7, as the problem can not be triggered with those packages. For further technical details, refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1297314#c5
dhcp-4.3.2-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.