[ntp:hackers] Replays and fuzz

David L. Mills mills at udel.edu
Sun May 6 20:10:37 PDT 2007


Guys,

I little analysis I stumbled over in class found a wee crack in the 
replay defense. Currently, this is done using the originate timestamp, 
which serves as nonce. Currently, replays of the client-inbound message 
are deflected using the destination timestamp. However, replays of the 
client-outbound message may cause the server to return a client-inbound 
message that won't be caught, as the originate timestamp remains the 
same. Easy to fix; the code in ntp-proto.c has been changed to set the 
originate state variable to zero once a client-inbound message has been 
validated.

The code in ntp_proto.c that estimates the host precision at startup has 
grossly misleading comments and does not operate correctly when no 
tick-interpolation means is available. I don't have machines around here 
like that, so would appreciate somebody checking with something really old.

A look at the code that stuffs a fuzz bitstring in the timespec and 
timeval structures has weeds. Originally, it operated to fuzz everything 
below the precision, but didn't do that properly. On the basis that you 
don't really know the actual clock during the syscall itself, the actual 
value can be anywhere in the middle. Even so, whatever the position, it 
probably doesn't change much in subsequent calls. On this conclusion and 
considering the extra fuzz is probably not justified, the get_systime() 
call now fuzzes only the nonsignificant bits of the kernel syscall.

In ntp-dev now.

Dave


More information about the hackers mailing list