Potential (security) problems with System.currentTimeMillis()?

[s355171@xxxxxxxxxxxxxxxxx (Benjamin Johnston)]

I have always automatically assumed that System.currentTimeMillis() would
only increase (I didn't check, and didn't think to check). After noticing
the defined return value of this function I began to question that "fact".
System.currentTimeMillis() returns:
"the difference, measured in milliseconds, between the current time and
midnight, January 1, 1970 UTC."

I did some testing, and it turns out that this assumption was false (on the
Win32 VM distributed with JBuilder Foundation (run on Windows98)).

If the system time is adjusted backwards, System.currentTimeMillis() will
suddenly "jump" backwards.
If the system time is adjusted backwards one hour, Thread.sleep(1000) can
take an hour to execute. (It doesn't appear to be affected by setting the
clock forward though (only a limited amount of tests though)).

I haven't tried much else, but I presume wait() and various other time
related functions would have the same problem.

This seems to be, potentially, quite a problem... if the date is suddenly
changed (for daylight savings or by an attacker) then:
* javax.swing.TimerQueue could "freeze" for a length of time, or cause Timer
events to be executed out of order.
* Custom schedulers (eg. Round-robin schedulers based on Thread.sleep())
would work incorrectly for a length of time.
* Animations could suddenly reverse, jump backwards or forwards, or cause an
error (especially if the time jumps back, "before" the animation actually
began).

I'm not sure if such problems are likely to occur, but I present two purely
hypothetical exploits:

If a mission critical server regularly updates its system clock via a
network, an attacker could spoof the time-update -- forcing the server's
clock to go backwards and possibly freezing the machine (or parts of it) for
a certain amount of time.

If an large ethernet-based network uses regular UDP-broadcasts to update
system-clocks automatically (I'm not sure how realistic this situation is --
but it seems a resonable strategy to keep hundreds of local clocks
correct), then an attacker could spoof a broadcast packet that would adjust
the local time of hundreds of machines, and therefore "crash" every Swing
app
currently running on the network that makes use of javax.swing.Timer.


Any thoughts?
Have I missed any other potential problems?
Have I "rediscovered" a commonly acknowledged issue?
Or are my exploits so unlikely that they were consciously ignored in the
APIs design?

(IMHO, there should be a System.millisSinceInit() function that returns the
number of milliseconds actually passed since the VM loaded.)

-Benjamin Johnston
s355171@xxxxxxxxxxxxxxxxx




---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx