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.
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.
> advising sfc /scannow and then reinstalling the OS.
I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again.
Or you could just wipe all config and reinstall everything and hope it doesn't happen again!
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.
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.
If you're a big enough customer, and you contrive a way to rely on this bug, then you've hacked the Microsoft backwards compatibility commitment. They'll have to preserve the functionality in perpetuum.
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 days the only Windows system I have to deal with is my gaming PC. It refuses to sync with time.windows.com.
It's probably still the case that Windows will consider the firmware clock more reliable than anything but a stratum 1 (direct gps/glonas/atomic) or maybe 2 time source which can result in truly bizarre behavior if the firmwar/hypervisor drifts too far from dozens of stratum 2 or 3 active directory servers. It logs no messages about this logic fork.
I don't recall the exact conditions that determine this but troubleshooting it is an exercise in thinking you're having a stroke.
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.
I find some humor in this being somewhat familiar with the history of clocks and watches. Forever the battle was making the most accurate time pieces possible, with wrist watches eventually reaching a few seconds per day variance before digital watches took over. And new we have something trillions of times more complicated and is performing worse
There are ways said to circumvent the enterprise policy on the autosync side, like unregistering win32tm or deleting all servers from the registry. No idea about setting the time though…
(A smarter time daemon like chrony would've kept track of the RTC drift.)
I decided a while ago that I was willing to sacrifice a few (and it's very few now - mostly just some anti-cheat using ones) games to just go Linux full time. I don't miss Windows one bit (well except Photoshop I guess :/) and I game a lot.
Unless you need the newest features, Photoshop runs surprisingly well under Wine - and I don't mean this in the usual "oh yea, Wine totally works" way where it's a huge pain to set up and is 90% luck, it actually runs with barely more glitches than on Windows (not zero, but it's Adobe software, so you can't expect much).
In 1996 I was supporting a small dialup operation, and one of our customers was having non-stop problems connecting via modem.
Their plant was 2 hours away, but I was driving past there to visit a friend, so I made arrangements to drop by and investigate.
For reasons unknown, most of their Windows desktops were configured to a year in the 21st century, probably 2096 instead of 1996 but it’s been a while. Wish I knew how they ended up that way, but I’m surprised dialup was the only thing they noticed that was broken.
A lot of shareware back then stopped working after a certain # of calendar days, which it used windows to figure out. So I always had my date set far in the future.
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.
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.
> “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.”
> 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.
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.
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.
It really feels like someone's thought experiment that was cargo-culted into production. Timestamps are truthy to begin with, and mission-critical systems are designed to die and be reborn anew like the common Phoenix. Physical issues that might come up are addressed in the spec and logical issues stop everything they touch. At no point have I ever hoped that a third party would start pumping garbage into the problem.
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 there is a buried registry setting to tell w32time to not place the firmware clock at very high stratum in the time sources list which also is just a giant WTF in how those two behaviors were decided on.
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 cipher suites and SSL/TLS versions you can use, the weather.gov server selects a cipher and version, and sends you their certificate. It's valid from Jun 2023 to Jun 2024, signed by a DigiCert TLS RSA SHA256 2020 CA1 certificate valid Apr 2021 to Jun 2024, which is itself signed by the Digicert root global CA encoded into your OS's root certificate store, valid Nov 2006 to Sun, Apr 2031.
Wait a second. Or maybe 1.7 billion seconds. Are any of those certificates valid? Do you want to let the attacker set the date back to when a revoked, potentially leaked Trustico or Symantec private certificate was valid?
You don't have a secure network if you don't know what time it is.
Man it's like you and the other respondent want to be helpful but didn't read the next sentence after that bit of hyperbole.
If all available time sources are not trustable and none of the existing answers make sense, do not try to set the clock! Coming up with more complicated ways to use untrustable data is not an improvement.
> 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)?
> 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.
This is what puzzles me - while time drift does occur, it tends to be in the form of minor errors which build up over time; large jumps are relatively rare. You'd think the mechanism described in the article would have a failsafe ensuring that only minor time recalibrations are performed.
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 unsuspends it; hopefully the clock is synchronized, but maybe it isn't, and you do need to jump ahead.
I thought I saw in the article that there are failsafes, but the allowed range is still pretty broad. But reporting is going to tend to be dominated by larger values, because smalller jumps are less likely to be noticed or more likely to be considered an accidental change.
There are a lot of machines out there with a dead battery on the real time clock. Every time they boot, the time is miles out and at some system-determined zero point.
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.
That's the point, if you can't trust the connection, stop trying to come up with more complicated ways to use the untrustable connection and accept that there is no safe way to update time.
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 obtain a trustworthy timestamp in the presence of a potentially hostile network - one that could be presenting expired, cracked certificates for every connection to arbitrarily tamper with all SSL connections. It’s not a trivial problem, for sure, but resetting perfectly valid clocks using this algorithm seems like a strict downgrade….
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!
Wow, we encountered a similar problem on one of our servers. We couldn't determine the cause. We set up an alarm to notify us when such a change occurs, and we've developed a procedure to handle the consequences. Great discovery!
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.
A bit of a tangent, but this time-checking heuristic reminds me of the game "Halo 3: ODST".
The story takes place in a future African megacity before, during, and after an alien invasion. Part of the game's story is shown from an AI's perspective who controls the city's operations trying to evacuate the Human survivors.
Whenever the story is shown through the AI's perspective, you can see an overlay of the AI's working memory including which suburb's cameras are being monitored, the emotional state of the AI, and the current running timestamp.
Some of the aliens end up withdrawing from within the city by making an FTL jump which causes extreme localised time dilation.
Immediately afterwards, the timestamp in the AI's working memory is frozen because it's not sure what the exact timestamp is anymore, each system it connects to gives it a slightly different time depending on how close it was to the FTL event.
It guesses a likely time and uses that until sometime later it is able to reconnect with other unaffected human networks and resumes the correct timestamps.
This time heuristic was shown in the game, but also makes an appearance of sorts in the announcement trailer (seen in the bottom right): https://www.youtube.com/watch?v=WroxHMo6B_k
Readit News
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.
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.
I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again.
Or you could just wipe all config and reinstall everything and hope it doesn't happen again!
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.
If you're a big enough customer, and you contrive a way to rely on this bug, then you've hacked the Microsoft backwards compatibility commitment. They'll have to preserve the functionality in perpetuum.
I don't recall the exact conditions that determine this but troubleshooting it is an exercise in thinking you're having a stroke.
Deleted Comment
(A smarter time daemon like chrony would've kept track of the RTC drift.)
This is the installer I used to use: https://github.com/Gictorbit/photoshopCClinux
This one is newer and looks even more promising: https://github.com/LinSoftWin/Photoshop-CC2022-Linux
Their plant was 2 hours away, but I was driving past there to visit a friend, so I made arrangements to drop by and investigate.
For reasons unknown, most of their Windows desktops were configured to a year in the 21st century, probably 2096 instead of 1996 but it’s been a while. Wish I knew how they ended up that way, but I’m surprised dialup was the only thing they noticed that was broken.
That doesn't sound right. Are you using some kind of externally controlled list of round-robin servers?
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.
> “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.
> “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.
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.
It really feels like someone's thought experiment that was cargo-culted into production. Timestamps are truthy to begin with, and mission-critical systems are designed to die and be reborn anew like the common Phoenix. Physical issues that might come up are addressed in the spec and logical issues stop everything they touch. At no point have I ever hoped that a third party would start pumping garbage into the problem.
https://youtu.be/AsXKS8Nyu8Q
(Whatever other representations there are of "The Good Idea Fairy", I can't help but think of Baldrick and his "cunning plans".)
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 there is a buried registry setting to tell w32time to not place the firmware clock at very high stratum in the time sources list which also is just a giant WTF in how those two behaviors were decided on.
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 cipher suites and SSL/TLS versions you can use, the weather.gov server selects a cipher and version, and sends you their certificate. It's valid from Jun 2023 to Jun 2024, signed by a DigiCert TLS RSA SHA256 2020 CA1 certificate valid Apr 2021 to Jun 2024, which is itself signed by the Digicert root global CA encoded into your OS's root certificate store, valid Nov 2006 to Sun, Apr 2031.
Wait a second. Or maybe 1.7 billion seconds. Are any of those certificates valid? Do you want to let the attacker set the date back to when a revoked, potentially leaked Trustico or Symantec private certificate was valid?
You don't have a secure network if you don't know what time it is.
If all available time sources are not trustable and none of the existing answers make sense, do not try to set the clock! Coming up with more complicated ways to use untrustable data is not an improvement.
> 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)?
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.
Deleted Comment
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 unsuspends it; hopefully the clock is synchronized, but maybe it isn't, and you do need to jump ahead.
I thought I saw in the article that there are failsafes, but the allowed range is still pretty broad. But reporting is going to tend to be dominated by larger values, because smalller jumps are less likely to be noticed or more likely to be considered an accidental change.
Yes, that gets annoying fast for said user, but a good incentive to eg fix the bios battery.
Deleted Comment
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 Comment
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 obtain a trustworthy timestamp in the presence of a potentially hostile network - one that could be presenting expired, cracked certificates for every connection to arbitrarily tamper with all SSL connections. It’s not a trivial problem, for sure, but resetting perfectly valid clocks using this algorithm seems like a strict downgrade….
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.
The story takes place in a future African megacity before, during, and after an alien invasion. Part of the game's story is shown from an AI's perspective who controls the city's operations trying to evacuate the Human survivors.
Whenever the story is shown through the AI's perspective, you can see an overlay of the AI's working memory including which suburb's cameras are being monitored, the emotional state of the AI, and the current running timestamp.
Some of the aliens end up withdrawing from within the city by making an FTL jump which causes extreme localised time dilation.
Immediately afterwards, the timestamp in the AI's working memory is frozen because it's not sure what the exact timestamp is anymore, each system it connects to gives it a slightly different time depending on how close it was to the FTL event.
It guesses a likely time and uses that until sometime later it is able to reconnect with other unaffected human networks and resumes the correct timestamps.
This time heuristic was shown in the game, but also makes an appearance of sorts in the announcement trailer (seen in the bottom right): https://www.youtube.com/watch?v=WroxHMo6B_k