Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 545836 - <net-misc/ntp-4.2.8_p2: two vulnerabilities (CVE-2015-{1798,1799})
Summary: <net-misc/ntp-4.2.8_p2: two vulnerabilities (CVE-2015-{1798,1799})
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://support.ntp.org/bin/view/Main/...
Whiteboard: B3 [glsa cve]
Keywords:
: 545990 (view as bug list)
Depends on: CVE-2015-5146
Blocks:
  Show dependency tree
 
Reported: 2015-04-07 15:59 UTC by Agostino Sarubbo
Modified: 2016-02-25 08:19 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-04-07 15:59:39 UTC
From ${URL} :

1)ntpd accepts unauthenticated packets with symmetric key crypto.

References: Sec 2779 / CVE-2015-1798 / VU#374268
Affects: All NTP4 releases starting with ntp-4.2.5p99 up to but not including ntp-4.2.8p2 where the installation uses symmetric keys to authenticate remote associations.
CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4
Date Resolved: Stable (4.2.8p2) 07 Apr 2015
Summary: When ntpd is configured to use a symmetric key to authenticate a remote NTP server/peer, it checks if the NTP message authentication code (MAC) in received packets is valid, but not if there actually is any MAC included. Packets without a MAC are 
accepted as if they had a valid MAC. This allows a MITM attacker to send false packets that are accepted by the client/peer without having to know the symmetric key. The attacker needs to know the transmit timestamp of the client to match it in the forged reply 
and the false reply needs to reach the client before the genuine reply from the server. The attacker doesn't necessarily need to be relaying the packets between the client and the server. 
Authentication using autokey doesn't have this problem as there is a check that requires the key ID to be larger than NTP_MAXKEY, which fails for packets without a MAC.
Mitigation:
Upgrade to 4.2.8p2, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page
Configure ntpd with enough time sources and monitor it properly.
Credit: This issue was discovered by Miroslav Lichvar, of Red Hat.


2)Authentication doesn't protect symmetric associations against DoS attacks.

References: Sec 2781 / CVE-2015-1799 / VU#374268
Affects: All NTP releases starting with at least xntp3.3wy up to but not including ntp-4.2.8p2 where the installation uses symmetric key authentication.
CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4 
Note: the CVSS base Score for this issue could be 4.3 or lower, and it could be higher than 5.4.
Date Resolved: Stable (4.2.8p2) 07 Apr 2015
Summary: An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on 
its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. This is a known 
denial-of-service attack, described at https://www.eecis.udel.edu/~mills/onwire.html . 

According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn't seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with 
originate timestamps that don't match the transmit timestamps on the receiving side. 

This seems to be a very old problem, dating back to at least xntp3.3wy. It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too. An update 
to the NTP RFC to correct this error is in-process.
Mitigation:
Upgrade to 4.2.8p2, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page
Note that for users of autokey, this specific style of MITM attack is simply a long-known potential problem.
Configure ntpd with appropriate time sources and monitor ntpd. Alert your staff if problems are detected.
Credit: This issue was discovered by Miroslav Lichvar, of Red Hat.


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2015-04-08 19:40:12 UTC
*** Bug 545990 has been marked as a duplicate of this bug. ***
Comment 2 SpanKY gentoo-dev 2015-04-08 21:13:20 UTC
Commit message: Version bump
http://sources.gentoo.org/net-misc/ntp/ntp-4.2.8_p2.ebuild?rev=1.1
Comment 3 cilly 2015-04-08 22:40:04 UTC
(In reply to SpanKY from comment #2)
> Commit message: Version bump
> http://sources.gentoo.org/net-misc/ntp/ntp-4.2.8_p2.ebuild?rev=1.1

!!! Couldn't download 'ntp-4.2.8p2-manpages.tar.bz2'. Aborting.
 * Fetch failed for 'net-misc/ntp-4.2.8_p2', Log file:
 *  '/var/tmp/portage/net-misc/ntp-4.2.8_p2/temp/build.log'

>>> Failed to emerge net-misc/ntp-4.2.8_p2
Comment 4 SpanKY gentoo-dev 2015-04-09 00:35:23 UTC
(In reply to cilly from comment #3)

uploaded
Comment 5 GLSAMaker/CVETool Bot gentoo-dev 2015-06-15 00:07:39 UTC
CVE-2015-1799 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1799):
  The symmetric-key feature in the receive function in ntp_proto.c in ntpd in
  NTP 3.x and 4.x before 4.2.8p2 performs state-variable updates upon
  receiving certain invalid packets, which makes it easier for
  man-in-the-middle attackers to cause a denial of service (synchronization
  loss) by spoofing the source IP address of a peer.

CVE-2015-1798 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1798):
  The symmetric-key feature in the receive function in ntp_proto.c in ntpd in
  NTP 4.x before 4.2.8p2 requires a correct MAC only if the MAC field has a
  nonzero length, which makes it easier for man-in-the-middle attackers to
  spoof packets by omitting the MAC.
Comment 6 Yury German Gentoo Infrastructure gentoo-dev 2015-08-05 06:34:14 UTC
Added to an existing GLSA Request.

Maintainer(s), please drop the vulnerable version(s).
Comment 7 Yury German Gentoo Infrastructure gentoo-dev 2015-09-23 11:47:27 UTC
Maintainer(s), please drop the vulnerable version(s).
Comment 8 GLSAMaker/CVETool Bot gentoo-dev 2015-09-24 16:45:57 UTC
This issue was resolved and addressed in
 GLSA 201509-01 at https://security.gentoo.org/glsa/201509-01
by GLSA coordinator Kristian Fiskerstrand (K_F).
Comment 9 Yury German Gentoo Infrastructure gentoo-dev 2015-09-27 02:47:18 UTC
Re-Opening for Cleanup

Maintainer(s), please drop the vulnerable version(s).
Comment 10 Yury German Gentoo Infrastructure gentoo-dev 2016-02-25 08:19:36 UTC
Arches and Maintainer(s), Thank you for your work.

closing