#y2k38

Born to early for 64-bit Unix time overflow

About the mod:

I want to compile a list of things I find that are vulnerable to the Y2K38 bug. If you find any I don't know about, I can add them to the list. But first, an explanation...

What is Y2K38?

For those that aren't aware, past January 19, 2038 at 3:14:07 UTC (2038-01-19T03:14:07Z), the number of seconds since midnight of January 1, 1970 (1970-01-01T00:00:00Z) will surpass 2^31 - 1.

So what are the implications of this? It has to do with how computers store time.

The Unix epoch is defined as the number of seconds since January 1, 1970, and this is universal to both Unix and Windows systems (so virtually every single computer that doesn't have a homemade operating system). The issue is what specific types of numbers are used to store the epoch.

There are two properties to an integer type: size and sign. The size dictates how many bits a number can hold, and the sign dictates whether or not the integer can store negative numbers. If the number is unsigned, it will be able to store numbers ranging from zero to 2^n - 1, where n is the size of the integer in bits. This means that an 8-bit unsigned number can hold numbers ranging from 0 to 255, because 2^8 - 1 is 255. If a number is signed, the positive range is cut in half. Signed numbers range from -2^(n - 1) to 2^(n - 1) - 1. This means that an 8-bit signed integer can hold numbers ranging from -128 to 127, as -2^7 is -128, and 2^7 - 1 is 127. As integers are used to store the Unix epoch, this means that the epoch is limited to the range of the integer type you use to store it.

If you decide to use a 32-bit signed integer to store the Unix epoch, then once the epoch reaches 2^31 - 1 (which is the upper limit of 32-bit signed integers and is around 2.1 billion), the epoch won't be able to increase anymore. So what happens when we try to increase it anyways? We get an integer overflow.

Due to how CPUs add numbers together, when the result of an operation is larger than the range of the integer type, the result is wrapped around. For example, if you have the number 127 in an 8-bit signed integer, adding one will wrap around to -128! This is a problem for the epoch, because now, instead of storing 2.1 billion seconds past January 1, 1970, it will now be storing 2.1 billion seconds before 1970, which goes all the way back to December 1901!

So why not just use a bigger number? Well, it's not really that simple. There has been an effort to switch over to 64-bit integers, which has an overwhelmingly generous range of around 21 times the estimated age of the universe. However, there are some systems that just can't change or haven't changed for a variety of reasons, and this is what the list will be about. There are two main causes for the Y2K38 bug, and most vulnerabilities stem from them:

32-bit representation of of time_t: time_t is the integer type that time is stored in. When a C program calls the time() function, it will receive a time_t. If time_t is 32-bits long, then the time() function will be vulnerable.

Downcasting the result of time(): There's a pattern in programming I like to call "int-defaultness". C's primitive types are not named with sizes. Instead, they are called 'char', 'short', 'int', and 'long'. These types are standardised to be at least 8 bits, 16 bits, 32 bits, and 64 bits respectively, but most platforms just use those sizes exactly. Usually, you would use exact-sized types like int16_t, uint64_t, and so on, or if it's a function like time(), you would use time_t. However, it is a common pattern to default to int as an integer type, and someone who isn't careful may just convert the result of the time() function into an int. This is known as downcasting, which is the conversion from one integer type to a smaller one. Regardless of whether or not time_t is 32 bits or 64 bits, this downcast will always convert the time to 32 bits, and the overflow behaviour will apply, leaving PHP vulnerable.

As you can see, the time() function is the root cause of the bug, and due to its popularity, usages and mimics of time() can be left vulnerable.

So, without further ado, here is...

The List of Vulnerabilities

PHP time() function: PHP has a time() function that acts very similar to C's, and if the size of a PHP int is 32 bits, PHP is left vulnerable.

pcap file format: The pcap file format (used by libpcap, which is used by utilities like tcpdump and Wireshark) is a format for storing captured packets, and the specification states that the timestamps of packets must stored in a 32-bit unsigned integer. Luckily, since it is unsigned, this will overflow in the year 2106, but there is still some vulnerability here. The PcapNG file format uses 64-bit timestamps, which prevents the vulnerability.

"ah, well, there's scheduled to be an issue in 2038 about timekeeping"

"Oh?"

"Yeah, you know how we track time by counting the number of seconds since 1970?"

"Huh--?"

"And how we usually use numbers that break when you hit just above 2 billion?"

"Wh-- uh--"