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