Slashdot Mirror
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.
Oh boy not Bitcoin! Save us!
have an option for ignoring server updates if the time differential is too great.
RFC 5906
don't screw around with options once they get the thing initially functioning.
NTP is a protocol for synchronizing your clock with another clock. It's not the protocol's fault if you choose a dumb clock to synchronize with, and if the resulting time ends up causing problems with your system.
Because fenceposting, drifting time that's as accurate as asking someone who glances at their watch (kids, look that up) is what everyone needs!
Isn't Eric Raymond in the middle of a major rewrite of the NTP software, with emphasis on security?
How fun! Now we can advance right past the next Y2K type bug...
Researchers warn [X] is unsafe.
"We should replace [X] with [Y]!"
Later:
Researchers warn [Y] is unsafe.
Can we, like, audit something rather that just keep replacing things and letting the users figure out which new ones were broken? Maybe the researchers could take a look at [Y] and make sure that's working before we switch it out?
Yesterday I dared venture to reddit.com and the stories all said they were posted 30 years ago. Great Scott, I'm not sure what could have happened. Their nptds must have been off by several jigawatts.
systemd automatically knows what time it is, but it'll only tell you in binary.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Once an RFC is adopted by IETF (as the linked RFC is), it becomes a standard. Bro, do you even internet?
Not so fast son. RFC 1796 - Not All RFCs are Standards .
RFC becomes standard provided, it's been put on standards track. As you can observe from above RFC 1796 it's status is Informational ie. it's not standard.
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.
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.
.
A quick description of OpenNTPd's constraints is here.
This would have been an issue with either time sync protocol since the source clock was changed.
...
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.
You have to be able to have an accurate time reference because a lot of devices interact with the real world. Logs, audit trails, signals intelligence, even photographs and surveillance cameras are a lot more meaningful if they have timestamps. If you can manipulate timestamps by using a flaw in NTP, then you can have an alibi for... anything.
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.
Recent Vulnerabilities --- October 2015 NTP Security Vulnerability Announcement (Medium)
I remember that day in 2012. Less than an hour and I had my work network (fifty workstations, about six servers doing various things) corrected, and it was less than four hours until the Navy fixed their problem and everything was restored back to normal operation.
So, seeing that NTP has been around before 1985 per Wikipedia, but I'll give it credit that I didn't start using it until 1995ish, and I'll even credit the full four hours out even though actual disruption was one hour. Four hours in twenty years. 12 minutes per year of problem time, or about 1 minute down per 3,650 minutes of uptime. 99.9726027397% uptime.
YMMV certainly. But yeah, I think I'll wait until this actually becomes a problem to do anything about it, thanks.
My desktop is updated via a GPS receiver connected to Tardis 2000 so I don't have to use any Internet-connected time server.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
It's Y2K all over again! Horde the ammo and water! Dig your bunkers a few meters deeper! Gird your loins!?
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.
"Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws" But can it be disassembled and put into a briefcase? Clockmed wants to know!
Says the loser.
This particular RFC has this status:
Status: Rejected (1)
But also notice this request for comments is not used or even cited but by this one person - who probably wrote the thing (how many times now?).
INFORMATIONAL
Errata Exist
Internet Engineering Task Force(IETF)
Request for Comments: 5906
Category: Informational
B. Haberman, Ed.
D. Mills
ISSN: 2070-1721
U. Delaware
June 2010
I told you the Y2K thing was real!!
"...rolled back their clocks 12 years, deciding it was the year 2000."
Yes, this can happen if one is an idiot and does not set up their not properly. Simply use an app that sets a maximum amount of time that the clock can be shifted. I don't allow my network to be altered more than 5 minutes as the time check is implemented daily and their is no good reason why a clock would be off by even this amount.
Need to know..
"Researchers at Boston University said this week that they've found flaws in the Network Time Protocol (NTP)" .. and it's been patched already ..
'We thank the Network Time Foundation, NTPsec, Cisco, and RedHat's security team for quickly issuing patches for various issues described in this work'
The Windows capability to synchronize my PC clock depends on a single time server.
Rubbish! I think you might be solely aware of the GUI. The following command will let you set a list of time servers. /config /manualpeerlist:server1,server2,server3 /syncfromflags:manual /update
w32tm
But, even if you only entered one address in the GUI, the us.pool.ntp.org pool is presently over 800 NTP servers.
There has been absolutely zero need to use any third party time sync system on Windows for over 12 years. It's built in and it works fine, even if you are clueless.