Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure

Dear joe,

--Friday, August 20, 2004, 2:59:06 AM, you wrote to 3APA3A@security.nnov.ru:

j> "If network is configured in accordance to these recommendations it's
j> possible to bring whole Windows 2003 forest down with a single UDP
j> packet."

j> What is your line of reasoning here? In a properly configured forest, all
j> machines will take their time from their default time source and not from a
j> preconfigured machine as you outlined. If the time on the PDC emulator of
j> the forest is spanked into a new value, either the other machines will be
j> unable to sync with it due to not being able to authenticate with it or the

Time synchronisation doesn't require authentication, at least it looks
like packets are only signed with computer key. That's why it's still
possible to change time across all forest with a single packet, if one
of the forest's reliable time sources or PDC emulator in root domain use
external SNTP server.

Before Windows 2000 SP4 it was possible to set date far in future (for
example to 2038). Locked accounts, expired certificates in addition to
"problem 2038" (Jan, 19 2038 is maximum date value for 32 bit time_t
timestamp used in many C compilers). But setting date 12 hours in future
or 12 hours in past still can produce a lot of harm.

-- 
~/ZARAZA
Итак, я буду краток. (Твен)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html