Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
The Internet Security IT

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

Posted by timothy from the when-was-that-again dept.
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.
This discussion has been archived. No new comments can be posted.

Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws More

Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws

Comments Filter:

  • Bitcoin! (Score:1, Funny)

    by Anonymous Coward

    Oh boy not Bitcoin! Save us!

    • Dogecoin is seven times more secure to clock changes than Bitcoin.

  • Most NTP clients I've seen... (Score:5, Insightful)

    by Chris Mattern ( 191822 ) on Thursday October 22, 2015 @09:31AM (#50780823)

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

    • Re:Most users I've seen... (Score:4, Insightful)

      by Anonymous Coward on Thursday October 22, 2015 @09:35AM (#50780861)
      don't screw around with options once they get the thing initially functioning.

    • Re:Most NTP clients I've seen... (Score:5, Insightful)

      by Penguinisto ( 415985 ) on Thursday October 22, 2015 @09:52AM (#50780975) Journal

      Not only that, but there are loads of other options, the most basic being that you can use your own personal stratum 1 device [probroadcastsupply.com], and point all your servers to that. Hell, you can even build your own [satsignal.eu] 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: (Score:3)

        by jabuzz ( 182671 )

        An additional idea for a cheap personal stratum 1 device if you happen to live in the reception area of a suitable LW radioclock.

        http://www.buzzard.me.uk/jonat... [buzzard.me.uk]

        Had my own personal dual source (MSF/DF77) stratum 1 time server for over a decade now.

        • I was about to Google for exactly that. There is this RaspberryPi based solution too : http://www.satsignal.eu/ntp/Ra... [satsignal.eu]

      • Hell, you can even build your own if you're truly paranoid.

        It's a good idea, but the forty euro GPS shield can easily be replaced by a twenty euro GPS board, a NEO-6M. These are also favored for drones because they are teensy tiny and they are smart enough to store configuration settings such that they will wake up, acquire, and start spewing GPS data on their serial port at your chosen baudrate. They also feature a PPS pin. Buy one with a header strip on and you can connect it to the Pi without soldering. Plus, they are useful for other projects if you decide to r

      • Re:Most NTP clients I've seen... (Score:4, Informative)

        by Technician ( 215283 ) on Thursday October 22, 2015 @11:18AM (#50781721)

        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.

        • How is GPS a time source?

          • GPS Time [lammertbies.nl]

            "The GPS system allows a maximum of 32 satellites around the earth which each transmit their own position and time on a regular interval to the earth."

            • Many GPS receivers will output a very accurate 1 sec tic. I've used this to check for multipath drift from WWV in maintaining a cesium beam atomic clock in one installation. The time standards were used to callibrate RF equipment to NIST standards. Multi source verification validates source drift and gives the degree of confidence for the certification paperwork. If your tracable standards are accurate to each other with jitter and drift to 8 9's, you can validate equipment as to being within 7 9's. Thi

          • Re: (Score:2)

            by mikael ( 484 )

            Each GPS satellite transmits a time code along with its ID number. When the receiver is able to locate a signal from four or more satellites, it can determine the distances to those satellites. Some simple spherical trigonometry allows the latitude, longitude and altitude to be calculated for the receiver.

        • Adding GPS to your NTP corporate servers is not difficult.

          Adding a window to the server room, or running a GPS antenna cable through the cable trunking to the outside world is likely to be the harder part of the process. PARTICULARLY if you have anything resembling Management Of Change procedures for your physical cabling.

      • Besides which, doesn't IBM have a patent on inaccurate computer clocks? Tromp on that and you'll probably find them suing you for your car, home, savings, and first born son.

    • Couldn't an attacker still exploit the vulnerability by incrementally making small adjustments that fall within the differential though? Just because it can prevent a single large inadvertent mistake doesn't mean it's completely safe.

      • Re: (Score:1)

        by Anonymous Coward

        it's nontrivial in the first place, doing it repeatedly over a period of time would require a focused attacker. and nothing stops a focused attacker.

      • Re:Most NTP clients I've seen... (Score:4, Informative)

        by the_other_chewey ( 1119125 ) on Thursday October 22, 2015 @10:11AM (#50781143)
        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.

        • That's good advice (it may actually be formal Best Practice for NTP configuration), but does violate Segal's Law: [wikipedia.org]

          "A man with a watch knows what time it is. A man with two watches is never sure."

          Which ultimately demonstrates that "a witty saying proves nothing."

          • This is why it pains me when I see two NTP servers setup. You NEVER know which one is right. Having just 1 is better than that.

            To me, the minimum is 4: This gives you n+1, since you need at least 3 clocks to know if the time is right, and NTP will actually play ball with this logic: It will first look to see if 1 of the 3 are way off and exclude it, then it will sync time from the clock that is the lowest stratum and most stable.

          • As I routinely say to my trainees.

            "One measurement is a datum. Two measurements is a disagreement. Three measurements is a majority opinion. Four measurements is statistics."

    • Re:Most NTP clients I've seen... (Score:5, Informative)

      by arglebargle_xiv ( 2212710 ) on Thursday October 22, 2015 @10:26AM (#50781279)

      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 [satsignal.eu].

    • Re: (Score:2)

      by rthille ( 8526 )

      Yes, and if you read the article, you'll see they found ways around them.

    • Re: (Score:2)

      by dbIII ( 701233 )
      And/or get their time from a few sources.

  • Authenticated NTP? (Score:3)

    by sinij ( 911942 ) on Thursday October 22, 2015 @09:32AM (#50780833)
    RFC 5906 [ietf.org]

    • What a great idea let every protocol invent its own crappy little authentication scheme.

      • Different protocols have different requirements; especially something as time sensitive as NTP.

        Treating security with a 'one size fits all' approach is never a good idea.

        • Different protocols have different requirements; especially something as time sensitive as NTP.

          DTLS adds no latency over UDP for purpose of time synchronization.

          Treating security with a 'one size fits all' approach is never a good idea.

          Unless it actually fits then its a great idea.

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

  • And around and around we go... (Score:1)

    by Anonymous Coward

    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?

  • Ob (Score:5, Funny)

    by Hognoxious ( 631665 ) on Thursday October 22, 2015 @09:56AM (#50781015) Homepage Journal

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

  • So design things to not require synced clocks. (Score:4, Interesting)

    by tlambert ( 566799 ) on Thursday October 22, 2015 @10:00AM (#50781063)

    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.

    • ...

      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.

    • Synced clocks are necessary (Score:4, Insightful)

      by sjbe ( 173966 ) on Thursday October 22, 2015 @10:20AM (#50781213)

      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.

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

        [...]

        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.

        These are reasonable arguments for a UTC time. Which you can get by hitting a known HTTP server, which I've already pointed out.

        These are not reasonable arguments for trying to do NTP from an IoT device, and they are not reasonable arguments for trying to do NTP for most applications.

    • Re:So design things to not require synced clocks. (Score:4, Interesting)

      by UnknowingFool ( 672806 ) on Thursday October 22, 2015 @10:24AM (#50781257)

      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.

    • So design things to not require synced clocks.

      What happens when you can't or such a design would be more difficult than a global shared time reference?

      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.

      What happens when every system can't just stamp their own "idea of local time" on to an event when it occurs? What happens when every systems "idea of local time" changes over time?

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

      Obviously it is best to avoid dependencies which require synchronization where possible. Unfortunately it isn't always possible.

      • So design things to not require synced clocks.

        What happens when you can't or such a design would be more difficult than a global shared time reference?

        What happens when every system can't just stamp their own "idea of local time" on to an event when it occurs? What happens when every systems "idea of local time" changes over time?

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

        Obviously it is best to avoid dependencies which require synchronization where possible. Unfortunately it isn't always possible.

        In those cases, use NTP. Or use direct tier one information from GPS or cell tower data (if you are OK with the +/- 1 second on the cell tower's idea of the time). Or set the device's idea of local time as part of the handshake establishing the connection with the server (although this last one wouldn't work for mesh networks not communicating with servers).

    • Good luck on that.

      Try getting a database spread across multiple servers without good clock sync. Try getting version control + build systems working well over a network without good clock sync.

      It is kind of like having unguarded critical sections in your code. You might get something that works most of the time but you'll be left with mysterious and messy failures that are hard to explain, hard to reproduce, and make you want to gouge your own eyeballs out. I'd rather keep my eyeballs in their sockets wh

    • Re: (Score:2)

      by dbIII ( 701233 )
      Another thing, the Zune with the spectacular leap year bug that meant it would run 365 days a year and not run at all on the last day of a leap year unless the user changed the date. It only had a clock because of some braindead DRM bullshit of having an expiry time on music files. Such a scheme was an afterthought so a clock was needed and put on as an afterthought and not properly tested. Apart from that it didn't need to know what day or even year it was.

  • Not for Windows? (Score:4, Interesting)

    by DERoss ( 1919496 ) on Thursday October 22, 2015 @10:02AM (#50781081)

    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.

    • Hasn't Windows automatically synched time out of the box since the first Lord of the Rings movie was released?

      • Hasn't Windows automatically synched time out of the box since the first Lord of the Rings movie was released?

        ISTR it's had the feature since Win2k. It's pretty sloppy, though.

      • Re: (Score:3)

        by DERoss ( 1919496 )

        The Windows capability to synchronize my PC clock depends on a single time server. The default is Microsoft's own time.windows.com, which is not always up.

        SocketWatch does not tie me to one particular time server the way the Windows capability does. SocketWatch has a list of servers, which I have edited. My list now has over 200 entries. Per my option settings, SocketWatch queries the top five entries from the list hourly, scoring each entry primarily on how quickly the server responds. The server with

        • The Windows capability to synchronize my PC clock depends on a single time server.

          time.windows.com is a pool, it's not a single server. The only real risk you have is DNS going down.

          My list includes some stratum 1 servers, which are atomic clocks.

          Do you run a small cluster of stratum 2 servers for the express purpose of serving time to hundreds of other machines? If not you have no business syncing to stratum 1 servers. If you have a specific application for a single device that needs a high accuracy clock then why not spend $50 on a GPS unit with which you can sync your way to stratum 1 precision.

          • Re: (Score:2)

            by DERoss ( 1919496 )

            I only use those stratum 1 servers that (a) either serve my geographical area or are worldwide, (b) that have "open access", and (c) do not require me to notify them that I am using them. Also, I only use those stratum 2 servers that meet the same criteria.

            The "Rules of Engagement" state: "There are many scenarios where the above rules may not apply, especially ... clients with intermittent connectivity ..." Given that I disconnect from the Internet whenever I walk away from my PC and I shut down my PC wh

        • Re: (Score:2)

          by dbIII ( 701233 )
          It's one of many MS Windows products that ask NTP servers for the time. If they go out of business just use another, which may not be quite as good but will be better than the built in MS thing that seems to deliver strange results several times per year.
  • OpenBSD's OpenNTPd with https constraints is mentioned in the Update section of one of the URLs [hboeck.de] cited in the summary. Constraints use the time in a https header to "constrain" the ntp time to reasonableness.

    .
    A quick description of OpenNTPd's constraints is here [marc.info].

  • This would have been an issue with either time sync protocol since the source clock was changed.

    • How true. Wouldn't it be the fault of the system who accepted a time 12 years in the past and started up without so much as a "Hey, System Administrator! You might want to look at this! Do you really intend to go back 12 years in time here?" I know it wouldn't fix anything because such warnings would likely be ignored anyway, but at least the system Administrator would be to blame then.

  • My desktop is updated via a GPS receiver connected to Tardis 2000 so I don't have to use any Internet-connected time server.
    • Oh man, ditch the windows machine for a Linux box..... But good for you. Most folks won't have the necessary infrastructure to support a GPS based time sync directly, for them NTP, pointing to a server that is based on some time standard like GPS, is a viable solution. For them the problem becomes picking a time server they trust to be right...

    • Re: (Score:2)

      by Dog-Cow ( 21281 )

      If you're relying on a Tardis for accurate time, you're in for a world of pain.

      • I'm not sure if you're trying to make a Doctor Who joke, or if you don't get what I'm doing, but Tardis 2000 is just what's interpreting the serial data stream from the GPS receiver I'm using.
  • It's Y2K all over again! Horde the ammo and water! Dig your bunkers a few meters deeper! Gird your loins!?

  • tlsdate isn't a NTP replacement (Score:4, Informative)

    by plcurechax ( 247883 ) on Thursday October 22, 2015 @11:30AM (#50781851) Homepage

    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.

    • Not only that but:

      TLS 1.3 and tlsdate

      In the upcoming version of TLS, tlsdate might not function anymore.

  • "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!
  • 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 [bu.edu] 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'

Slashdot Top Deals

Be sociable. Speak to the person next to you in the unemployment line tomorrow.

Close