[stuff about setting file timestamps]
>This is why BSD/OS since version 3.0 disallows setting the clock
>backwards when running at normal securelevel. I think more operating
>systems need that feature. Subverting timestamps in this environments
>becomes much harder.
Not really. Granted, the following is from a Linux box, not a
secureleveled BSD one, but it illustrates the principle:
-=-=-=-=-=-=-=-
crystal:/tmp# cat settime.c
#include <stdlib.h>
#include <unistd.h>
#include <sys/time.h>
int main()
{
struct timeval tv, now;
gettimeofday(&now, NULL);
tv.tv_sec = 0x7FFFFFF8;
tv.tv_usec = 0;
settimeofday(&tv, NULL);
system("date");
sleep(15);
system("date");
now.tv_sec += 14; /* less than we slept for */
settimeofday(&now, NULL);
system("date");
return 0;
}
crystal:/tmp# cc settime.c -o settime
crystal:/tmp# ./settime
Mon Jan 18 22:14:00 EST 2038
Fri Dec 13 15:45:59 EST 1901
Sun Aug 30 00:39:14 EDT 1998
crystal:/tmp#
-=-=-=-=-=-=-=-
In other words, if you can't manually set the clock back, get the
system to do it for you. And if the system doesn't allow the clock to
"turn over", then all sorts of things will go bonkers when the clock hits
its maximum (cron jobs, for one), turning this into a DoS of sorts. So I
don't see this as a particularly effective measure. One way I could see to
make this more effective would be to use 64-bit times and disallow both
setting the clock back and changing the top 2 bits to anything other than
zero. This would break the rollover attack without causing any premature
Y2k-like problems (2^62 seconds ~= 10^13 years).
--Andy Church | If Bell Atlantic really is the heart
achurchat_private | of communication, then it desperately
www.dragonfire.net/~achurch/ | needs a quadruple bypass.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:12 PDT