Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

61–70 of 169 posts

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

#61

Post by xg15 »

zoky wrote: post #31
xg15 wrote: post #26

Why not use all that STS cleverness to get a "rough" estimate of the current time, then use that estimate to securely connect to an NTP server and get the actual time?

Why even bother with all of the STS cleverness? The article suggests a perfectly good way to get a rough but trusted time stamp by… scraping it from a known good HTTP server. Anyway, STS as described is an obviously broken protocol. It’s not clear to me that it is even capable of reliably getting a rough time.

My understanding was that they want to pull the time over a secure (TLS) connection only - but to establish a secure connection, they already have to have the time in advance. That kind of catch-22 would always appear, no matter whether the thing you want to connect to is an NTP or an HTTP server.

So far, it all makes sense. It stops making sense when their attempt at breaking the catch-22 seems to do so by in fact ditching the "secure connection" requirement, just doing so in an obfuscated manner.

I agree, if you already violate your own rule, you could have saved everyone a lot of hassle and just pull the time from a plaintext HTTP server.

But then you might just as well ask a plaintext NTP server and go back to where everything started...

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

#62

Post by cratermoon »

nneonneo wrote: post #49

I wonder if this feature might be “infectious”: if a handful of servers wind up with the wrong time, and start propagating that wrong time in their server handshakes, it might cause a cascade of other servers to reset their times too. In any case, it seems like a poor solution especially given that random timestamps can occasionally look valid (they’re random!). The problem they’re trying to solve seems to be to obta…

At the very least the system should do what NTP does: refuse to change the system time if the delta is too large.

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

#63

Post by solardev »

LeifCarrotson wrote: post #37
yetanotherloss wrote: post #7

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…

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.

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

#64

Post by Johnny555 »

smallstepforman wrote: post #53

I’ve used Linux on an embedded system which gets time/date via proprietary monitoring protocol. Seting Linux time/date isn’t instant, Linux will run an accelerated clock until it reaches the target time. This bizzare behaviour is a hack to fix apps/services which have too high delta time which cause other problems. Its frustrating for us since when we receive a clock update, our clocks can take hours to sync. Meanwhi…

NTP will step the clock instead of slewing it if the offset exceeds a threshold, your proprietary algorithm should do the same if the time to adjust the clock is too long. I don’t think it’s unreasonable for apps to assume that time is continuous and always moving forward, so slewing seems like a good solution to the problem of time synchronization, if you need instant synchronization you can always step the clock yourself.

Under ordinary conditions, the clock discipline gradually slews the clock to the correct time, so that the time is effectively continuous and never stepped forward or backward. If, due to extreme network congestion, an offset spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if offset spikes greater than the step threshold persist for an interval more than the stepout threshold, by default 300 s, the system clock is stepped to the correct time.

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

#65

Post by simendsjo »

cratermoon wrote: post #62
nneonneo wrote: post #49

I wonder if this feature might be “infectious”: if a handful of servers wind up with the wrong time, and start propagating that wrong time in their server handshakes, it might cause a cascade of other servers to reset their times too. In any case, it seems like a poor solution especially given that random timestamps can occasionally look valid (they’re random!). The problem they’re trying to solve seems to be to obta…

At the very least the system should do what NTP does: refuse to change the system time if the delta is too large.

Funny thing is that it does refuse to change the time when the delta is large. So it trusts these random bytes in the TLS handshake blindly, but when it gets the correct time from the time server some seconds later, it doesn't dare to change the time as the delta is too large!

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

#66

Post by londons_explore »

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 that the date is July 5th 1998. So the system clock gets set to then.

Then you use a leaked yet expired cert (or maybe one signed with a broken algorithm) to impersonate an update server or steal valuable cookies/tokens.

Expired certs typically fall out the back of revocation systems too - so it really is just the expiry date/time that protects against their use.

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

#67

Post by simendsjo »

yetanotherloss wrote: post #7

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.

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

#68

Post by zokier »

simendsjo wrote: post #67
yetanotherloss wrote: post #7

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.

That seems far-fetched considering that afaik all cell networks provide time syncing

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

#69

Post by matsemann »

simendsjo wrote: post #32
toast0 wrote: 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

That's some fun debugging to figure out, heh, a real head scratcher. Nice find!

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

#70

Post by dylan604 »

solardev wrote: post #63
LeifCarrotson wrote: post #37

Earlier quoted context omitted.

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

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.
Post reply on HN