Bug 1286694 - X.509 certificate parsing handles leap years incorrectly in multiple ways.
X.509 certificate parsing handles leap years incorrectly in multiple ways.
Status: NEW
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-30 09:07 EST by Rudolf Polzer
Modified: 2015-12-01 09:55 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rudolf Polzer 2015-11-30 09:07:26 EST
Description of problem:


Decoding a date fails in the following ways:

- Feeding February xx, 2000 in an ASN1_UNITIM will actually return a date in the year 20 (i.e. anno domini twenty, not 1920/2020).
- Feeding February xx, 2001 in an ASN1_GENTIM will actually return a date in the year 21 (i.e. anno domini twenty-one, not 1921/2021).

This comes from this division by 100:


which should rather be written as:

if ((year / 100) % 4 != 0)

(BTW: I suppose here the intention of using a division by 100 instead of modulo 400 is to use both quotient and remainder from one DIV instruction)

If nothing else, this bug allows for two different ASN.1 representations of the same date (in the years 20/21), which violates the canonicality required by ASN.1 CER and thus MIGHT be exploitable in some protocols.

How reproducible:

Did not try. Found this when reading source. I suppose the way to reproduce this is creating a SSL cert dated sometime February 2000, changing your system clock back, and trying to verify it. using the kernel X.509 parser.

Such a certificate should be accepted then, but will be rejected.
Comment 1 Rudolf Polzer 2015-11-30 09:08:14 EST
Sorry, the second error case would be Februrary xx, 2100.
Comment 2 Rudolf Polzer 2015-11-30 09:50:37 EST
There also seems to be another related issue:

Feb 29, 2017 is not rejected but handled as Mar 1, 2017. The reason is incorrect leap year logic:

mon_len starts at 29:

in 0 mod 4 years, it's set to 29:

in 0 mod 100 but not 0 mod 400 years, it's set to 28:

Probably the initialization should be changed to 28. Keeping the rest of the code as is, this will do:

not 0 mod 4: 28
0 mod 100 but not 0 mod 400: 28
otherwise: 29

which is the correct rule.
Comment 3 David Howells 2015-12-01 09:51:52 EST
(In reply to Rudolf Polzer from comment #0)
> if ((year / 100) % 4 != 0)

This is the same as:

				year /= 100;
				if (year % 4 != 0)

provided one doesn't use year again - which I am, which I think is the actual problem there.
Comment 4 Rudolf Polzer 2015-12-01 09:55:43 EST
Exactly, the reuse of year in the mktime64() is what conflicts with this change of year.

Note You need to log in before you can comment on or make changes to this bug.