Bug 1297314 - (CVE-2015-8605) CVE-2015-8605 dhcp: UDP payload length not properly checked
CVE-2015-8605 dhcp: UDP payload length not properly checked
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 1298077
Blocks: 1297315
  Show dependency treegraph
Reported: 2016-01-11 02:51 EST by Martin Prpič
Modified: 2016-01-24 17:50 EST (History)
4 users (show)

See Also:
Fixed In Version: dhcp 4.1-ESV-R13, dhcp 4.3.3-P1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-13 09:36:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
rt41267-4.1-ESV-R12-P1.patch (3.84 KB, text/plain)
2016-01-11 02:55 EST, Martin Prpič
no flags Details
rt41267-4.3.3-P1.patch (3.83 KB, text/plain)
2016-01-11 02:55 EST, Martin Prpič
no flags Details
rt41267-general.patch (3.34 KB, text/plain)
2016-01-11 02:55 EST, Martin Prpič
no flags Details

  None (edit)
Description Martin Prpič 2016-01-11 02:51:04 EST
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.


Red Hat would like to thank ISC for reporting this issue. Upstream acknowledges Sebastian Poehn of Sophos as the original reporter.
Comment 1 Martin Prpič 2016-01-11 02:55:26 EST
Created attachment 1113518 [details]
Comment 2 Martin Prpič 2016-01-11 02:55:29 EST
Created attachment 1113519 [details]
Comment 3 Martin Prpič 2016-01-11 02:55:32 EST
Created attachment 1113520 [details]
Comment 5 Tomas Hoger 2016-01-12 05:11:54 EST
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.
Comment 7 Tomas Hoger 2016-01-13 03:15:23 EST
Public now via upstream advisory.

External References:

Comment 8 Tomas Hoger 2016-01-13 03:16:08 EST
Created dhcp tracking bugs for this issue:

Affects: fedora-all [bug 1298077]
Comment 9 Tomas Hoger 2016-01-13 09:36:42 EST
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.
Comment 10 Fedora Update System 2016-01-16 08:21:12 EST
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.
Comment 11 Tomas Hoger 2016-01-18 10:21:20 EST

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
Comment 12 Fedora Update System 2016-01-24 17:50:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.