Fwd: CR 7077172 Updated, P3 jgss/krb5plugin KerberosTime does not take into account system clock adjustement
Valerie (Yu-Ching) Peng
valerie.peng at oracle.com
Thu Nov 17 23:24:18 UTC 2011
Looks good to me.
Thanks,
Valerie
On 11/16/11 01:54, Weijun Wang wrote:
> Hi Valerie
>
> In code changes for 6882687, in order to increase the precision of
> KerberosTime, I use System.nanoTime() to calculate the current time.
> It is precise, but it's only an elapse of nanaseconds after the VM
> starts. What I did is, when the VM starts, I record a clock time, and
> after that, I add the elapsed time to it and get a current clock time.
> This would break if the user adjust the system time during the program
> execution, which will change the clock time, but not the elapse time
> since VM starts, and won't be noticed by me.
>
> Lines are added to detect system clock change. Please review:
>
> http://cr.openjdk.java.net/~weijun/7077172/webrev.00/
>
> No reg, hard to simulate system clock change.
>
> Thanks
> Max
>
>
> -------- Original Message --------
> *Change Request ID*: 7077172
> *Synopsis*: KerberosTime does not take into account system clock
> adjustement
>
> === *Description*
> ============================================================
> FULL PRODUCT VERSION :
> 7
>
> A DESCRIPTION OF THE PROBLEM :
> Context
> -----------
> In the Kerberos procotol, current client timestamp is encapsulated in
> the Kerberos query sent to the KDC to obtain a TGT. The timestamp in
> the query must be accurate (The KDC timestamp accepts 5mn deviation
> in most case); if not the KDC return a "Clock too skew" error.
>
> Problem
> ------------
> To obtain the current Timestamp, previously in the JDK 6, the
> 'KerberosTime' 'setNow()' method instanciates a 'new Date()' object .
> A JDK 7 bug fix
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6882687)
> introduces a major change in this class. The current timestamp is
> evaluated using the time elapsed since the JVM startup (use of
> System.nanoTime()).
> This implementation totally misses the fact that both client and
> server generally use a time server (NTP) to synchronize their clocks.
> Clock adjustement is not taking into account in the current
> implementation while the previous implementation does.
>
> REGRESSION. Last worked in version 6u26
>
> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
> 1. Develop a small Java client application that queries a KDC to
> obtain TGT each minutes. (Both client and KDC are hosted on the same
> machine)
> 2. Run the Java application.
> 3. Set the system clock and add 15 minutes to the current time
>
> EXPECTED VERSUS ACTUAL BEHAVIOR :
> EXPECTED -
> The KDC continues to deliver client TGT using the new time
> ACTUAL -
> The KDC returns an error 'Clock skew too great'
>
> ERROR MESSAGES/STACK TRACES THAT OCCUR :
> The Java application thrown an Exception
> javax.security.auth.login.LoginException: Clock skew too great (37) -
> PREAUTH_FAILED
>
> REPRODUCIBILITY :
> This bug can be reproduced always.
>
More information about the security-dev
mailing list