The Limits of Security

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.

Take Control of Sharing Files in Snow Leopard

Take Control of Exploring & Customizing Snow Leopard

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.