[ntp:hackers] Release fixing all issues
martin.burnicki at meinberg.de
Thu Jan 21 09:50:18 UTC 2016
Miroslav Lichvar wrote:
> 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.
Correct. This has also been discussed in Bug 988, long time ago:
> 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.
As far as I can see the situation in 4.2.8 is a little bit better than
If I remember correctly then in 4.2.6 ntpd sync'ed to the local clock
very quickly, and thus the allow_panic flag was cleared before any
upstream source was accepted, even if the external source was configured
with iburst. So the only workaround was to run ntpdate before starting
ntpd, just like in the good old days. :-(
In 4.2.8 ntpd sync's to the local clock only slowly, so if an upstream
source is available there's a good chance ntpd syncronizes to the
external source first, and step the time due to -g before ntpd has a
chance to sync to the local clock.
This may still fail, though, if an external source is not reachable when
ntpd starts, e.g. because the network connection is down. I haven't
tried this, but I'd expect that ntpd would still synchronize to the
local clock, then clear the allow_panic flag, and terminate itself if
there's a large time offset when a real time source becomes reachable.
(Please note this refers to the behavior observed before any patches for
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-5300 had been applied.)
So IMO a good and easy solution would have been just to check the clock
type, and never clear allow_panic if the system peer is only the local
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
More information about the hackers