NTP switch in gnome-control-center is broken

[Miroslav Lichvar]

On Sat, Oct 25, 2014 at 11:41:52AM -0500, Michael Catanzaro wrote:
> An active MITM attackr could change the system time by intercepting NTP
> packets. Such an attack could be used, for example, to bypass HSTS, as
> described in [1], which specifically criticizes Fedora's default
> configuration as insecure on page three (though I imagine chrony must
> have some limits as to how far the system clock can be changed at a
> time?).

It's an interesting paper, but I'm wondering if they have actually
tried the attack with a Fedora machine. In our default configuration
chronyd is allowed to step the clock only in the first three updates,
i.e. in the first ~1 minute after that start. After that, chronyd will
not step the clock no matter how large is the measured offset. When
the initial updates are missed, the worst thing an MITM attacker can
do is change the frequency of the clock by 10%.

Also, the polling interval is normally increased up to the maximum of
1024 seconds (similarly to ntpd), it doesn't stay at 1 minute, and I'm
not sure how is the rtcsync option or the update of the RTC relevant
to the attack.

To summarize the stepping behavior in the default configurations for
chronyd, ntpd and timesyncd:

- chronyd steps the clock to any value, but only on start
- ntpd steps to any value on start, after that each individual step
  has to be smaller than 1000 seconds, otherwise ntpd exits. A step
  is not done immediately, ntpd waits at least 15 minutes for another
  measurement (stepout interval).
- timesyncd steps to any value later than the compiled-in time of the
  systemd release and it does that at any time

If chronyd was configured to track the RTC by default, we could
theoretically disable even the initial step from NTP. The initial
offset would be small unless the system was down/offline for weeks,
another application or operating system was messing with the RTC, an
attacker is spoofing NTP packets, etc. For larger offsets, a mechanism
to inform the desktop user and confirm the correction might be useful
here.

> It looks like ntpd can be configured to prevent such if the NTP
> server signs its messages and the client is configured with its public
> key. It seems safe to assume timesyncd cannot handle this; is that
> correct? What's the status with chrony?

timesyncd doesn't support any authentication. chronyd implements the
authentication using symmetric cryptography, but not the public key
cryptography (RFC 5906).

It would be a great feature to have NTP authentication by default, but
I'm wondering if it's technically even possible to deploy it on such a
large scale as pool.ntp.org. I've not seen any discussion on that so
far.

The authentication doesn't prevent all attacks, however. If the
attacker just needs to adjust the victim's clock by a small number of
seconds, it's possible to trick the NTP client to reduce its polling
interval and throw its clock off just by delaying the authenticated
requests or replies. The NTP traffic is then cut off and the client
will drift away. That's why it's important to monitor the NTP
reachability in critical applications.

> [1]
> https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf

-- 
Miroslav Lichvar