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

91–100 of 169 posts

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

#91

Post by jaegrqualm »

londons_explore wrote: post #66

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…

TFA seems to only mention errors where the time is set to the future, which would probably indicate that Microsoft at least thought of this. Their responses seem to indicate that they also don't think that it's a security issue, which means they likely don't know of any _explicit_ way to exploit this.

It seems to me that it could still be used to bring down a windows server right around the time that you wanted to, which is still a potentially serious security concern.

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

#92

Post by _dain_ »

londons_explore wrote: post #66

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…

Bitcoin? Heartbleed? SSL? Wow anon, you must have hit your head hard. C'mon, we're gonna be late for the Windows 98 launch party!

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

#93

Post by ewoodrich »

jmuguy wrote: 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…

I have a Windows work laptop that sometimes drifts up to 10 minutes off the correct time despite time/date settings saying it has synced every day. It won't even let me correct the time because of an enterprise policy requiring it to use network time. Then one day it will be back to the correct time and the drift cycle begins anew.

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

#94

Post by Arnavion »

jmholla wrote: post #46
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…

But this isn't just impacting machines at first boot. This is enabled in an on-going fashion.

The point isn't restricted to first boot. Lots of systems forget the time when they power cycle because of bad batteries or other trouble.

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

#95

Post by gerdesj »

londons_explore wrote: post #66

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…

That's not just plausible but probably needs a CVE and then MS will have to act.

I can feel an experiment coming on: Mint an OpenSSL based CA and use it to generate 200 certs for randomly generated CNs. The script could write out a zone file and web server vhost configs. Pop the CA cert in a Win PC/Server trust store. "Fix" the time on the web server. AutoIT could be used to poke a browser at each vhost or an iframe monstrosity.

I have yet to see this snag myself but it sounds like an MS style screw up. Excellent engineering fucked up by one wrong assumption which leads to a huge towering monstrosity. Sheer arrogance precludes a back down, MS ploughs on and then after a year or two, a fix is silently released and the victim shaming carries on for a little while longer. Meanwhile social.ms carries on advising sfc /scannow and then reinstalling the OS.

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

#96

Post by [deleted] »

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…

[deleted]

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

#97

Post by gerdesj »

jaegrqualm wrote: post #91
londons_explore wrote: post #66

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…

TFA seems to only mention errors where the time is set to the future, which would probably indicate that Microsoft at least thought of this. Their responses seem to indicate that they also don't think that it's a security issue, which means they likely don't know of any _explicit_ way to exploit this. It seems to me that it could still be used to bring down a windows server right around the time that you wanted to, w…

At the very least you can can screw with Kerberos which requires a default of something like five mins time sync. That's a denial of service. Keep it up for long enough and the device will fall off AD as well.

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

#98

Post by pixl97 »

cpeterso wrote: post #77
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…

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…

>instead of a trusted server under Microsoft's control like time.microsoft.com (or whatever)?

"Golly it's getting expensive hosting 100 billion random requests per year, lets let someone else shoulder the problem".

While this might not be it, we've seen plenty of other providers really screw up with time like this. I believe it was Linksys years ago just pointed their NTP as someone elses NTP servers and flooded them out.

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

#99

Post by pixl97 »

Arnavion wrote: post #94
jmholla wrote: post #46

Earlier quoted context omitted.

But this isn't just impacting machines at first boot. This is enabled in an on-going fashion.

The point isn't restricted to first boot. Lots of systems forget the time when they power cycle because of bad batteries or other trouble.

I mean, at that point the system should go to the IT group and be fixed.

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

#100

Post by bob-09 »

akira2501 wrote: post #86
dylan604 wrote: post #70

Earlier quoted context omitted.

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

If your goal is to phase out local accounts and force microsoft.com logins as part of the computer setup, being able to trust your certificates seems like a prerequisite to being able to trust your users. And the correct time is a prerequisite to trusting your certificates.
Post reply on HN