ntpdate vs. xntpd

[Peng Lu]

Hi there,

I've read from some security audit report (can't recall the exact location) that there's a security vulnerability in xntpd (buffer overflow). As such, it is recommended to use ntpdate instead of xntpd if you only want to be a client. I'm not too sure how true it is. Any one knows more detail?

Cheers,
Peng

[Sridhar Bhaskarla]

Hi Peng,

You can use both xntpd as a daemon and ntpdate as a cronjob to synchorinize the local clock. However, you will need to note the following

//
It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does xntpd, the accuracy using ntpdate is limited.
//

The above is from the man page. Look at the man page of ntpdate and xntpd for more information.

-Sri

[Andrew Cowan]

Hi Peng,

I think that the thinking here is that since xntpd is a continuously running service, its more vulnerable than a one-off ntpdate request that could run at any time. I haven't heard of any particular buffer overflow problem, and if one exists, I imagine HP will simply issue a patch.
Normally when ntp is attacked it simply generates a clock-insane error and stops sync'ing, or it can try to check one timesource with serveral others, and then decide which one's are likely to be right. Remember if all fails your system's internal clock should keep reasonably good time until ntp is fixed.

I think the question you should be asking is how accurate/in-sync do I need my clocks to be? If the answer is they need to be very close due to something like Kerberos, then use xnptd, if they could drift a little without causing a problem, use ntpdate. Also if you use ntpdate then there's a little less networking traffic.

[Robert-Jan Goossens]

Hi Peng,

Are you revering to this Denial of service.

http://secunia.com/advisories/7701/?show_all_related=1

It has been solved with a patch.

HP-UX 11.00: PHNE_27223
HP-UX 11.11: PHNE_24512

Hope this helps,
Robert-Jan

[Peng Lu]

Hi,

Thanks to all who replied to my post.

I managed to find out the location of that document mentioned about xntpd buffer-overflow vulnerability. It is at "http://www.nortelnetworks.com/solutions/securenet/collateral/hp-ux_hardening_guide_v1.pdf". It's a system hardening guideline document produced by someone in Nortel. It appears to be on HP-UX 11 although it doesn't give out details about the vulnerability. (I'm working on 11.11)

I think I'll stick with xntpd as all my servers (they will use a dedicated NTP server over internal network) are behind firewall and it blocks access to port 123 from any external sources.

Thanks again.
Peng

[Trevor Dyson]

xntpd is intended to skew the clock gradually over a period of time to minimise the impact of time changes on applications (especially databases)

ntpdate changes the clock in one action and is really intened to be used to sync the time at boot time.