Live data from Hacker News

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

arstechnica.com

71–80 of 169 posts

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

#71

I wonder if you could use this 'feature' to exploit a system? Set up a bunch of servers all over the internet with innocuous web pages. Get all of them to include in their SSL headers the exact identical timestamp of July 5th 1998. Then get the user to connect to all those domains (eg. with a page with a bunch of iframes). The Secure Time service will see that lots of remote servers all agree with high confidence tha…

I was wondering what the newly exposed vector of exploitation was here and I think you nailed it.

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

#72

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…

> I can't imagine the sequence of horrible decisions that led to doing this. My guess is that it was created because of Windows Phone 10. But it's not a feature I'd like even on my phone.

[deleted]

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

#73
post #24

Earlier quoted context omitted.

Coincidence? $ TZ=UTC date --date=@$[$(date +%s)*2] Wed 31 Mar 15:33:50 UTC 2077

Nice spot. Perhaps something that is meant to add a delta to a timestamp accidentally adds 2 timestamps together.

How is the hardware clock connected? It it is something serial it could be an offset by 1 bit.

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

#74
post #3

TL:DR, the w32time service will sometimes try to bootstrap the clock with data from TLS handshakes. TLS 1.0-1.2 use a random value in Client Hello/Server Hello which was originaly specified as a uint32 gmt_unix_time plus 28 random bytes. It's better [1] to fill the whole structure with 32 bytes of random data (and TLS 1.3 specifies it without reference to time). If you interpret the random data as a unix time, someti…

I wrote more details in a ServerFault answer before contacting Ars Technica: https://serverfault.com/a/1132383/45588

I was baffled at what was happening after reading the article. Your TL;DR was perfect, and explained it very well in a single short paragraph. Thank you.

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

#75
The point that Windows became less reliable than Linux Desktop happened last month.

Windows 7 is still more reliable, but with the updates being over, people are forced to upgrade.

But Windows 11 is less reliable than popular Linux Desktops. There might be an exception if you have NVIDIA, but I'd say less than a few percent of people have a video card.

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

#76
post #55
post #27

That feature is simply insane. How did MS think this was a good idea? To address the issue they were trying to address (what happens when a mission critical server's RTC malfunctions or the battery dies?), Windows should treat it no differently than any other hardware malfunction in a mission-critical server: raise an alarm so a system operator can take a look and address the issue.

From the article > “The false assumption is that most SSL implementations return the server time,” Simen said. “This was probably true in a Microsoft-only ecosystem back when they implemented it, but at that time [when STS was introduced], OpenSSL was already sending random data instead.” And they link the reason for sending random data at https://mailarchive.ietf.org/arch/msg/tls/_clS-TIIlZUcid_2S4... The post start…

But, their _starting position_ is that they can't trust the network

> “Since the device is not in a state to communicate securely over the network, it cannot obtain time securely over the network as well, unless you choose to ignore network security or at least punch some holes into it by making exceptions.”

So, because they can't trust the network, or the time, they instead choose to randomly trust some of the requests over the network.

But it's okay because they rely on the certificate from that request to report whether it has been revoked or not.

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

#77

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…

> ...if it has a network... But that network is not trusted. Imagine this: You boot a machine for the first time, and the system clock tells you it's January 1, 1970. You might know when your OS was built, so you could maybe hard-code some sanity checks there, but you basically don't know what the date is. You want to communicate securely with weather.gov? Sure, you can do that over SSL/TLS. You send it a list of cip…

The article says:

> Because Secure Time Seeding used SSL certificates Windows already stored locally, it could ensure that the machine was securely connected to the remote server. The mechanism, Microsoft engineers wrote, “helped us to break the cyclical dependency between client system time and security keys, including SSL certificates.”

But in that case, why does the Windows time service connect to a random server running OpenSSL instead of a trusted server under Microsoft's control like time.microsoft.com (or whatever)?

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

#78
post #56

God knows how windows machines keep time these days, except to say that they basically don't. WSL2 has not ever been able to keep time consistent between the host and VM. You can find the issue threads on gitlab going back years at this point.

Ugh I hate this issue. Literally just ran:

sudo ntpdate time.windows.com

Because my WSL VM drifted apparently 29000 seconds into the past for...reasons... causing the az cli login to fail. With an ugly traceback, of course.

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

#79

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…

> ...if it has a network... But that network is not trusted. Imagine this: You boot a machine for the first time, and the system clock tells you it's January 1, 1970. You might know when your OS was built, so you could maybe hard-code some sanity checks there, but you basically don't know what the date is. You want to communicate securely with weather.gov? Sure, you can do that over SSL/TLS. You send it a list of cip…

> You don't have a secure network if you don't know what time it is

Yes, that's a very good reason not to trust the network to tell you what time it is.

Unfortunately, Windows, because it doesn't trust the network in the broad sense, relies on specific and known-to-be-unreliable SSL handshake data on the network to reset the clock.

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

#80

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.

But the user input thing is not the rule, its a specific case of the more general rule regarding external data generally.

It definitely applies even more to the data it is trusting in this case.

Post reply on HN