APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

The Limits of Security


Some material is very old and may be incorrect today

© 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.


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> The Limits of Security


Inexpensive and informative Apple related e-books:

Digital Sharing Crash Course

Take Control of High Sierra

Photos for Mac: A Take Control Crash Course

Take Control of Pages

iOS 10: A Take Control Crash Course





More Articles by © Anthony Lawrence



Related Articles




Printer Friendly Version


Related Articles

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


Printer Friendly Version





The three chief virtues of a programmer are: Laziness, Impatience and Hubris. (Larry Wall)




Linux posts

Troubleshooting posts


This post tagged:

Security



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode