Hacker News Reader

Comment by subway | Hacker News Reader

I wonder if it would be possible to walk back the date using an ntp mitm attack.

Very, very difficult, unless the host relies on a single timesource. Best and common practice is to use 3-4 sources from different organizations in the ISC pool. It also wouldn't surprise me if most implementations of ntpd would have further safeguards about going 40 years back in time; at the very least the skew factor would make the clock change take a longgggg time to happen.

There are much easier attack vectors.

It doesn't matter how many time sources there are. If you're doing an MITM attack, it's just as easy to fake multiple sources as it is to fake one.

This isn't always true: it all depends on where you [the attacker] are. If you've done something like compromise part of a large organization's network, it's entirely plausible that you could spoof either their internal NTP server or time.apple.com but not both.

Actually I had to write a ntp spoofer for an university class. With arpspoof it is easy to manipulate all ntp traffic. At least ntpdate didn't complain when you sent it some years forward or backward.

ntpdate won't complain because it's entire purpose is to set the time on a system that isn't synchronized with the rest of the world. So it is expected that the clock may have drifted by a substantial amount, and it is only meant to be used occasionally. It is especially bad practice to run it from cron.

On the other hand, ntpd is a daemon that is meant to be run continuously. It will complain if lower-strata time servers start jumping around, and has a built-in mechanism for ignoring time servers that seem to be giving incorrect time (compared to both other servers and the system's own idea of the current time). Note that, if having accurate time is important, ntpd also supports using external reference clocks with a pulse-per second connected to, for example, a serial port.

       -g      Normally, ntpd exits with a message to the system  log  if  the  offset  exceeds  the  panic
               threshold,  which  is  1000 s by default. This option allows the time to be set to any value
               without restriction; however, this can happen only once. If the threshold is exceeded  after
               that,  ntpd  will exit with a message to the system log. This option can be used with the -q
               and -x options. See the tinker command for other options.

It won't. An NTP client will refuse to update it's system clock back to Epoch. There's a threshold after which ntpdate will refuse to adjust the clock.

No, ntpd adjusts the skew, not the actual time. NTP is specifically designed to prevent time from going backwards because that can cause all sorts of problems with tons of software. It only slows down and speeds up the clock to keep it in sync.

Reply on news.ycombinator.com