Bug 1297314 (CVE-2015-8605) - CVE-2015-8605 dhcp: UDP payload length not properly checked
Summary: CVE-2015-8605 dhcp: UDP payload length not properly checked
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2015-8605
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1298077
Blocks: 1297315
TreeView+ depends on / blocked
 
Reported: 2016-01-11 07:51 UTC by Martin Prpič
Modified: 2019-09-29 13:41 UTC (History)
4 users (show)

Fixed In Version: dhcp 4.1-ESV-R13, dhcp 4.3.3-P1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-13 14:36:42 UTC


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

Description Martin Prpič 2016-01-11 07:51:04 UTC
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.

Comment 1 Martin Prpič 2016-01-11 07:55:26 UTC
Created attachment 1113518 [details]
rt41267-4.1-ESV-R12-P1.patch

Comment 2 Martin Prpič 2016-01-11 07:55:29 UTC
Created attachment 1113519 [details]
rt41267-4.3.3-P1.patch

Comment 3 Martin Prpič 2016-01-11 07:55:32 UTC
Created attachment 1113520 [details]
rt41267-general.patch

Comment 5 Tomas Hoger 2016-01-12 10:11:54 UTC
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 08:15:23 UTC
Public now via upstream advisory.

External References:

https://kb.isc.org/article/AA-01334

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

Affects: fedora-all [bug 1298077]

Comment 9 Tomas Hoger 2016-01-13 14:36:42 UTC
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 13:21:12 UTC
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 15:21:20 UTC
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

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