Live data from Hacker News

Windows feature that resets system clocks based on random data is wreaking havoc

arstechnica.com

81–90 of 169 posts

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#81
post #17

While this Windows feature does sound quite bonkers as described, it is also baffling to me that the timekeeping on computers is such a mess; would it really be that difficult to have my multithousand dollar computer keep time at least as well as a dollar-store quartz watch? Have time already set in factory, and be correct to within few hours at least; enough to do networking and more accurate time syncing safely.

Computers have a lot more temperature variations than a typical quartz watch. In the absence of temperature correction, they'll be less accurate.

Enter the temperature compensated crystal oscillator (TXCO). A few $ at most should get you one.

This shouldn't be overkill for a server dedicated to timekeeping on a large company network, right?

In a datacenter one could even go for a matchbox sized atomic clock. Last I checked (years ago) such a miracle device could be had for ~$1500.

Then: how often does atomic clock (or even TXCO) fail, in practice? My guess: only about as often as even the backup power fails.

Note that either should provide accurate timekeeping without even going outside a physical location. That is: without using 'random' NTP server on the internet, GPS or whatever.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#83

PowerShell invocation to disable this: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "UtilizeSslTimeData" -Type DWord -Value 0 Reload using: W32tm.exe /config /update

Remember to tell w32tm to reload the configuration too.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#84
post #2

The article doesn’t talk about a fix—scary. I know OpenBSD uses a similar SSL-based method for time keeping on startup, but I’ve never experienced an issue like this.

The fix is to disable.

Here's the PowerShell cmd to do so: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name "UtilizeSslTimeData" -Type DWord -Value 0

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#85

Earlier quoted context omitted.

Computers have a lot more temperature variations than a typical quartz watch. In the absence of temperature correction, they'll be less accurate.

Enter the temperature compensated crystal oscillator (TXCO). A few $ at most should get you one. This shouldn't be overkill for a server dedicated to timekeeping on a large company network, right? In a datacenter one could even go for a matchbox sized atomic clock. Last I checked (years ago) such a miracle device could be had for ~$1500. Then: how often does atomic clock (or even TXCO) fail, in practice? My guess: on…

[deleted]

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#86

Earlier quoted context omitted.

Why can't it just ask the human to provide it, either in the welcome UI or in a setup script? That's how we've set up computers for many milliseconds.

because every developer has been told to never trust user input, and to sanitize the hell out of it.

There are public users and owner users. Specifically, you don't trust input from public users. You absolutely should trust input from owner users, or if you won't by default for some reason, you absolutely should give them the option to do so. Primarily, you should be giving them the choice as to what their system will do when it cannot reliably determine the actual time.

The alternative is to pretend that you can somehow divine a 'projected secure time.' Just, the gall to even write a sentence like that.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#87
post #12

Windows Time bullshit was one of the most annoying things I dealt with during my years as an IT guy. Registering and unregistering w32time, trying different NTP servers. Trying to figure out why domain systems werent getting their time from the DC. It always felt so... stupid. Surely having the correct time on a device isnt that complicated. Turns out, its not, unless you're on Windows. Somewhat ironic that these day…

Windows isn't the only thing with issues. Both ntpd and systemd-timesyncd can be very annoying if upstream servers send a bad stratum value, and the maintainence team of upstream is a bunch of morons taking weeks to fix it. You can't say "forcibly use IP w.x.y.z no matter what" to either of them.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#88
I always thought that it was a bad decision that Windows tracked time as local time. IMO they got it wrong right from the get-go. It made more sense to me to track time in an unambiguous manner(*) like seconds since midnight January 1. 1970 GMT and then convert to whatever representation is convenient locally.

(*) I suppose this does not work as well on Mars. I suspect that the time on the various extra-planetary vehicles is tied to earth time but would not work so well if Mars were ever colonized.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#89
post #28

I can't imagine the sequence of horrible decisions that led to doing this. Like, why would the time service ever want to depend on all this insanity when if it has a network and everything else is bizarro world, just like scrape the time and date text from weather.gov. Or just accept that absent NTP, w32time maybe just shouldn't try to set the clock to whatever a circus clown tells it? This sort of reminds me how the…

It's already discussed in the article -- because to determine that weather.gov connection is sound and not hacked, you first need to check its certificate expiration date. Chicken/Egg problem.

[deleted]

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#90
Hmm, so essentially it's sampling times from different servers it thinks are unlikely to be conspiring, and those times are not as reliable as expected.

Since it's fun to imagine (and then find flaws in proposals) here's an idea for y'all:

1. If the device reaches out to a dozen servers at different usually-trustable domains (e.g. microsoft.com, nist.gov) and they _all_ have "expired" certificates, that becomes a sign that My Local Time Is Unreliable. (Or that the machine is being booted up by an attacker who has connected it to a fake micro-internet.)

2. The Windows device contains a cert or public key which does not auto-expire based on clock-time, but is only replaced as a side-effect of OS patches. This cert/key exists for one specific purpose, allowing it to securely get a time from an MS time fallback server. Such a server would not normally be queried, and can have very relaxed performance/accuracy/uptime requirements. It could literally just be a GET call returning a epoch integer.

3. This way the client system can bootstrap up to something close-enough-to-current that the regular NTP process can be completed for a more-precise time.

Obviously this can fail if the attacker injects a fake cert/key into the machine... but at that point isn't it Game Over anyway? The same attacker could just put in their own certificate authority for any service.

It may not work for computers that are left unplugged and unpatched for a few years, but it sounds like the real issue are live servers, or ones that just suffered some power-supply hiccup.

Post reply on HN