If you switch to 64 bit timestamps, and the network protocol supports dates > 2038, can you then just trigger the rollover bugs by pretending it's 2*64 - 1 seconds after epoch start?
Also, if the actions are potentially so severe, and NTP (or whatever is used) so vulnerable, why haven't we seen many such attacks in the wild?
Update: to be clear I'm not arguing that there isn't a problem, I've already run into it myself. I'm trying to understand how severe it is, how exploitable, and how robust a solution could be.
I think many software engineers know that if you want to make any organization care about this type of issue, you need to be ready to demonstrate the severity and impact.
Even if the system boots properly, there's various critical systems that depend upon having the correct time. Say goodbye to things like HTTPS and SSL/TLS certificates.
However, I’m not sure how you make a 2038 test environment
It assumes that the OS/Kernel etc… are defacto frozen to 2025 or whatever increment until 2038
What was the y2k solution for the people that implemented those fixes in the 90s?
It intercepts system calls to get the time and reports a fake time to the application.
Y2K showed that you don't need details beyond vague threats of "medication administered at the wrong time" and "planes falling out of the air" to get organizations and the public to care. No idea how that's going to tie into the conspiracy-heavy media landscape we inhabit now.
(Note I do think this is a serious issue that needs to be addressed. And I'd love to see specific examples. I'm just pushing back against the idea that examples would make much difference to advocacy efforts)
Businesses installing new smart infrastructure and devices will need to pay attention to this, and in 10-15 years they'll need to work out what to replace, of course.
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...
Here's an example of measuring packages that report warnings for software that has suspicious conversions. Compile with `-Wconversion` with both 32-bit and 64-bit time_t, and see what the difference is. https://github.com/mkj/yocto-y2038
That is using yocto, but you could probably do something similar with other less-embedded distros too, if you can rebuild the world.
FWIW I didn't find much interesting with that apart from busybox dhcpd.
Funniest is that one of them wrote that they have "learned about it after Y2K bug". I thought one learns about this overflow in a "introduction to programming" class...
2^53 + 1 milliseconds = 9007199254740993 milliseconds = 104249991 days 8 hours 59 minutes 0.993 seconds. Since the zero point is midnight 1970-01-01, we reach the first non-representable millisecond at 287396-10-12T8:59:00.993 (be careful to use the Gregorian leap rule if you want to calculate this manually).
At least, the good part is that people will get "hunches" about y38, just like you start getting "hunches" about bugs related to locales, time zones, character encodings, currency roundings, etc...
I don't know if there are courses, books, etc... about all those matters that are definitely non "computer sciency", but occupy so much of our engineering time ?
Only 13 years left!
Maybe I should start thinking about an early retirement :)
So, ahem, your “early retirement” is assured?
A year is a lot longer than it used to be. And quickly getting longer. Measured in change.
The best thing about waiting until the last minute to fix something is it will only take a minute.
That might be imposssible right now, and not just because of the time travel thing. While it's a good idea, and while people are working to get legislation passed that would prevent the forced obsolescence of products by companies requiring, then no longer supporting, public servers, for instance, companies would fight to the death any requirement to make their source available.
But the problem isn't only theirs - open source projects that are steered by corporations often lack the willingness to expend some work now in order to save work decades from now.
For instance, NetBSD moved to 64 bit time on all platforms using clever versioning to maintain compatibility with 32 bit timestamps. They did this on 32 bit architectures, too, back in 2012. [0], [1]
Linux, on the other hand, has no shortage of people who either want to drop 32 bit support entirely or who think that the work to modernize 32 bit support isn't worthwhile (because, in part, they've forgotten that embedded Linux is a thing, and they also don't care about people who can't afford modern hardware). The 64 bit time transition for 32 bit platforms has taken ages, but is thankfully finally underway. [2]
There's practically no hope for corporations. If they aren't given stuff that's already fixed (that is, if the fix isn't already baked in to the Linux they choose to use), they're certainly not going to "invest" resources in fixing things from the past. Heck - it took Google more than a week to fix issues with Chromecasts that came from bad planning. [3]
What can we do? Most people aren't going to decide on a purchase based on whether their product might stop working in 2038 unless we make it very easy for them. We should test more things and point out when products will fail. Of course, nobody is going to care if their wifi device bought in 2025 won't run in 2038, but if someone told you that a $50,000 car's infotainment system will stop working, they might care.
[0]: https://wiki.netbsd.org/symbol_versions/
[1]: https://web.archive.org/web/20200122035908/https://twitter.c...
[2]: https://wiki.debian.org/ReleaseGoals/64bit-time
[3]: https://www.theregister.com/2025/03/13/google_chromecast_fix...
But it will be the end of time, as we know it!
Fixing Y38 will require some public spending. If "researching cancer" is not considered worthy of public spending any more, I'm curious about how the nerds will manage to justify replacing lots of embedded chips "because maths".
If it takes the usual 8 years to replace the current administration with one that accepts listening to experts, and unless big donors can make a profit by organizing the transition, we can expect serious efforts to only start around 2032 globally. No idea if that will be enough this time, we'll see...
(On the bright side, maybe they can charge customers ? That would work.)
13 years is plenty of time to make a start on all of this, and will allow the costs to be spread over that time period without undue hurry. It's also long enough that it will be possible for much software to be allowed to reach end-of-life without being audited, while applying rigorous testing to new software. Procrastination, though, is not a good option.
