Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Remko Lodder]

> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Trond Endrestøl]

On Wed, 7 Mar 2018 14:30+0100, Remko Lodder wrote:

> > On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> > 
> > Were these changes and the kernel changes tested together on Xen?  
> > After updating to -p7, I get about 10 seconds of uptime on a Xen 
> > VM before the kernel panics with a double fault and reboots.  
> > Disabling ntpd results in a stable system.  On an AMD system 
> > without a hypervisor, I don’t see any instability.
> 
> Hi David,
> 
> We have no Xen setup as far as I know so in short; these changes were not 
> tested on Xen as far as I know.
> 
> Cheers
> Remko

Here's one of my systems, running ntpd on stable/11 r330228 on 
XenServer 7.3, and there have been no issues so far. Timekeeping is as 
good as can be expected. The XenServer host has Intel CPUs.

$ uname -aKU
FreeBSD somehost 11.1-STABLE FreeBSD 11.1-STABLE #0 r330228: Thu Mar  1 
10:58:45 CET 2018 root@somehost:/usr/obj/usr/src/sys/XENGUEST  amd64 
1101511 1101511
$ w | head -1
 2:18p.m.  up 5 days,  1:23, 1 user, load averages: 0,18 0,20 0,17

Note, I run a custom kernel eliminating most of the unneeded stuff 
when running as a/an Xen guest, see 
https://ximalas.info/~trond/create-zfs/canmount/XENGUEST-amd64-stable-11 
for details.

-- 
Trond.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[Remko Lodder]

> On 7 Mar 2018, at 12:50, David Chisnall  wrote:
> 
> Were these changes and the kernel changes tested together on Xen?  After 
> updating to -p7, I get about 10 seconds of uptime on a Xen VM before the 
> kernel panics with a double fault and reboots.  Disabling ntpd results in a 
> stable system.  On an AMD system without a hypervisor, I don’t see any 
> instability.
> 
> David
> 
>> 

Hi David,

We have no Xen setup as far as I know so in short; these changes were not 
tested on Xen as far as I know.

Cheers
Remko



signature.asc
Description: Message signed with OpenPGP

Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:02.ntp

[David Chisnall]

Were these changes and the kernel changes tested together on Xen?  After 
updating to -p7, I get about 10 seconds of uptime on a Xen VM before the kernel 
panics with a double fault and reboots.  Disabling ntpd results in a stable 
system.  On an AMD system without a hypervisor, I don’t see any instability.

David

> On 7 Mar 2018, at 07:10, FreeBSD Security Advisories 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> =
> FreeBSD-SA-18:02.ntpSecurity Advisory
>  The FreeBSD Project
> 
> Topic:  Multiple vulnerabilities of ntp
> 
> Category:   contrib
> Module: ntp
> Announced:  2018-03-07
> Credits:Network Time Foundation
> Affects:All supported versions of FreeBSD.
> Corrected:  2018-02-28 09:01:03 UTC (stable/11, 11.1-STABLE)
>2018-03-07 05:58:24 UTC (releng/11.1, 11.1-RELEASE-p7)
>2018-03-01 04:06:49 UTC (stable/10, 10.4-STABLE)
>2018-03-07 05:58:24 UTC (releng/10.4, 10.4-RELEASE-p6)
>2018-03-07 05:58:24 UTC (releng/10.3, 10.3-RELEASE-p27)
> CVE Name:   CVE-2018-7182, CVE-2018-7170, CVE-2018-7184, CVE-2018-7185,
>CVE-2018-7183
> 
> For general information regarding FreeBSD Security Advisories,
> including descriptions of the fields above, security branches, and the
> following sections, please visit .
> 
> I.   Background
> 
> The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
> used to synchronize the time of a computer system to a reference time
> source.
> 
> II.  Problem Description
> 
> The ctl_getitem() function is used by ntpd(8) 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 through 4.2.8p10, ctl_getitem() will
> read past the end of its buffer. [CVE-2018-7182]
> 
> The ntpd(8) service can be vulnerable to Sybil attacks.  If a system is
> configured 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. [CVE-2018-7170]
> 
> 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.
> [CVE-2018-7184]
> 
> 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.  [CVE-2018-7185]
> 
> The ntpq(8) utility is a monitoring and control program for ntpd.  The
> internal decodearr() function of ntpq(8) that is used to 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(8)
> request on its way to a remote ntpd server and forge and send a response
> before the remote ntpd sends its response.  It is potentially possible that
> the malicious data could become injectable/executable code. [CVE-2017-7183]
> 
> III. Impact
> 
> Malicious remote attackers may be able to break time synchornization,
> or cause the ntpq(8) utility to crash.
> 
> IV.  Workaround
> 
> No workaround is available, but systems not running ntpd(8) or ntpq(8) are
> not affected.  Network administrators are advised to implement BCP-38 which
> helps to reduce risk associated with the attacks.
> 
> V.   Solution
> 
> Perform one of the