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.
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.
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.
-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.
There are much easier attack vectors.