The Limits of Security

© February 2006 Anthony Lawrence

I was reading Challenge: How Did These Processes Get Here? recently. The contest is long over, but take a moment to think about the symptoms before reading the answer. Then pop back here; I'll wait.

Good, you are back. I found that interesting, especially Brian's analysis of why the admin didn't spot this, which was right on the money. But it also set me thinking about time stamps. Obviously we need to be able to change the system date, but secure systems try to put restrictions on that. For example, securelevel (I'm showing the BSD man page, but it has been ported to Linux also) only lets you move forward in time - you can't set the time backward.

Unfortunately, that's really not protection, because if you set it to Unix's 2038 overflow date, unpatched versions go back to the beginning of the epoch, and from there you could simply go forward to the desired date. So how do you fix that problem?

Well, the latest BSD man page for "date" shows what they did:

     Only the superuser may set the date, and if the system
     securelevel (see securelevel(8)) is greater than 1, the
     time may not be changed by more than 1 second.
 

That's pretty harsh, but it doesn't stop someone from exploiting the bug - it will just take them a bit longer. On a reasonably fast machine, you might be able to iterate through a few minutes of time changes each second. Let's say the machine is pretty fast and you could get it to advance an hour for each second you run: you'd need a couple of days or so before you could bump it to overflow, and of course a lot longer to bring it back to where you want it. Even if no one is looking during all this time, lots of files are going to get very strange dates as this time changing program runs - the attacker probably would need to track down and restamp all of them.

So the restriction probably does effectively squash the bug. Another approach could have been to not allow the overflow at all: when time reaches that 2038 date, it just freezes there, never to advance again. Yes, that would "break" any system still running in 2038, but wouldn't they be just as broken if they overflowed? I think so. However, there may be other security advantages to the "1 second rule" that I haven't thought of.

Some security problems are simply very difficult to solve.

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us