[ntp:hackers] Release fixing all issues
mlichvar at redhat.com
Thu Jan 21 08:19:53 UTC 2016
On Thu, Jan 21, 2016 at 03:22:54AM +0000, Harlan Stenn wrote:
> and practically INSTANTLY see why that fix is inadequate.
> I suspect the key issue is knowing what -g is supposed to do.
> -g should allow the first *correction* to exceed the panic gate.
That doesn't seem to be how -g is described. Quoting ntpd.html:
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.
See the difference?
The trouble with enabling the panic threshold right after the first
clock update, at least in 4.2.6, is that it doesn't work well with the
LOCAL driver. If the initial offset is larger than 1000 seconds and
the first update comes from the driver (e.g. it's specified in the
config before other sources or the network comes up couple seconds
later after ntpd start), the second update (from a real source) will
cause ntpd to exit.
Allowing a large step in first two updates instead of one doesn't help
the attacker much, but breaking a valid use case would be a problem
for a security update. I know you are trying to deprecate the LOCAL
driver. There are people who still use it, for good or bad reasons.
Anyway, this applies to 4.2.6 and older. In 4.2.8 it doesn't really
matter which patch is applied. Large step would still be allowed only
on the first update as there is no case in the loopfilter for the FSET
state when offset is smaller than 0.128 second and allow_panic is set
to false in the default case.
More information about the hackers