Bug 649612 (CVE-2018-7170, CVE-2018-7182, CVE-2018-7183, CVE-2018-7184, CVE-2018-7185) – <net-misc/ntp-4.2.8_p11: multiple vulnerabilities (CVE-2018-{7170,7182,7183,7184,7185})

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Agostino Sarubbo 2018-03-05 09:14:41 UTC]

From https://bugzilla.redhat.com/show_bug.cgi?id=1550223:

ntpq is a monitoring and control program for ntpd. decodearr() is an internal function of ntpq that is used to -- wait for it -- decode an array in a response string when formatted data is being 
displayed. This is a problem in affected versions of ntpq if a maliciously-altered ntpd returns an array result that will trip this bug, or if a bad actor is able to read an ntpq request on its way to a 
remote ntpd server and forge and send a response before the remote ntpd sends its response. It's potentially possible that the malicious data could become injectable/executable code.

References:

http://support.ntp.org/bin/view/Main/NtpBug3414


From https://bugzilla.redhat.com/show_bug.cgi?id=1550220:

The NTP Protocol allows for both non-authenticated and authenticated associations, in client/server, symmetric (peer), and several broadcast modes. In addition to the basic NTP operational modes, 
symmetric mode and broadcast servers can support an interleaved mode of operation. In ntp-4.2.8p4 a bug was inadvertently introduced into the protocol engine that allows a non-authenticated zero-origin 
(reset) packet to reset an authenticated interleaved peer association. If an attacker can send a packet with a zero-origin timestamp and the source IP address of the "other side" of an interleaved 
association, the 'victim' ntpd will reset its association. The attacker must continue sending these packets in order to maintain the disruption of the association. In ntp-4.0.0 thru ntp-4.2.8p6, 
interleave mode could be entered dynamically. As of ntp-4.2.8p7, interleaved mode must be explicitly configured/enabled.

References:

http://support.ntp.org/bin/view/Main/NtpBug3454


From https://bugzilla.redhat.com/show_bug.cgi?id=1550218:

The fix for NtpBug2952 was incomplete, and while it fixed one problem it created another. Specifically, it drops bad packets before updating the "received" timestamp. This means a third-party can inject 
a packet with a zero-origin timestamp, meaning the sender wants to reset the association, and the transmit timestamp in this bogus packet will be saved as the most recent "received" timestamp. The real 
remote peer does not know this value and this will disrupt the association until the association resets.

References:

http://support.ntp.org/bin/view/Main/NtpBug3453


From https://bugzilla.redhat.com/show_bug.cgi?id=1550214:

ntpd can be vulnerable to Sybil attacks. If a system is set up to use a trustedkey and if one is not using the feature introduced in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to 
specify which IPs can serve time, a malicious authenticated peer -- i.e. one where the attacker knows the private symmetric key -- can create arbitrarily-many ephemeral associations in order to win the 
clock selection of ntpd and modify a victim's clock.

Ps.: This is possibly a incomplete fix for CVE-2016-1549.

References:

http://support.ntp.org/bin/view/Main/NtpBug3415


From https://bugzilla.redhat.com/show_bug.cgi?id=1550208:

ctl_getitem() is used by ntpd to process incoming mode 6 packets. A malicious mode 6 packet can be sent to an ntpd instance, and if the ntpd instance is from 4.2.8p6 thru 4.2.8p10, that will cause 
ctl_getitem() to read past the end of its buffer.

References:

http://support.ntp.org/bin/view/Main/NtpBug3412


@maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.

[Comment 1 Thomas Deutschmann (RETIRED) 2018-03-13 18:27:14 UTC]

*** Bug 650016 has been marked as a duplicate of this bug. ***

[Comment 2 Thomas Deutschmann (RETIRED) 2018-03-13 18:31:33 UTC]

@ Arches,

please test and mark stable: =net-misc/ntp-4.2.8_p11

[Comment 3 GLSAMaker/CVETool Bot 2018-03-13 18:33:24 UTC]

CVE-2018-7185 (https://nvd.nist.gov/vuln/detail/CVE-2018-7185):
  The protocol engine in ntp 4.2.6 before 4.2.8p11 allows a remote attackers
  to cause a denial of service (disruption) by continually sending a packet
  with a zero-origin timestamp and source IP address of the "other side" of an
  interleaved association causing the victim ntpd to reset its association.

CVE-2018-7184 (https://nvd.nist.gov/vuln/detail/CVE-2018-7184):
  ntpd in ntp 4.2.8p4 before 4.2.8p11 drops bad packets before updating the
  "received" timestamp, which allows remote attackers to cause a denial of
  service (disruption) by sending a packet with a zero-origin timestamp
  causing the association to reset and setting the contents of the packet as
  the most recent timestamp. This issue is a result of an incomplete fix for
  CVE-2015-7704.

CVE-2018-7182 (https://nvd.nist.gov/vuln/detail/CVE-2018-7182):
  The ctl_getitem method in ntpd in ntp-4.2.8p6 before 4.2.8p11 allows remote
  attackers to cause a denial of service (out-of-bounds read) via a crafted
  mode 6 packet with a ntpd instance from 4.2.8p6 through 4.2.8p10.

CVE-2018-7170 (https://nvd.nist.gov/vuln/detail/CVE-2018-7170):
  ntpd in ntp 4.2.x before 4.2.8p7 and 4.3.x before 4.3.92 allows
  authenticated users that know the private symmetric key to create
  arbitrarily-many ephemeral associations in order to win the clock selection
  of ntpd and modify a victim's clock via a Sybil attack. This issue exists
  because of an incomplete fix for CVE-2016-1549.

[Comment 4 Mikle Kolyada (RETIRED) 2018-03-13 19:00:37 UTC]

amd64 stable

[Comment 5 Thomas Deutschmann (RETIRED) 2018-03-13 22:29:21 UTC]

x86 stable

[Comment 6 Sergei Trofimovich (RETIRED) 2018-03-14 22:15:37 UTC]

commit 267748ba25eb7b80df44cde7d8d07a50c4f09b83
Author: Rolf Eike Beer <[e-mail]>
Date:   Wed Mar 14 08:13:27 2018 +0100

    net-misc/ntp: stable 4.2.8_p11 for sparc, bug #649612

[Comment 7 Sergei Trofimovich (RETIRED) 2018-03-14 23:25:08 UTC]

ia64 stable

[Comment 8 Matt Turner 2018-03-17 17:46:47 UTC]

alpha stable

[Comment 9 Mart Raudsepp 2018-03-20 20:18:59 UTC]

arm64 does not have any ntp version stable..

[Comment 10 Matt Turner 2018-03-21 22:11:25 UTC]

hppa stable

[Comment 11 Markus Meier 2018-04-08 10:54:35 UTC]

arm stable

[Comment 12 Mikle Kolyada (RETIRED) 2018-05-26 08:02:10 UTC]

ppc/ppc64 stable, old dropped

[Comment 13 Aaron Bauman (RETIRED) 2018-05-26 14:28:43 UTC]

GLSA request filed

[Comment 14 GLSAMaker/CVETool Bot 2018-05-26 16:02:07 UTC]

This issue was resolved and addressed in
 GLSA 201805-12 at https://security.gentoo.org/glsa/201805-12
by GLSA coordinator Christopher Diaz Riveros (chrisadr).

[Comment 15 GLSAMaker/CVETool Bot 2018-05-27 18:34:23 UTC]

This issue was resolved and addressed in
 GLSA 201805-12 at https://security.gentoo.org/glsa/201805-12
by GLSA coordinator Aaron Bauman (b-man).