This article is more than 1 year old

Boffins want to stop Network Time Protocol's time-travelling exploits

Ancient protocol's key vulnerability is fixable

Among the many problems that exist in the venerable Network Time Protocol is its vulnerability to timing attacks: turning servers into time-travellers can play all kinds of havoc with important systems.

Complicating the problem is that timing attacks are enabled by the protocol itself, which makes it hard to change.

Now a group of researchers from Marvell Semiconductor and the Hebrew University of Jerusalem have followed up on a February 2018 conference presentation with an Internet-Draft proposal they hope can block timing attacks.

Their argument, put in depth in this paper, (PDF) presented to the 2018 Network and Distributed Systems Security (NDSS) Symposium, is that timing attacks can affect “TLS certificates, DNS and DNSSEC, RPKI, Kerberos, BitCoin, and beyond”. The authors also note that time-shifting attacks are possible “even if all NTP communications are encrypted and authenticated” – so a fix is well overdue.

Salvador Dali Persistence of Memory pastiche

Google turns on free public NTP servers that SMEAR TIME

READ MORE

The problem with encrypted/authenticated NTP responses is that a person-is-the-middle can still delay and replay packets to time-shift the victim.

What they propose in “Chronos” is an “alternative set of client mechanisms … that is backward compatible with NTPv4”.

If you take a look at the time configuration in a typical consumer computer, you'll see one or two NTP servers nominated. In Chronos, what the Israeli team proposes is that the client instead “crowd-source” its time information from multiple servers.

It then applies what they call “a provably secure algorithm” to eliminate suspicious responses, and take an average time from the remaining responses as the “true” time.

A server still receives an NTP query in the existing message format, meaning Chronos gets around sysadmins' wariness to reconfiguring their servers: there's no server-side change required.

When it queries a sample of the pool of available time servers nearby to the client – the draft envisages the client interrogating at most tens of servers – the client discards two-thirds of the responses (the highest and lowest values returned).

The only time a Chronos client would query the whole pool in its configuration is if multiple iterations of sampling can't satisfy the client's success conditions – a condition the authors call a “panic mode”, in which every server in the pool is checked.

Their bold claim from the academic analysis is that “in order to succeed in shifting time at a Chronos client by even a small time shift (e.g., 100ms), even a powerful man-in-the-middle attacker requires many years of effort (e.g., over 20 years in expectation).”

Chronos' authors are Neta Rozen Schiff, Danny Dolev, and Michael Schapira of the Hebrew University of Jerusalem; and Tal Mizrahi of Marvell Semiconductor. ®

More about

TIP US OFF

Send us news


Other stories you might like