Hi,
                                                                                                                  
There was an security problem (ntpd internal overflow CERT vu#584606) with setting dates on an NTP client, when the difference between the client and server is more than 34 years. ntpdate used to set time wrongly on the client side; the problem is solved with NTPv4 version of ntpdate.
                                                                                                                  
Now, ntpd 'usually' quits if the time difference is more than 1000 seconds (roughly 20 minutes); however, if ntpd
is started with the -g option, even that sets time wrongly on the client side!(?) Ideally, the user should run ntpdate before running ntpd, but we believe there *is* a problem for ntpd as well (even with the latest 4.2.0 release).
                                                                                                                  
We have tested this on linux/tru64 implementations. Please confirm whether this is seen as a potential security issue and whether this problem is already acknowledged by ntp.org and being worked upon?
                                                                                                                  
Thanks & Regards,
Vishal

Vishal Agarwal wrote:
> Hi,
>                                                                                                                   
> There was an security problem (ntpd internal overflow CERT vu#584606) with setting dates on an NTP client, when the difference between the client and server is more than 34 years. ntpdate used to set time wrongly on the client side; the problem is solved with NTPv4 version of ntpdate.
>                                                                                                                   
> Now, ntpd 'usually' quits if the time difference is more than 1000 seconds (roughly 20 minutes); however, if ntpd
> is started with the -g option, even that sets time wrongly on the client side!(?) Ideally, the user should run ntpdate before running ntpd, but we believe there *is* a problem for ntpd as well (even with the latest 4.2.0 release).
>                                                                                                                   
> We have tested this on linux/tru64 implementations. Please confirm whether this is seen as a potential security issue and whether this problem is already acknowledged by ntp.org and being worked upon?
>                                                                                                                   
> Thanks & Regards,
> Vishal
> 

That is correct and known and as designed. However, when using the '-g'
option, you should not run ntpdate first. That is the purpose of the -g,
to eliminate the need to run ntpdate first. And as you noted, ntpdate has
the same overflow problem. This is not a problem with these programs, it
is the limitation in the protocol itself. To quote the docs at ntp.org:


....it is necessary to set the system clock within 34 years of the current UTC
time before the protocol is started.

-- 
blu

It is bafflingly paradoxical that the United States is by far the world's
leading scientific nation while simultaneously housing the most scientifically
illiterate populace outside the Third World. - Richard Dawkins
--------------------------------------------------------------------------------
Brian Utterback - OP/N1 Revenue Product Engineering, Sun Microsystems, Inc.
Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom

Vishal,

I take it you have carefully read the CERT advisory, which I submitted.
See the NTP project page and the two pages NTP timescale calculations
and NTP era and era numbering. That should answer all your concerns.

Be advised the 34-year issue is not a problem, but an inherent factor in
the design specific to the NTP timestamp calculations. As described in
the timestamp calculation page, the most recent ntpd has been modified
so that the non-ambiguity window has been extended from 34 years to 68
years. This is not a generic solution and results only from the fact
that ntpd does almost all calcuations in floating-double.

That has not been done for xntpd or ntpdate. The hazard continutes for
those programs, which I consider obsolete. It's even more serious with
xntpd, as I have pointed out before.

The bottom line is that users must insure the system clock is set within
34 years of the actual time with xntpd and ntpdate and within 68 years
with ntpd.

Dave

Vishal Agarwal wrote:
> 
> Hi,
> 
> There was an security problem (ntpd internal overflow CERT vu#584606) with setting dates on an NTP client, when the difference between the client and server is more than 34 years. ntpdate used to set time wrongly on the client side; the problem is solved with NTPv4 version of ntpdate.
> 
> Now, ntpd 'usually' quits if the time difference is more than 1000 seconds (roughly 20 minutes); however, if ntpd
> is started with the -g option, even that sets time wrongly on the client side!(?) Ideally, the user should run ntpdate before running ntpd, but we believe there *is* a problem for ntpd as well (even with the latest 4.2.0 release).
> 
> We have tested this on linux/tru64 implementations. Please confirm whether this is seen as a potential security issue and whether this problem is already acknowledged by ntp.org and being worked upon?
> 
> Thanks & Regards,
> Vishal

I believe Dave Mills has stated that a functional requirement of ntp is
that the time be correct to within 34 years before starting ntpd.

ntpdate is worse than suboptimal and its use should be phased out.

H
--
In article <mailman.210.1084448885.1757.questions@ntp.org>,
Vishal Agarwal  <avishal@india.hp.com> wrote:
>Hi,
>                                                                        
>
>There was an security problem (ntpd internal overflow CERT vu#584606)
>with setting dates on an NTP client, when the difference between the
>client and server is more than 34 years. ntpdate used to set time
>wrongly on the client side; the problem is solved with NTPv4 version of
>ntpdate.
>                                                                        
>
>Now, ntpd 'usually' quits if the time difference is more than 1000
>seconds (roughly 20 minutes); however, if ntpd
>is started with the -g option, even that sets time wrongly on the client
>side!(?) Ideally, the user should run ntpdate before running ntpd, but
>we believe there *is* a problem for ntpd as well (even with the latest
>4.2.0 release).
>                                                                        
>
>We have tested this on linux/tru64 implementations. Please confirm
>whether this is seen as a potential security issue and whether this
>problem is already acknowledged by ntp.org and being worked upon?
>                                                                        
>
>Thanks & Regards,
>Vishal
>

On Thu, 13 May 2004 19:18:03 +0000 (UTC), stenn@maccarony.ntp.org
(Harlan Stenn) wrote:

>I believe Dave Mills has stated that a functional requirement of ntp is
>that the time be correct to within 34 years before starting ntpd.
>
>ntpdate is worse than suboptimal and its use should be phased out.
>
>H
Hi Harlan -

I've read that the current NTPD can be a functional replacement for
NTPDATE, by setting certain flags so that it converges quickly and
then quits (after sync).  

Would it be possible to create a new, small NTPDATE program for v4.2
(or 4.3) that simply invokes the NTPD module with the appropriate
flags, so users with existing NTPDATE calls in their scripts would
continue to function correctly, without using the old, deprecated
NTPDATE or having to make changes to the rest of their systems?

- Eric
 

The short script is:

 #! /bin/sh
 ntpd -q

(As I understand it).

It gets more difficult if somebody wants to handle all of the other options.

A volunteer would be appreciated, and it is probably better to simply
fix the startup scrupts.

H
--
In article <c0h9a0td7ogp818otigdlhvctgb3uu45mu@4ax.com>,
Eric  <ejensen@spamcop.net> wrote:
>Would it be possible to create a new, small NTPDATE program for v4.2
>(or 4.3) that simply invokes the NTPD module with the appropriate
>flags, so users with existing NTPDATE calls in their scripts would
>continue to function correctly, without using the old, deprecated
>NTPDATE or having to make changes to the rest of their systems?

Eric <ejensen@spamcop.net> wrote in message news:<c0h9a0td7ogp818otigdlhvctgb3uu45mu@4ax.com>...
> On Thu, 13 May 2004 19:18:03 +0000 (UTC), stenn@maccarony.ntp.org
> (Harlan Stenn) wrote:
> 
> >I believe Dave Mills has stated that a functional requirement of ntp is
> >that the time be correct to within 34 years before starting ntpd.
> >
> >ntpdate is worse than suboptimal and its use should be phased out.
> >
> >H
> Hi Harlan -
> 
> I've read that the current NTPD can be a functional replacement for
> NTPDATE, by setting certain flags so that it converges quickly and
> then quits (after sync).  
> 
> Would it be possible to create a new, small NTPDATE program for v4.2
> (or 4.3) that simply invokes the NTPD module with the appropriate
> flags, so users with existing NTPDATE calls in their scripts would
> continue to function correctly, without using the old, deprecated
> NTPDATE or having to make changes to the rest of their systems?
> 
> - Eric

No. There is no need for it. If people don't want to take it out of
their scripts then they can always use an old version. There will be
no support for this. with the advent of ntpd -g there is no reason
at all to have ntpdate in the scripts.

Danny

Vishal Agarwal <avishal@india.hp.com> wrote in message news:<mailman.210.1084448885.1757.questions@ntp.org>...
> Hi,
>                                                                                                                   
> There was an security problem (ntpd internal overflow CERT vu#584606) with setting dates on an NTP client, when the difference between the client and server is more than 34 years. ntpdate used to set time wrongly on the client side; the problem is solved with NTPv4 version of ntpdate.
>                                                                                                                   
> Now, ntpd 'usually' quits if the time difference is more than 1000 seconds (roughly 20 minutes); however, if ntpd
> is started with the -g option, even that sets time wrongly on the client side!(?) Ideally, the user should run ntpdate before running ntpd, but we believe there *is* a problem for ntpd as well (even with the latest 4.2.0 release).
>                                                                                                                   
> We have tested this on linux/tru64 implementations. Please confirm whether this is seen as a potential security issue and whether this problem is already acknowledged by ntp.org and being worked upon?
>                                                                                
If you have any security issues please file a bug report in bugzilla.
This forum is not the place to address the issue. It can be discussed
here but
don't expect resolution here.

Danny

                                    
> Thanks & Regards,
> Vishal

Danny,

With due respect, wrong answer. I make no advice on sending to bugzy,
which is probably a good idea; but, if I am to see and help resolve
security issues, better copy the list or me at mills@udel.edu, since I
don't read bugzy. Another reason to post on this list is the archives.
Not everybody knows about bugzy and how to search its archives.

If somebody discovers a real security problem, like the stack hazard
awhile ago, they should follow CERT procedures. The case here is nothing
like that. It's really an operational limitation I should have predicted
and given advance notice. The fact the CERT was involved at all was
because I thought the best action to holler from the rooftops before
750,000 home routers plunged the century to chaos.

Dave

Danny Mayer wrote:
> 
> Vishal Agarwal <avishal@india.hp.com> wrote in message news:<mailman.210.1084448885.1757.questions@ntp.org>...
> > Hi,
> >
> > There was an security problem (ntpd internal overflow CERT vu#584606) with setting dates on an NTP client, when the difference between the client and server is more than 34 years. ntpdate used to set time wrongly on the client side; the problem is solved with NTPv4 version of ntpdate.
> >
> > Now, ntpd 'usually' quits if the time difference is more than 1000 seconds (roughly 20 minutes); however, if ntpd
> > is started with the -g option, even that sets time wrongly on the client side!(?) Ideally, the user should run ntpdate before running ntpd, but we believe there *is* a problem for ntpd as well (even with the latest 4.2.0 release).
> >
> > We have tested this on linux/tru64 implementations. Please confirm whether this is seen as a potential security issue and whether this problem is already acknowledged by ntp.org and being worked upon?
> >
> If you have any security issues please file a bug report in bugzilla.
> This forum is not the place to address the issue. It can be discussed
> here but
> don't expect resolution here.
> 
> Danny
> 
> 
> > Thanks & Regards,
> > Vishal

"David L. Mills" <mills@udel.edu> wrote in message news:<40AABBA2.FCD0A4C3@udel.edu>...
> Danny,
> 
> With due respect, wrong answer. I make no advice on sending to bugzy,
> which is probably a good idea; but, if I am to see and help resolve
> security issues, better copy the list or me at mills@udel.edu, since I
> don't read bugzy. Another reason to post on this list is the archives.

I would always want you to be involved on any discussion and solution.
It's just not a good tracking mechanism to put it here. 


> Not everybody knows about bugzy and how to search its archives.
> 
> If somebody discovers a real security problem, like the stack hazard
> awhile ago, they should follow CERT procedures. The case here is nothing
> like that. It's really an operational limitation I should have predicted
> and given advance notice. The fact the CERT was involved at all was
> because I thought the best action to holler from the rooftops before
> 750,000 home routers plunged the century to chaos.
> 

Agreed. CERT will always be certain to contact you for notification and
resolution. It's probably the best mechanism.

Danny

> Dave
>