Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws (networkworld.com)

alphadogg writes: Researchers at Boston University said this week that they've found flaws in the Network Time Protocol (NTP), a 30-year-old Internet protocol whose security shortcomings could undermine encrypted communications and even jam up bitcoin transactions. The importance of NTP was highlighted in a 2012 incident in which two servers run by the U.S. Navy rolled back their clocks 12 years, deciding it was the year 2000. Computers that checked in with the Navy's servers and adjusted their clocks accordingly had a variety of problems with their phones systems, routers and authentication systems. There is at least one alternative out there, and reason to use it.

Comments

Most NTP clients I've seen...

[Chris Mattern]

have an option for ignoring server updates if the time differential is too great.

Re:Most NTP clients I've seen...

[Penguinisto]

Not only that, but there are loads of other options, the most basic being that you can use your own personal stratum 1 device, and point all your servers to that. Hell, you can even build your own if you're truly paranoid.

IIRC by default the Windows AD infrastructure has member clients/servers using the Domain Controllers as their local source, and then you only need to re-point the DCs to whatever you want (the registry info documentation for NTP was a bit hinkey as late as Win7/Win2k8, so if you go mucking around in there, do it at your own risk). On the Linux/BSD/*nix side, there's a zillion options to beef up security, and they are drop-easy to enforce with any competent orchestration software (puppet, cfengine, chef, whatever). I only remember the Windows side because a previous employer had a distributed BI system that demanded that all component client devices (a mixture of Windows and Linux) must remain within 5 seconds of each other time-wise (else the whole thing threw an error and stopped).

Like sibling said though, most sysadmins don't dork around with NTP once they get a time source running - few will set up a local NTP relay of sorts, fewer still will have those sources use at least three different and vastly disparate sources to check against, and very few will set up a local authoritative stratum 1 box.

Lots of workarounds, and you really only have to set it up right once, with maybe an occasional (as in once-a-year-or-so) review and tuneup of the infrastructure.

Re:Most NTP clients I've seen...

[the_other_chewey]

That would work if the attackee uses only the attacker's server.
That's not how NTP is supposed to be used: It is designed to pull
time from multiple sources, weigh their accuracy/trustworthyness
over a longer time window against each other (with rather sophisticated
algorithms), and use the best ones as the time source to follow.

I usually go for 5-6 independent sources (with independent stratum0 masters!):
some national labs' PPS; GPS; etc. - this doesn't make an attack impossible,
but it mitigates the "the master time source is wrong" problem. This has
happend by accident before, so even without considering active attacks, it's
just the sensible thing to do.

Re:Most NTP clients I've seen...

[arglebargle_xiv]

There is at least one alternative out there

Whoever proposed tlsdate as an alternative to NTP has no idea how either NTP or tlsdate work. What moving to tlsdate is doing is replacing a well-designed clock-synchronisation protocol talking to precise time servers with an opportunistic gimme-whatver-time-you've-got mechanism that returns a one-off estimate of an approximate time on a web server, assuming the server doesn't just set the time field to random bytes as many do. They're totally different things.

If you're really worried about this, run your own stratum 1 clock and serve NTP off that. If you're worried about the cost of a dedicated NTP server, build it yourself using any number of instructions on the Internet, e.g. these ones.

Re:Most NTP clients I've seen...

[Technician]

Many devices such as tablets and cell phones contain GPS, another hard to spoof time source. Multi factor authentication checking NTP, Cell tower time, and GPS would make a very robust system that could detect tampering. On an IMSI catcher, Time wrong, GPS time difference would catch it. NTP spoof, Cell and GPS mismatch would catch it. Local area GPS spoof, Cell and NTP would catch it. Targeting a mobile device with 3 factor time authentication + internal clock for 4 factor would be very hard to spoof undetected.

If you want to roll your own, GPS receiver modules for RC drones are under $20 online. Adding GPS to your NTP corporate servers is not difficult. You can protect your network with a little hardware and software.

Re:Most users I've seen...

[Anonymous Coward]

don't screw around with options once they get the thing initially functioning.

Re:Authenticated NTP?

[halivar]

Once an RFC is adopted by IETF (as the linked RFC is), it becomes a standard. Bro, do you even internet?

Ob

[Hognoxious]

systemd automatically knows what time it is, but it'll only tell you in binary.

Re:Eric Raymond rewrite

[0123456]

Isn't Eric Raymond in the middle of a major rewrite of the NTP software, with emphasis on security?

I heard it was going to become part of systemd.

So design things to not require synced clocks.

[tlambert]

So design things to not require synced clocks.

It's not like you couldn't include your idea of your local time (whatever it is) in your NFS requests, and then have the server take its idea of its local time, generate a delta, and apply that to all the timestamps that you are trying to set on a file. Or conversely, when you do a stat, the server could include its idea of the local time, the client could use that to generate a delta vs. its own idea of local time, and apply that delta to the time being reported up from the kernel to user space.

The whole idea of having to synchronize clocks between machines is rather moronic. When you have a billion mechanical computers wandering around in your body with robot bodies to e.g. fight a nasty cancer, do you really think there's going to be enough spare CPU cycles, RAM, or communications bandwidth for them to run NTP requests around to each other?

I recently fielded a request from someone who was building an embedded device; the trick was, it was going to be pre-programmed, then deployed everywhere, and not have local time beacons (i.e. it couldn't access local beacons, such as local cell towers, which send out "time is now" broadcasts). The question was: "How do I sync the time to the local time?".

My response was "Why?".

The reason finally boiled down to wanting to put the time in log files, and to display it on an LCD.

There was no reason for either of these: if the devices are Internet connected, just grab an HTTP header by hitting a known HTTP server, and log in UTC, since the time in the header will be reported as a UTC time + a zone delta. For the display: why the hell do you need to display the time on the small LCD? Because it was the only neutral thing he could think of to display on the LCD. "Can't I just look at my watch/iPhone/VCR/microwave/refrigerator/dishwasher/clock? Or just display it in UTC? Or display a PacMan animation instead of a clock?". "I guess so".

Problem solved with no need to sync clocks.

Non-synchronized clocks are only a problem if you let them be a problem/make them a problem.

Re:So design things to not require synced clocks.

[UnknowingFool]

So design things to not require synced clocks.

Practically all of modern humanity requires clocks so I'm not sure how we can design modern life without clocks.

The whole idea of having to synchronize clocks between machines is rather moronic.

Synchronizing clocks is necessary because clocks drift. Clocks have always drifted since the dawn of humanity. Humans have been able to make clocks that are more accurate but unless you want every machine to have an atomic clock built-in, synchronizing is one way to ensure they all agree.

When you have a billion mechanical computers wandering around in your body with robot bodies to e.g. fight a nasty cancer, do you really think there's going to be enough spare CPU cycles, RAM, or communications bandwidth for them to run NTP requests around to each other?

Um we are not talking about nanobots in the future. We are talking about today and servers: servers that run everything from email to shopping to banking. They all rely on correct clocks

There was no reason for either of these: if the devices are Internet connected, just grab an HTTP header by hitting a known HTTP server, and log in UTC, since the time in the header will be reported as a UTC time + a zone delta.

And how can your ensure that the web server that was hit has the correct time? That web server used an NTP server somewhere.

Problem solved with no need to sync clocks.

In your one example of an embedded device, you can question whether it needed to sync a clock. For the rest of the world, it is needed. Your sample size of one does not translate to the whole world.

Not for Windows?

[DERoss]

It appears to me that all the NTP patches and all the NTP alternatives are for UNIX or Linux systems.

I use SocketWatch on Windows 7 to synchronize my PC clock with external time servers around the world. I have it set to run every hour. It warns me whenever an adjustment to my PC clock is excessive (using my definition of "excessive").

The questions are: How do the reported problems with NTP affect me. Or do those problems only affect time servers?

Yes, I know SocketWatch is no longer being maintained. The developer is going out of business and will soon stop distributing it. As long as it works for me, I hope to keep using it.

Synced clocks are necessary

[sjbe]

So design things to not require synced clocks.

They do when that is a sane thing to do. Sometimes a precise notion of time isn't important. But many activities are impossible without a rather precise determination of the time across multiple devices.

It's not like you couldn't include your idea of your local time (whatever it is) in your NFS requests, and then have the server take its idea of its local time, generate a delta, and apply that to all the timestamps that you are trying to set on a file.

The only way to ensure the local time on your clock is correct is to synchronize with another clock. A clock providing arbitrary time stamps is worse than useless. In fact for many activities what you suggest would lead to accidents, fraud and all sorts of confusion.

Any time you have a measuring device where you care about its accuracy you have to compare it to a reference standard. That's why we have highly accurate atomic clocks maintained by standards organizations to calibrate our clocks to.

Non-synchronized clocks are only a problem if you let them be a problem/make them a problem.

Sorry my friend but that's simply not true for a lot of problems.

Re:Eric Raymond rewrite

[Bengie]

OpenNTP uses a pool of HTTPS servers to do basic sanity checks against the NTP time. It does a kind of simple NTP using TLS, then uses NTP against your time servers. If the NTP time is too far off from the TLS time, it rejects it. Pretty much all of the practical security of NTPSEC without all of the accuracy reducing overhead.

Re:Eric Raymond rewrite

[NotInHere]

Time synchronisation is in systemd already:

http://lists.freedesktop.org/a...

And it uses SNTP, not NTP.

tlsdate isn't a NTP replacement

[plcurechax]

The mentioned TLSdate isn't a NTP replacement.

It openly admits is roughly only good for a <1-5 second accuracy. That's crap. A typical NTP setup can easily maintain ~10-15 millisecond accuracy using public stratum 2 or 3 NTP servers from the Internet.

Sure, tlsdate is a simple, secure rdate replacement, and while many people without precise timing requirements it is good enough, it is simply not suitable for a huge range of applications that are time sensitive, or are timing / synchronization critical.