It rather involved being on the other side of this airtight hatchway: Attacking the system clock

A security vulnerability report came in that went something like this:

An attacker can trigger a buffer overflow in the XYZ component by setting the system time beyond the year 9999. This can be used as a precursor step for a further attack.

Thanks for letting us know. We'll look at it.

But is it a security vulnerability?

In order to change the system time, a user must have Change the system time permission, which is by default granted only to Administrators and SYSTEM. Therefore, a human being intending to launch such an attack would already need administrator privileges, at which point, they can just stop the XYZ component manually without needing to mess with the system time.

You might think, "Oh, but what if somebody sets up a rogue time server that broadcasts that the current time is January 1, 10000?"

We discussed this a while back. By default, the time service refuses to change the clock by more than 15 hours at a time.¹ That is to prevent exactly this type of attack: Where a rogue time server is messing with the clock in order to trick a computer into setting the time to something that can be used as a foothold for the next level of attack.

Still, this is a good bug to know about. Fortunately, we have around 8000 years to fix it. (But after 7000 years, it'll start getting urgent, so best to set a "Must fix" deadline of around the year 6000, just to be safe.)

¹ The default maximum time skew is 15 hours for workgroup-class machines. There is no default maximum time skew for domain-joined machines. "But wait, doesn't that mean that I can use a rogue time server to manipulate the clocks of domain-joined computers?" No, because domain-joined computers take their time from the domain controller, and those time synchronization packets are digitally signed. If you can forge time synchronization packages, then that means that you have stolen the private key of the domain controller, at which point, why are you wasting your time with small potatoes like spoofing the system time on workstations?

Comments (35)
  1. EduardoS says:

    And why does the component XYZ buffer overflows with a specific time?

    1. Medinoc says:

      Probably because it doesn’t expect more than 4 digits for the year.

      1. Entegy says:

        Which is funny because due to some extreme glitch when initially setting up Windows on a Mac, I did get the system clock to display the year 10000.

  2. Kirby FC says:

    I seem to remember, from my own trial and error, that Windows XP would not run if you set the date beyond 2080.

    Which is probably about the time people will finally stop using it.

  3. 12BitSlab says:

    Raymond, my guess is that MSFT has to investigate all reported vulnerabilities. Otherwise, the PR fallout would not be pretty. Out of curiosity, how many of the “other side of the airtight hatchway” type of reports are reported and how much time do the people at MSFT have to spend on them?

    1. David Totzke says:

      Raymond addresses this in a previous post. Don’t neglect the comments there either as they have some good bits in them as well:
      Not even making it to the airtight hatchway: Execution even before you get there.

      1. 12BitSlab says:

        @ David — thanks! I keep forgetting that there is a wealth of knowledge in Raymond’s prior posts.

  4. Pete says:

    Circumstances which are difficult to trigger, and non-default settings, don’t make this a non-vulnerability. This is not another “airtight hatchway” scenario. Granting a user “change the system time” permissions shouldn’t give them Administrator access.

    1. Granting a user permission to change the system clock is still pretty much a “bad idea”: it’s a global state with wide-ranging impacts on the operating system, browser, networking infrastructure, etc. A user could do many malicious things by changing the system time without taking privilege escalation into account. It falls into the same realm as letting users modify boot screens or Windows Update policies: you’re not giving them the keys to the mansion, but they can still make a huge mess of things.

      Also, we don’t know what component XYZ is, so even if a buffer overflow is triggered it may not mean much depending on where it is. It would be a far bigger deal if was triggered in the Explorer shell than if it was in, say, the Windows Time Service. Also, since Raymond’s posting about it, odds are the bug’s already fixed now. :-)

      1. Pete says:

        All good points. I was just saying that this isn’t in the usual “airtight hatchway” category where a user hacks themselves. The answer to “is it a security vulnerability?” is “yes” and everything else is quibbling over the severity.

        1. Darran Rowe says:

          It is still an airtight hatchway.
          The Change Time policy is set to administrators and system by default. To give this to other users/groups requires that the user changing the policy be an administrator. This means to set the entire ball rolling, you have to be an administrator and change the time, in which case you are already on the other side of the airtight hatchway, or an administrator has to give a non administrator the change time policy, in which case, you have an airtight hatchway with an unlocked door and a sign saying “please don’t use”.

        2. AndyCadley says:

          Well, no. In the same way that changing permissions isn’t a security vulnerability. An Administrator could change all the permissions so that a normal user could make unauthorised changes to the system, if you choose to make a system less secure you have to live with the consequences. The ability to change the system time is enormously dangerous (much ore so than the average person probably expects), which is why standard users can’t do it by default.

          1. Pete says:

            If “change system clock” is intended to be an admin-equivalent privilege AND DOCUMENTED AS SUCH – like “Debug” as Raymond says below – then you’re right and this bug doesn’t allow escalation (because once you can change the system time you’re already there).

            Otherwise, you and Darran Rowe are just making rather sad apologies for a security hole.

        3. Darran Rowe says:

          I’ll reply here since there seems to be a max level of replies.
          Anyway, while you are complaining about Windows, you should also send some of that dislike in the way of Linux and Mac too. Over on that side, changing the system time is also a privileged operation that requires super user access.
          Also, remember that the system time is used during logon. This is well known with the Kerberos protocol. See and maybe plenty others like it. In this case, changing the time is the same as skewing the clock.

        4. Darran Rowe says:

          Oh yes, and a security vulnerability/elevation of privileges isn’t necessarily getting admin rights. It is really a case of being able to do something that you shouldn’t be able to do.
          So using my Kerberos example, this allows a non administrative user to deny logon to everyone in a DoS attack.
          This of course isn’t the only problem that changing the time allows, but it is the most prominent one that I can think of.

  5. NotThisMind says:

    Unrelated: Why have i not been getting notifications from this blog since december 10th?
    I missed something on the holidays… :(

    I also can’t seem to be able to subscribe again.

  6. Dave says:

    So it will be fixed in Windows 2346? (the version number, not the year…assuming a new release every 3 years for 7000 years, continuing for Windows 10, and skipping Windows 95, 98, and 2000 for obvious reasons :P)

  7. Andre says:

    I don’t quite agree with this assessment. Sure, under normal circumstances
    1) a normal user cannot change the system clock and
    2) an administrator is already all-powerful (on the other side of the hatchway).
    But NT security controls are more fine-grained than “restricted user” and “administrator”. Just because “change system time permission” usually coincides with “full permissions for everything” doesn’t mean it has to.
    So (assuming this can actually be exploited with “further attack”) you still have a privilege escalation from “change system time” to “full control”. It’s not a critical scenario, but it is an escalation.

    1. Ken in NH says:

      You can also give a normal user debug privilege. Should they worry about all the vulnerabilities that emanate from that?

      In some cases, the old joke about the visiting the doctor is right; if it hurts when you do that, then don’t do that.

      1. voo says:

        That’s nowhere the same thing. Debug privilege by definition gives you admin rights with just a different name.

        But you really think there’s an inherent reason that having “rights to change system time” should equate admin rights?

        The consequence of that thinking is that adding any group to a user makes it implicitly an admin, because how would you know any better?

        1. Ken in NH says:

          No sorry, debug privilege does not confer administrator access. For example, it does not allow one to change ownership of a file that does not already belong to them or change the system clock. You can use debug privilege to cause havoc and escalate in various ways, including exploiting buffer overflows, but that does not make someone with debugging privilege an administrator nor any buffer overflows they could not exploit without that privilege a high-priority vulnerability.

          But really, the burden is on those of you who think this is a valid exploit that deserves immediate priority. Why do you wish to confer system time privilege to the ordinary user? Why would you confer it to someone who you fear will misuse it or be negligent? Just how often do they change their system clock and why? In other words, what is the use case for this that makes it common to bypass this safety mechanism?

          1. Debug privilege indirectly gives you admin because you can use it to debug a service running as SYSTEM and inject arbitrary code into it.

          2. Ken in NH says:


            Yes, I thought I had already conceded that when I stated, “You can use debug privilege to … escalate in various ways”.

            Thinking for on it though, perhaps my rebuttal should be, if you don’t want a non-admin user to be able to escalate to admin then don’t give them privileges usually reserved for admins.

  8. Joshua says:

    Well we do have a procedure on file for making a bastion host against a compromised domain. You would probably say it defeats the purpose of being on the domain, but it doesn’t: it allows the host to use domain resources.

    Life would be good if I never had to use that procedure again. The support ramifications are kind of a pain in the behind.

  9. jon says:

    Don’t be too smug, I have no problem believing that Microsoft could leave a bug unfixed for 8000 years.

    1. cheong00 says:

      I have no problem the world will have yet another Y2K like panic on year 9999, but I doubt any of us will have chance to see it.

  10. GWO says:

    “In order to change the system time, a user must have Change the system time permission, which is by default granted only to Administrators and SYSTEM. Therefore, a human being intending to launch such an attack would already need administrator privilege”

    Is there anyway to interpret this other than “Granular permissions are broken. If a granular permission may be leveraged to full Administrator rights, this is not a bug.”

    1. Entegy says:

      Why would a normal user need to change the clock? That’s a system level thing that affects all users. Users can change their time zone, but not adjust the clock for everyone.

      1. voo says:

        It doesn’t matter whether you think it’s a good idea or not. It’s about whether Microsoft’s official stance really is that adding *any* permission, independent of how harmless to a restricted user makes them an administrator, this means that the whole permission system is broken by design.

        1. Darran Rowe says:

          The change system time privilege is actually a lot more damaging than you think.
          IIRC, Kerberos actually relies on the time for security purposes, and in a domain setting, the client’s clock can’t be that different from the domain server’s clock otherwise it will refuse login.
          Another one is digital certificates, since they normally have a limited period in which they are used.
          Anyway, this is totally separate to the perception that the granular security in Windows is broken or not. This is because the time has a really large role in security, so even if Microsoft provided more granular groups for users, the change time privilege would still be only available to administrators.

      2. cheong00 says:

        Maybe to workaround some machanics that binds to the clock?

        Say, some evaluation software that won’t function after 30days and don’t let you reset the counter by reinstalling it. (I know that violates Eula of the evaluation software, but lots of company have very loose software audit policy that audits software that the company owns instead of software installed on system by users)

        But wait, they have the right to install software, so they are admin too.

        1. GWO says:

          So the idea that permission control are fine grained is a fiction, and if you grant anyone any permission above standard user permissions – however seemingly minor – it must be assumed that they now have full admin rights.

          Is that documented anywhere? Is there a list of which policy-granted capabilities can be “exploited” in this way to gain full admin rights? (I use the quotes as its clear that you don’t consider leveraging the ability to change the clock to read arbitrary private data to be an exploit – despite the fact it self-evidently is)

    2. There are a number of admin-equivalent privileges. For example, Backup and Restore privilege lets you overwrite any file. We already saw that Debug privilege is admin-equivalent.

    3. AndyCadley says:

      Privileges aren’t the same as permissions, even if you’re account has a given privilege you can’t perform the operation in code without first enabling the privilege. So they offer a certain amount of protection against silly mistakes, even when running as an Administrator.

Comments are closed.

Skip to main content