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-Str...