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