Stale NTP software included in FreeBSD (RELEASE/STABLE/CURRENT)

[Mark Martinec]

2014-09-03 08:10, John Marshall wrote:
> All of the following FreeBSD releases included stale NTP software at 
> the
> time of their release.
> 
>   8.3-RELEASE  (ntp 4.2.4p5)
>   8.4-RELEASE  (ntp 4.2.4p5)
>   9.0-RELEASE  (ntp 4.2.4p8)
>   9.1-RELEASE  (ntp 4.2.4p8)
>   9.2-RELEASE  (ntp 4.2.4p8)
>   9.3-RELEASE  (ntp 4.2.4p8)
>  10.0-RELEASE  (ntp 4.2.4p8)
> 
> ntp 4.2.4 is the version that shipped in all of the above releases and
> is also included in 10-STABLE and 11-CURRENT at present.  ntp 4.2.4 was
> superseded by the ntp 4.2.6 release on 12-Dec-2009.  Is there any
> interest in getting a supported version of the ntp software into the
> upcoming 10.1 release?  I would have thought that the latest patch
> release of the stable ntp version (4.2.6p5 24-DEC-2011) would be
> appropriate?  I know that the ntp folks are working on releasing 4.2.8
> but it isn't quite there yet.
> 
> I understand that this is a volunteer project and that volunteers don't
> have time to do everything.  I'm just waving the flag in case this is
> something that may have been overlooked.
> 
> Thank you to all those committers who look after vendor imports for all
> of the contributed software that helps make up the FreeBSD releases.

A version ntp-4.2.6p5 is in ports (net/ntp), but is marked as
forbidden due to CVE-2013-5211:

   The monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26
   allows remote attackers to cause a denial of service (traffic
   amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1
   requests, as exploited in the wild in December 2013.

Just recently I came across another problem with the 4.2.4 from base,
which ended up with me opening a PR on the ntp bugzilla:

   Bug 2648 - 'restrict default' should imply both IP protocol families
   http://bugs.ntp.org/show_bug.cgi?id=2648

... only to realize later that by mistake I was testing against the
FreeBSD base version of ntp, and the problem is fixed in net/ntp-devel .

The thing is that when trying to address the amplification attack by
restricting ntp queries, it turns out that the 'restrict default'
only applies to IPv4, and the IPv6 access is left open wide.
Still need to figure out which version fixed that, it works
as expected in the current 4.2.7p470.

So, I'm definitely for upgrading the ntp to something more recent.
The exact version remains to be investigated.

   Mark