linux-kernel - Preventing 32-bit time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150409164548.GP32271@localhost>
Date:	Thu, 9 Apr 2015 18:45:49 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Preventing 32-bit time_t overflow

I did a test to see what happens on a system when 32-bit time_t
overflows. While the kernel seems to continue running without big
problems and it's possible to set the clock back to a time before the
overflow, some applications are not so good, they are burning CPU, the
system log is getting filled, it looks like an admin's nightmare.

I'm not sure how many of them are bugs in math with time_t and how
many are due to unexpected results from system calls like setting
timers with the ABSTIME flag to time before 1970, but I think it would
be pretty unrealistic to expect all applications to be able to handle
all the problems that can happen when time_t overflows or is close to
the overflow.

The trouble is this can be exploited with unauthenticated NTP or PTP.
With a spoofed reply the clock can be set close to the overflow. Some
NTP/PTP implementations don't allow (large) steps after the initial
synchronization, so a system that's already running with good time
might be safe, but there are some implementations where the clock can
be set to any value at any time. Also, a lot of people are running
ntpdate or similar from cron.

I'm wondering if this is something that would make sense to address
in the kernel, at least for now.

I was thinking about reserving an interval (e.g. month or year) before
the overflow where the time would be considered invalid and the clock
couldn't be set to it. In the time accumulation would be a check
if the time is still valid and if not, the clock would be set back by
day, month or year as if adjtimex(ADJ_SETOFFSET) was called, so the
overflow never actually happens and there is always some room for
calculations around current time. It could be configurable, to allow
people to test the kernel and applications for the overflow.

What do you think?

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/