[ntp:hackers] Release fixing all issues
mlichvar at redhat.com
Thu Jan 21 16:55:03 UTC 2016
On Thu, Jan 21, 2016 at 09:51:49AM +0000, Harlan Stenn wrote:
> > 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.
> There are 2 things going on in that paragraph I don't fully understand.
> First, what is this "valid use case" that is apparently being broken by
> a security update?
Starting ntpd with a large offset and LOCAL driver specified in the
> > 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.
> I disagree with you here, in part. With our patch, the panic gate is
> reset quickly. That means a reduced window of opportunity to attack the
Yes, reduced by one update.
> With your patch, I *think* a bad guy (worst case, MITM) can feed small
> corrections to the client for an arbitrary amount of time, and then send
> an *arbitrarily large* step correction and it will be accepted.
No, if the patch is applied on 4.2.8p4, only the first update will
allow a step larger than the panic threshold. If you look at the
loopfilter code, in the FSET state (after loading driftfile) it can go
either to the default case of the (offset > 0.128) block, or the
default case of the else block, and both set allow_panic to false.
Even if a MITM attacker could delay enabling of the panic threshold by
feeding small offsets to the client, it doesn't matter, the same
can be done simply by not sending any replies to the client and delay
its first update.
More information about the hackers