[pkgsrc/pkgsrc-2015Q1]: pkgsrc/net/ntp4 Pullup ticket #4678 - requested by taca

[tron <tron%pkgsrc.org@localhost>]

details:   https://anonhg.NetBSD.org/pkgsrc/rev/d83b1d201e4e
branches:  pkgsrc-2015Q1
changeset: 649181:d83b1d201e4e
user:      tron <tron%pkgsrc.org@localhost>
date:      Tue Apr 21 21:44:22 2015 +0000

description:
Pullup ticket #4678 - requested by taca
net/ntp4: security update

Revisions pulled up:
- net/ntp4/Makefile                                             1.85
- net/ntp4/PLIST                                                1.18
- net/ntp4/distinfo                                             1.21

---
   Module Name: pkgsrc
   Committed By:        taca
   Date:                Wed Apr  8 03:31:34 UTC 2015

   Modified Files:
        pkgsrc/net/ntp4: Makefile PLIST distinfo

   Log Message:
   Update ntp4 package to 4.2.8p2.

   NTP 4.2.8p2 (Harlan Stenn <stenn%ntp.org@localhost>, 2015/04/xx)

   Focus: Security and Bug fixes, enhancements.

   Severity: MEDIUM

   In addition to bug fixes and enhancements, this release fixes the
   following medium-severity vulnerabilities involving private key
   authentication:

   * [Sec 2779] 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.

   * [Sec 2781] 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.

   * New script: update-leap
   The update-leap script will verify and if necessary, update the
   leap-second definition file.
   It requires the following commands in order to work:

        wget logger tr sed shasum

   Some may choose to run this from cron.  It needs more portability testing.

diffstat:

 net/ntp4/Makefile |  4 ++--
 net/ntp4/PLIST    |  3 ++-
 net/ntp4/distinfo |  8 ++++----
 3 files changed, 8 insertions(+), 7 deletions(-)

diffs (46 lines):

diff -r ab24d48e2680 -r d83b1d201e4e net/ntp4/Makefile
--- a/net/ntp4/Makefile Tue Apr 21 21:39:41 2015 +0000
+++ b/net/ntp4/Makefile Tue Apr 21 21:44:22 2015 +0000
@@ -1,7 +1,7 @@
-# $NetBSD: Makefile,v 1.84 2015/03/21 20:49:28 bsiegert Exp $
+# $NetBSD: Makefile,v 1.84.2.1 2015/04/21 21:44:22 tron Exp $
 #
 
-DISTNAME=      ntp-4.2.8p1
+DISTNAME=      ntp-4.2.8p2
 PKGNAME=       ${DISTNAME:S/-dev-/-/}
 CATEGORIES=    net time
 MASTER_SITES=  http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/
diff -r ab24d48e2680 -r d83b1d201e4e net/ntp4/PLIST
--- a/net/ntp4/PLIST    Tue Apr 21 21:39:41 2015 +0000
+++ b/net/ntp4/PLIST    Tue Apr 21 21:44:22 2015 +0000
@@ -1,4 +1,4 @@
-@comment $NetBSD: PLIST,v 1.17 2015/03/21 20:49:28 bsiegert Exp $
+@comment $NetBSD: PLIST,v 1.17.2.1 2015/04/21 21:44:22 tron Exp $
 bin/sntp
 man/man1/sntp.1
 man/man5/ntp.conf.5
@@ -486,6 +486,7 @@
 share/doc/ntp/sntp.html
 share/doc/ntp/stats.html
 share/doc/ntp/tickadj.html
+share/doc/ntp/update-leap.html
 share/doc/ntp/warp.html
 share/doc/ntp/xleave.html
 share/doc/sntp/sntp.html
diff -r ab24d48e2680 -r d83b1d201e4e net/ntp4/distinfo
--- a/net/ntp4/distinfo Tue Apr 21 21:39:41 2015 +0000
+++ b/net/ntp4/distinfo Tue Apr 21 21:44:22 2015 +0000
@@ -1,8 +1,8 @@
-$NetBSD: distinfo,v 1.20 2015/03/21 20:49:28 bsiegert Exp $
+$NetBSD: distinfo,v 1.20.2.1 2015/04/21 21:44:22 tron Exp $
 
-SHA1 (ntp-4.2.8p1.tar.gz) = 1e6d8894bbd3456bd71aa890b02f802f2e611e86
-RMD160 (ntp-4.2.8p1.tar.gz) = f61569230e876faf9271607aff9dcbd242ea4f69
-Size (ntp-4.2.8p1.tar.gz) = 6791852 bytes
+SHA1 (ntp-4.2.8p2.tar.gz) = 51d014c4a38383692d0895f5b8247004942e3b38
+RMD160 (ntp-4.2.8p2.tar.gz) = 5e2bec1f296f6d1528694167da2229cae13ebf47
+Size (ntp-4.2.8p2.tar.gz) = 6820869 bytes
 SHA1 (patch-aa) = b247569339d09a88f2e143e355033ce7635ffe92
 SHA1 (patch-configure) = 21466ffa5d0334957a1a93b2a99087e7edaaa4d5
 SHA1 (patch-sntp_configure) = 38357046af0f0c1aeb8b57bb9c653e330d3feadd