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

51–60 of 169 posts

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

#51

Post by jstanley »

matja wrote: post #24
nicolaslem wrote: post #4

I sometimes experience a similar issue with my linux laptop where time jumps to the year 2077 when waking up from sleep. My guess is that it is a hardware glitch as it doesn't happen often, but when it does it is quite impactful. One of the annoying consequences is that some parts of the system decide to clean up "old" data. Surely data that has been stale for 50 years can be deleted, right? I cannot imagine the impa…

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.

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

#52

Post by orf »

ragebol wrote: post #35
deepsun wrote: post #28

Earlier quoted context omitted.

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.

Why not let the user at least give an estimate for the current time & date. Should be close enough for certificate validation. Yes, that gets annoying fast for said user, but a good incentive to eg fix the bios battery.

Imagine there is no user, and there are thousands of machines

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

#53

Post by smallstepforman »

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. Meanwhile our packet clocks are inaccurate. This only happens during testing (by gov regulators) and to pass the tests, we had to outsmart the way the system clock works when receiving a large date/time diff.

All of these work-arounds for unneeded hacks (like in the article) drives my temper way up. Just do the simple thing in kernel space or the OS level. No suprises.

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

#54

Post by toast0 »

Wowfunhappy wrote: post #22
toast0 wrote: post #16

Earlier quoted context omitted.

It kind of depends. There's a lot of poor clocks at boot up time, but a continuously running host usually doesn't get too off, too quickly; I've seen some things, but even at 10% fast/slow, you don't have to jump days unless you're checking infrequently. On the other hand, with virtualization, who knows how long it's really been between clock ticks. Let's say someone suspends a VM for a couple months and then unsuspe…

Every VM software I've ever used automatically syncs the guest OS's clock to the host OS's clock. I've never used VMs in a server context, but do servers not do this too? It seems like the logical solution here.

I've certainly had issues with time sync in the past, and Windows has a wide range of deployment, so I would imagine they can't rely on it.

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

#55

Post by pmontra »

JohnFen wrote: 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 starts with

> Here's something I wrote about removing a fingerprinting opportunity from the current TLS protocol.

So the point is not that it was a bad idea, it is that MS didn't keep up with the world and didn't respond to requests from their customers to fix the problem.

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

#56

Post by gorkish »

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.

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

#57

Post by sebzim4500 »

lamp987 wrote: post #23
netmare wrote: post #9

Earlier quoted context omitted.

Even worse, some use Linux as their desktop OS. Imagine that...

It just works in 2023.

Makes sense. This is, after all, the year of linux on the desktop.

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

#58

Post by JohnFen »

pmontra wrote: post #55
JohnFen wrote: 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…

Yes, I read that.

I think that if you're making mission-critical systems rely on nonguaranteed behavior from systems you don't control, then it's a Bad Idea.

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

#59

Post by rcme »

pmontra wrote: post #55
JohnFen wrote: 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…

I mean it still seems like a bad idea

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

#60

Post by cratermoon »

pmontra wrote: post #55
JohnFen wrote: 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…

Yeah, when I read about SSL returning the server time I thought of fingerprinting, and I'm glad to see that it was removed. The reason giving for using it – PRNG completely broken – gave me a WTF moment, too. A broken PRNG is gonna cause a lot more trouble in SSL (TLS) than a non-random random field.
Post reply on HN