[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