Bug 1299442 (CVE-2015-8138)

Summary: CVE-2015-8138 ntp: missing check for zero originate timestamp
Product: [Other] Security Response Reporter: Martin Prpič <mprpic>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: carnil, mlichvar, sardella, security-response-team, slawomir
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
It was discovered that ntpd as a client did not correctly check the originate timestamp in received packets. A remote attacker could use this flaw to send a crafted packet to an ntpd client that would effectively disable synchronization with the server, or push arbitrary offset/delay measurements to modify the time on the client.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-25 13:51:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1299457, 1299458, 1299459, 1299460, 1300277    
Bug Blocks: 1297474    

Description Martin Prpič 2016-01-18 11:53:33 UTC
The TEST2 check of the originate timestamp in received packets, which requires the timestamp to match the value of the peer->aorg variable and which is supposed to be random to prevent spoofing attacks has been found to be faulty.

When ntpd receives a reply, it clears the peer->aorg variable to prevent a replay attack. This makes the value known to the attacker and a spoofed packet with a zero originate timestamp will pass the TEST2.

This means an off-path attacker can disrupt the synchronization with KoD packets, similar to CVE-2015-7704, or they can push arbitrary offset/delay measurements to the client, taking full control over the clock or cause ntpd to exit with an offset larger than the panic threshold.

Comment 6 Martin Prpič 2016-01-20 12:01:38 UTC
Created ntp tracking bugs for this issue:

Affects: fedora-all [bug 1300277]

Comment 7 Martin Prpič 2016-01-20 14:33:15 UTC
Statement:

This issue did not affect the versions of ntp as shipped with Red Hat Enterprise Linux 5 as they do not include the affected code, which was introduced in version 4.2.6 of NTP.

Comment 8 Martin Prpič 2016-01-21 14:52:55 UTC
The upstream fix for this issue is reported to be incomplete:

http://bugs.ntp.org/show_bug.cgi?id=2945#c7
http://lists.ntp.org/pipermail/hackers/2016-January/007406.html

Comment 9 Martin Prpič 2016-01-25 12:50:13 UTC
(In reply to Martin Prpic from comment #8)
> The upstream fix for this issue is reported to be incomplete:
> 
> http://bugs.ntp.org/show_bug.cgi?id=2945#c7
> http://lists.ntp.org/pipermail/hackers/2016-January/007406.html

Clarification: The patch proposed by upstream has been found not address the CVE-2015-8138 issue because it doesn't apply with a fix that was applied for a different issue. The problematic upstream merge is:

https://github.com/ntp-project/ntp/commit/5e16a06fa7dea9fcbfc1b2fc3cba0d2629171e80#diff-3b84eda3a15fdd99dcf77a2d85423721L1331

Red Hat has not included the patch to fix the previous issue and used a slightly modified version of the upstream patch to fix CVE-2015-8138.

Comment 10 errata-xmlrpc 2016-01-25 13:46:09 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2016:0063 https://rhn.redhat.com/errata/RHSA-2016-0063.html

Comment 11 Fedora Update System 2016-01-30 18:21:12 UTC
ntp-4.2.6p5-36.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2016-02-21 02:24:43 UTC
ntp-4.2.6p5-36.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.