Linux Running Out of Time 

Remember Y2K? Yes, I am talking about the infamous time-dependent bug, which gave most of us sleepless nights, let alone enjoy the arrival of the new millennium. But thankfully it didn't result in as major a problem as expected, probably because everyone became very conscious and handled it very well. But ask for wisdom and strength and God gives you more problems to solve! So now there is another bug to create chaos, and this time it's targeting Linux users-the 'Year 2038' bug. 

What is the 2038 *nix bug?



Most UNIX, Linux and other *nix based OSs are written in ANSI C language. And if you are a C programmer, you probably know that in C we use a 32-bit data type 'time_t' which stores time, and the mechanism for doing this is very simple. It converts the complete date into seconds and saves the value into it. The time starts from 1st Jan 1970 00:00 Hrs GMT. This means according to the counter, the value of 1st Jan 1970 1:00 AM will be saved as '3600' into the variable. 

Since time_t is a 32-bit data type, it has 32 memory units each of which can have a value of either 0 or 1. As the first bit is used for storing whether the value is negative or positive, we're left with 31 bits. The maximum value a 31-bit variable can take is 231 — 1, which is equal to '2147483648', meaning that the data type can store 2,147,483,648 seconds starting from 1st Jan 1970 00:00 Hrs. This means that the

approximate number of years it can store is 2147483648 / (60 * 60 * 24 * 356), which is equal to around 68 years. Add 68 years to 1970 and you get 2038. So in the year 2038, the 'time_t' data type won't be able to store more data and will thus fall back to zero.

How dangerous is it? 



This will obviously lead to many problems. To give you an idea of how dangerous it can be, let's do a test. Don't do it on a production system, because the output of this test will crash the GNOME environment. Go to your Linux machine, restart it and enter the BIOS. Set the time to anything

beyond 2038, save and restart the machine. When your Linux machine starts up, you will find that GNOME refuses to start up and will show some error messages, including problems of nautilus, xscreensaver and gnome-panel. If you move out to the command line and run the 'top' command, you will find that some of the applications such as xscreensaver have gone into an

infinite loop and occupy the full processing power. If a single simple desktop machine that isn't running any mission-critical applications can crash like this, imagine what can happen to enterprise applications ! It sounds scary, but probably by 2038, most implementations would have moved to 64-bit versions of various *nixs, where this problem doesn't exist. But those who don't migrate will have to find a solution. Just because 2038 is still far away doesn't mean you don't need to do anything about it today. Think of all the devices that are embedded with Linux, such as firewalls, IDSs and various other security appliances. If a hacker manages to get into any of these devices and simply changes their date to 2038, the devices will start malfunctioning. Or what if somebody sends out a spam mail with malicious code that generates a fake time stamp of the year 2038? This could cause a Linux mail server to crash. 

The moment you change the date of your Linux system to 2038, many  applications crash and messages like the ones shown above pop up

So what do we do about this problem? For one, you need to ensure that your systems are protected from such threats. Secondly, if you're a developer, then use larger data types for storing dates in databases, eg using 'double data types'.

Anindya Roy