[krbdev.mit.edu #9033] Bug report: warn_pw_expiry() wrongfully warns of coming expiration when krbPasswordExpiration is in at least 68.09 years

[Félix-Antoine Fortin via RT]

Wed Oct 06 11:42:56 2021: Request 9033 was acted upon.
 Transaction: Ticket created by felix-antoine.fortin at calculquebec.ca
       Queue: krb5
     Subject: Bug report: warn_pw_expiry() wrongfully warns of coming expiration when krbPasswordExpiration is in at least 68.09 years
       Owner: Nobody
  Requestors: felix-antoine.fortin at calculquebec.ca
      Status: new
 Ticket <URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9033 >


Hi,

While tinkering with krbPasswordExpiration setting in FreeIPA, I stumbled
on a corner case where calling kinit would output the following warning:

$ kinit admin
Password for admin at INT.HOSTNAME.TLD:
Warning: Your password will expire in less than one hour on Fri 05 Oct
2096 12:00:00 AM UTC

The admin krbPasswordExpiration is effectively set to 05 Oct 2096 12:00:00
AM UTC or in epoch: 4000233600, while the current date was 05 Oct 2021
13:58:00 AM UTC or in epoch : 1633442336.

The problem happens here:
https://github.com/krb5/krb5/blob/371f09d4bf4ca0c7ba15c5ef909bc35307ed9cc3/src/lib/krb5/krb/get_in_tkt.c#L1568

warn_pw_expiry() computes the difference between the expiration date and
now using ts_delta. Since ts_delta returns a signed 32 bits integer, the
highest difference that can be correctly represented between a future date
and now is 2147483648 seconds (~68.09 years). Beyond that, ts_delta returns
a negative number, and warn_pw_expiry() warns the password is about to
expire since it is smaller to 3600 seconds.

When the delta is computed, warn_pw_expiry() is already aware that the
password is not expired, otherwise the expiration callback would have been
called. Hence, we know the timestamp difference has to be strictly
positive. Therefore, the first if could be rewritten as:

if (delta > 0 && delta < 3600) {

Reference:
https://github.com/krb5/krb5/blob/371f09d4bf4ca0c7ba15c5ef909bc35307ed9cc3/src/lib/krb5/krb/get_in_tkt.c#L1569

I realize this is a corner case, so it might not be desirable to fix the
logic, but if the logic is not fixed, a maximum value
for krbPasswordExpiration should probably be documented somewhere, which is
why I am reporting this.


--
Félix-Antoine Fortin
Université Laval