Thanks. So assuming that the time change of a great (epoch date) magnitude could occur [1], it would occur in a fluid way across the entire forest (or at least the MS machines that are part of it). Have you actually tried to change time to some arbitrarily large and incorrect value and see if other machines can sync when it is set that way or is this speculation? Beyond that, time maintained on the Windows machines is not time_t based, it is FILETIME based (64 bit value whichis the number of 100 nanosecond intervals since 1/1/1601) format which should be able to represent any 4 digit year > 1601. It can probably go beyond 4 digits but I don't expect any date routines will support a 5 digit year (holy crap - we now have a Y10K issue thanks MS, can't wait to have to deal with that one). Now that I see where you are going in terms of a vast major change to epoch ending, assuming the time change would sync across the forest I would guess that you could have a breakdown in kerberos if you somehow pushed the date beyond time_t capabilities but that is a guess. I am not sure how kerberos time is represented in the kerberos internals, are you aware of that format? Is it time_t? I would say that would be the main thing that could prompt you to say that the forest would be down. I would expect local logons to domain controllers by admins would still work (though they would probably have to change their password while logging on), the overall functionality of the environment would be unavailable - but again, this assumes kerberos stops working. Also I would guess various and sundry apps (or services) would possibly do odd things based on how they internally needed and used time. I would guess the event logs might be a little hokey for some apps. Accounts would lock if something was automatically sending the now bad passwords and not responding to the password has expired message (this assumes kerberos is working at all though which means the forest is actually up). This would impact mostly service accounts I would guess as well as network/application connections for people who were currently logged in. I really don't see why you feel a 12 hour change would hurt that much other than forcing an early refresh on kerb tickets. Do you have more detail on your thoughts on that? Specifics. So besides getting to a point where kerberos breaks due to how the time is structured in kerberos I don't see a forest that is down. If the time changed exceeded your tombstone period AND synced properly I could see replication stopping due to the delta from the last replication and not wanting to corrupt with possible bad data (i.e. lingering/revived objects). However the forest would be up and functioning in terms of authentication, you would just have to get the time corrected so replication kicks back in - which if it allowed the change in the first, place the change in the second place should be pretty easy. Anyway, I don't know how much of this I would push as an issue without actually testing to see what would happen. If the date was able to be pushed far enough, it could be painful, if kerberos is time_t based, then it could break. I would suggest working that out specifically. If you can actually force a bad date into the PDC emulator of the forest (and I am not arguing this point, I don't know enough about it), will it sync to the rest of the forest? And if so, can the date change be enough to break kerberos? I think in order to call the forest down, you would have to break either name resolution or authentication. I don't see name resolution breaking here, so you focus on authentication which would fall on kerberos. joe [1] I am still not entirely confident would occur, I think the downstreams would reject the time source but have no solid testing to prove this. -----Original Message----- From: 3APA3A [mailto:3APA3A@xxxxxxxxxxxxxxxx] Sent: Friday, August 20, 2004 2:22 AM To: joe Cc: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxx Subject: Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure Dear joe, --Friday, August 20, 2004, 2:59:06 AM, you wrote to 3APA3A@xxxxxxxxxxxxxxxx: 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, j> all machines will take their time from their default time source and j> not from a preconfigured machine as you outlined. If the time on the j> PDC emulator of the forest is spanked into a new value, either the j> other machines will be unable to sync with it due to not being able j> 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 Итак, я буду краток. (Твен)
