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?"

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?

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?

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.

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. :-)

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.

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”.

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.

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.

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 http://kb.mit.edu/confluence/pages/viewpage.action?pageId=3908114 and maybe plenty others like it. In this case, changing the time is the same as skewing the clock.

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.

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)

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.

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?

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.

“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.”

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.

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.

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.

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)

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.