January 19, 2038 : next Millennium bug ?

XavierBens · ‎2018-02-05

Hi, a recent product alert (sk122612‌) highlights a problematic which will impact all unix systems in twenty years : we will have reached 2^31 seconds since epoch (January 1, 1970 midnight).

Off course Check Point products and pre-R77.30 Jumbo HF Take_143 are concerned as gaia is UNIX based.

Due to this, Check Point is setting the certificate expiration date to be equal to the maximum Unix epoch time.

Do you know if there is a global reflection of the community regarding this limitation ?

Cybersecurity Evangelist, CISSP, CCSP, CCSM Elite

PhoneBoy · ‎2018-02-10

Not sure I understand the exact question.

In general, I expect this Unix epoch issue will impact MANY things, far more than the Y2K bug did.

XavierBens · ‎2018-02-11

Yes you've alright : MANY things.

I just wanted to initiate the conversation ; since this message I understood that 64bits counters fix the issue.

Cybersecurity Evangelist, CISSP, CCSP, CCSM Elite

Bob_Zimmerman · ‎2026-01-30

Looks like R82.10 switches to 64-bit time_t, which is the biggest step towards addressing the 2038 issue:

[Expert@SomeFirewall]# cpinfo -y fw1

This is Check Point CPinfo Build 914000224 for GAIA
[FW1]
	HOTFIX_INEXT_NANO_EGG_AUTOUPDATE
	HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE
	HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE
	HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE
	HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE
	HOTFIX_UCA_INFRA_AUTOUPDATE
	HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
	HOTFIX_GOT_TPCONF_AUTOUPDATE

FW1 build number:
This is Check Point's software version R82.10 - Build 767
kernel: R82.10 - Build 768

[Expert@SomeFirewall]# date +%s -d"Jan 19, 2038 03:14:07Z"
2147483647

[Expert@SomeFirewall]# date +%s -d"Jan 19, 2038 03:14:08Z"
2147483648

[Expert@SomeFirewall]# date +%s -d"Jan 19, 20380 03:14:08Z"
580965016448

Are you a member of CheckMates?

January 19, 2038 : next Millennium bug ?