r4 - 2018-04-28 - 09:58:16 - HarlanStennYou are here: NTP >  Dev Web > DevelopmentIssues > NtpVariablesAndNtpq
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

NTP Variables and ntpq

Related Topics: bug_small.png Bug #597, bug_small.png Bug #892, bug_small.png Bug #973, bug_small.png Bug #1026, ConfigurationAndAuthorizationLevelsForNtpd

Problem Summary

ntpd and ntpq exchange system, peer, clock and flash data.

Over the years the lists of these variables have changed from time to time.

When ntpq compiled with one 'release' of these values is run against ntpd compiled with a different 'release' of these values the data can be incorrectly decoded.

Possible Solutions

Versioned headers

In this case, if we need to change the names or strings or add/delete entries we do it with some sort of version bump. I'd expect that we'd have something like

 
  include/ntp_varsX.h
(where X is a version number)

and ntpd/ntp_control.c will #include the latest rev, and ntpq will #include and decode them all.

 

On-the-fly decoding

FrankKardel notes the varible list can be queried with by reading the sys_var_list variable:

 % ntpq -c 'rv 0 sys_var_list'
 assID=0 status=21f4 leap_none, sync_atomic/PPS, 15 events, event_peer/strat_chg,
 sys_var_list="leap,stratum,precision,rootdelay,rootdispersion,refid,reftime,poll,peer,state,offset,frequency,jitter,noise,clock,processor,system,version,stability,sys_var_list,flags,hostname,update,cert,expire,leapsec,tai,signature,ident,expire,daemon_version,settimeofday,contact,operational_status"

There are three variables: sys_var_list, peer_var_list, clock_var_list.


We would also have to get the required format definitions as well. This would entail having a sys_var_fmt variable with the formats matching the respective position in the sys_var_list variable list. Likewise for peer_var_list and clock_var_list. Then the problem is to have a static list of formats.

This is intriguing in that it would allow a common NTP control protocol with less reliance on implementation details allowing a greater chance of another implementation. Ideally, the whole control protocol should be independent of the implementation, just as the actual NTP protocol is.

BrianUtterback


I'm liking this idea more and more.

I think we'd also want to create flash_var_list and flash_var_fmt.

As far as the format list, we could also have a variable that contains the format name and a 'presentation format'.

I'm wondering if we should have sys_var_list and sys_var_fmt or if the sys_var_list 'response' should contain both the name and the presentation information.

-- HarlanStenn - 21 Aug 2007

 

Other Discussion

 

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback