On Thu, Jan 06, 2022 at 08:38:37AM +0100, Otto Moerbeek wrote:
> On Wed, Jan 05, 2022 at 02:19:28PM -0700, Theo de Raadt wrote:
>
> > Otto Moerbeek <[email protected]> wrote:
> >
> > > On Wed, Jan 05, 2022 at 11:45:36AM +0100, Matthias Schmidt wrote:
> > >
> > > > >Synopsis: ntpd constraint validation shows timestamp from 1899
> > > > >Environment:
> > > > System : OpenBSD 7.0
> > > > Details : OpenBSD 7.0-current (GENERIC.MP) #216: Mon Jan 3
> > > > 16:04:47 MST 2022
> > > >
> > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > >
> > > > Architecture: OpenBSD.amd64
> > > > Machine : amd64
> > > > >Description:
> > > >
> > > > Yesterday, the following log message from OpenNTPD appeared for the
> > > > first and
> > > > only time in my logs:
> > > >
> > > > Jan 4 19:35:04 sigma ntpd[72304]: maximum length exceeded
> > > > Jan 4 19:35:04 sigma ntpd[72304]: tls certificate not yet valid:
> > > > 9.9.9.9 (9.9.9.9): not before 2021-07-27 00:00:00 UTC, now 1899-12-31
> > > > 00:00:00 UTC
> > > >
> > > > It seems like some hiccup during constraint TLS certificate validation.
> > > >
> > > > Here are the log messages of the last two minutes BEFORE the lines above
> > > > appeared:
> > > >
> > > > Jan 4 19:33:08 sigma ntpd[65131]: peer 134.76.249.201 now invalid
> > > > Jan 4 19:33:16 sigma ntpd[65131]: peer 141.2.22.74 now invalid
> > > > Jan 4 19:33:20 sigma ntpd[2066]: adjusting local clock by 0.468916s
> > > > Jan 4 19:33:20 sigma ntpd[65131]: clock is now unsynced
> > > > Jan 4 19:34:04 sigma ntpd[65131]: peer 134.76.249.201 now valid
> > > > Jan 4 19:34:22 sigma ntpd[2066]: adjusting local clock by 0.153686s
> > > > Jan 4 19:34:26 sigma ntpd[65131]: peer 134.76.249.201 now invalid
> > > > Jan 4 19:34:54 sigma ntpd[65131]: clock is now synced
> > > > Jan 4 19:34:54 sigma ntpd[65131]: constraint reply from
> > > > 82.165.229.152: offset -0.891146
> > > > Jan 4 19:35:00 sigma ntpd[65131]: constraint reply from 82.165.229.87:
> > > > offset -0.776174
> > > >
> > > > The next time 9.9.9.9 appeared in the logs was around 15 minutes later:
> > > >
> > > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 2620:fe::fe:
> > > > offset -0.848819
> > > > Jan 4 19:50:43 sigma ntpd[65131]: constraint reply from 9.9.9.9:
> > > > offset -0.872381
> > >
> > > The 1899 time is the time taken from the http reply headers received.
> > > I suppose quad9 had a hickup and sent garbage. Likely the strptime()
> > > call in ntpd/constraint.c went wrong but did not return an error in
> > > some way. The answer to this contraint request was rejected. Other
> > > constraints worked apparantly and after a while quad9 was reporting a
> > > correct time in its http reply headers.
> >
> > So in other words, the code worked precisely as intended. The constraint
> > timestamp was not consumed, and the alert is simply amusing.
> >
>
> Yep.
>
> Looking at the loop again and seeing the "maximum length exceeded" I
> think what has happened is that the loop exited without reading the
> Date: line and so no call to strptime() happened at all.
>
> The code could be improved a bit by returning -1 in that case.
>
> -Otto
>
Like this
Index: constraint.c
===================================================================
RCS file: /cvs/src/usr.sbin/ntpd/constraint.c,v
retrieving revision 1.52
diff -u -p -r1.52 constraint.c
--- constraint.c 16 Jul 2021 13:59:10 -0000 1.52
+++ constraint.c 6 Jan 2022 07:43:52 -0000
@@ -1019,7 +1019,7 @@ httpsdate_request(struct httpsdate *http
&httpsdate->tls_tm) == NULL) {
log_warnx("unsupported date format");
free(line);
- return (-1);
+ goto fail;
}
free(line);
@@ -1027,6 +1027,8 @@ httpsdate_request(struct httpsdate *http
next:
free(line);
}
+ if (httpsdate->tls_tm.tm_year == 0)
+ goto fail;
/*
* Now manually check the validity of the certificate presented in the
