[HN Gopher] Windows feature that resets system clocks based on r...
___________________________________________________________________
Windows feature that resets system clocks based on random data is
wreaking havoc
Author : dddddaviddddd
Score : 177 points
Date : 2023-08-16 18:11 UTC (4 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| gorkish wrote:
| 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.
| buildbot wrote:
| 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.
| bbarnett wrote:
| "You may ask--why doesn't the device ask the nearest time server
| for the current time over the network?" Microsoft engineers
| wrote. "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."
|
| Let me guess, time isn't set, so dnssec is broken, so ntp servers
| won't reolve, so you can't set the time?
|
| So lame, ntp servers shouldn't be using dnssec.
| newman314 wrote:
| PowerShell invocation to disable this:
|
| Set-ItemProperty -Path
| "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name
| "UtilizeSslTimeData" -Type DWord -Value 0
|
| Reload using:
|
| W32tm.exe /config /update
| simendsjo wrote:
| Remember to tell w32tm to reload the configuration too.
| drcongo wrote:
| Blows my mind that anyone would use Windows on a server.
| netmare wrote:
| Even worse, some use Linux as their desktop OS. Imagine that...
| lamp987 wrote:
| It just works in 2023.
| sebzim4500 wrote:
| Makes sense. This is, after all, the year of linux on the
| desktop.
| justapassenger wrote:
| It does. As long as you carefully select HW.
| blibble wrote:
| let me present you the Windows 11 supported CPU list:
|
| https://learn.microsoft.com/en-us/windows-
| hardware/design/mi...
|
| anything earlier than 8th gen core? fuck you
| kibwen wrote:
| Indeed, and then consider that some poor souls even use
| Windows or Mac on the desktop.
| astrange wrote:
| Seemed to work for Stack Overflow.
| nneonneo wrote:
| 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....
| cratermoon wrote:
| At the very least the system should do what NTP does: refuse to
| change the system time if the delta is too large.
| simendsjo wrote:
| 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!
| binkHN wrote:
| The article doesn't talk about a fix--scary. I know OpenBSD uses
| a similar SSL-based method for time keeping on startup, but I've
| never experienced an issue like this.
| newman314 wrote:
| The fix is to disable.
|
| Here's the PowerShell cmd to do so: Set-ItemProperty -Path
| "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config" -Name
| "UtilizeSslTimeData" -Type DWord -Value 0
| tedunangst wrote:
| Openbsd does an https (with expiry checks disabled) GET to
| google.com (or another server) and uses the Date header in the
| response.
| JohnFen wrote:
| If it's assuming that it can make an internet connection, why
| does it do that rather than NTP?
| toast0 wrote:
| NTP is trivially MITM. Secure NTP is basically not deployed
| anywhere. Someone with a google.com cert that's valid other
| than expiration is probably google and probably has a
| working clock.
| anthk wrote:
| You can always use a gpsd(4) compatible USB dongle as the
| time source.
| toast0 wrote:
| Sure, if you have such a dongle, and it has sufficient
| view of the sky. Adding a 'free' https based sanity check
| on top of NTP seems like a good balance of cost vs
| reward.
|
| gps (and friends) is a nice way to get access to a very
| accurate timesource, but it's not always worth the cost.
| JohnFen wrote:
| Or run their own NTP server. That's what I do in my home
| network.
| somat wrote:
| It is a sanity check to protect against malicious ntp
| actors.
|
| http://man.openbsd.org/ntpd.conf#CONSTRAINTS
| simendsjo wrote:
| It's easy to turn off the feature, and its described in their
| original blog post. The article doesn't mention it directly
| though.
| yetanotherloss wrote:
| 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.
| Varriount wrote:
| 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.
| toast0 wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| toast0 wrote:
| 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.
| HPsquared wrote:
| 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.
| LeifCarrotson wrote:
| > ...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 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.
| dragonwriter wrote:
| > 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.
| jmholla wrote:
| But this isn't just impacting machines at first boot. This is
| enabled in an on-going fashion.
| Arnavion wrote:
| 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.
| pixl97 wrote:
| I mean, at that point the system should go to the IT
| group and be fixed.
| yetanotherloss wrote:
| 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.
| [deleted]
| solardev wrote:
| 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.
| dylan604 wrote:
| because every developer has been told to never trust user
| input, and to sanitize the hell out of it.
| dragonwriter wrote:
| 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.
| akira2501 wrote:
| 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 somehow divine
| a 'projected secure time.' Just, the gall to even write a
| sentence like that.
| dylan604 wrote:
| >'projected secure time.'
|
| It's 5 o'clock somewhere!
| bob-09 wrote:
| 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.
| cesarb wrote:
| If I understood the article correctly, this misfeature is
| for the rare case in which the server reboots after a power
| loss and the real-time-clock battery on the motherboard is
| dead, which can happen long after the initial setup of the
| server.
| cpeterso wrote:
| 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)?
| pixl97 wrote:
| >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.
| deepsun wrote:
| 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.
| [deleted]
| yetanotherloss wrote:
| 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.
| deepsun wrote:
| Ok, so the system should fail to boot, right?
| ragebol wrote:
| 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.
| orf wrote:
| Imagine there is no user, and there are thousands of
| machines
| simendsjo wrote:
| > 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]
| zokier wrote:
| That seems far-fetched considering that afaik all cell
| networks provide time syncing
| mlichvar wrote:
| A better solution to secure bootstrapping of time would be
| NTP+NTS (RFC 8915) using self-signed certificates with unlimited
| time validity, which can be preloaded with the OS and updated via
| normal OS updates if the server key is compromised. They would
| probably need to run their own servers. There are some public NTS
| servers (e.g. Cloudflare and Netnod), but I have not seen any
| using long-term certificates specifically for this use case.
| przemeq wrote:
| 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!
| toast0 wrote:
| 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, sometimes you're going to get weird
| results. It's not clear to me what servers w32time probes to get
| these values, either.
|
| I've seen other services that use https to bootstrap time in case
| other clocks are unavailable or suspect (or use a limited
| expiration certificate to authenticate!), it's a bit difficult
| because you have to ignore or postpone checking certificate
| expiration when validating the x.509 certificates, parse the http
| date header, and then presumably check that the date provided is
| within the time the certificates involved are valid.
|
| [1] https://datatracker.ietf.org/doc/html/draft-mathewson-no-
| gmt...
| simendsjo wrote:
| I wrote more details in a ServerFault answer before contacting
| Ars Technica: https://serverfault.com/a/1132383/45588
| nocoiner wrote:
| 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.
| matsemann wrote:
| That's some fun debugging to figure out, heh, a real head
| scratcher. Nice find!
| smallstepforman wrote:
| 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.
| Johnny555 wrote:
| 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._
| hospitalJail wrote:
| 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.
| zokier wrote:
| While this Windows feature does sound quite bonkers as described,
| it is also baffling to me that the timekeeping on computers is
| such a mess; would it really be that difficult to have my
| multithousand dollar computer keep time at least as well as a
| dollar-store quartz watch? Have time already set in factory, and
| be correct to within few hours at least; enough to do networking
| and more accurate time syncing safely.
| taylodl wrote:
| Your dollar-store quartz watch isn't on a worldwide network
| communicating with other watches where there needs to be an
| agreement on what time it is. The watch also expects _you_ to
| notice when the time drifts and for _you_ to correct it. That
| includes DST adjustments, leap second adjustments, and
| physically moving to different timezones.
|
| Even when using an NTP server to set your time, network
| latencies have to be taken into account. Otherwise, if the
| request took 300ms round-trip and that weren't accounted for
| then your machine is already 300ms off from "official" time.
| Depending upon what you're doing, being that far off can be
| critical.
|
| These are things your dollar-store quartz watch simply doesn't
| need to concern itself with.
| pixl97 wrote:
| I mean for SSL purposes, no that's not really needed that
| much. Micro seconds don't matter as certs typically expire on
| a monthly to yearly basis. And those that expire closer to
| monthly are typically updated on a regular basis.
|
| If you have a critical need for leap second time you're
| typically using your own means of NTP and not Microsofts
| broken ass bullshit.
| kmeisthax wrote:
| The problem of computer timekeeping lives on the margins. Your
| computer is probably more accurate than the quartz watch, but
| there's all sorts of ways that timekeeping can fail even on a
| system that's accurately counting time when on. Many of these
| have to do with early boot or unattended scenarios where
| trustworthy sources of time data are scarce or difficult to
| reach. e.g. maybe the motherboard clock chip is five months off
| because of a firmware bug or something, and this is a server so
| there's no user to notice the incorrect time and not having it
| set itself would cause catastrophic application failures
| somewhere else. Computer timekeeping is a comedy of errors.
| [deleted]
| justapassenger wrote:
| Two most underrated problems in software development are
| tracking (and timezones) and calendars. They both seem really
| simple on the surface, while in practice they're a gigantic
| mess that takes enormous amount of work to get right.
| jstanley wrote:
| Computers do do this. The problem is that some computers are
| quite old and the battery that keeps the real-time clock
| running has gone flat. That means if the computer is powered
| off it forgets what time it is.
|
| If your quartz watch battery goes flat you replace it straight
| away because a watch with a flat battery is 100% useless. But
| if the battery on your motherboard goes flat you don't even
| notice, so why would you replace it? To a layperson, "my
| computer's time is always wrong" is not likely to be caused by
| a random flat battery that they didn't know existed.
|
| Microsoft came up with this "Secure Time" system so that even
| computers with flat batteries would be able to work out what
| time it is, but obviously it is kind of weird and sometimes
| makes wrong decisions.
| pixl97 wrote:
| Fixing computers with a broken batteries sounds just about as
| smart as
|
| "Microsoft came up with an internet boot image that allows
| your computers to boot windows even if the hard drive is dead
| without users realizing this is the case"
|
| Honestly, when the battery dies, it's time to take it to the
| shop.
| orbital-decay wrote:
| Timepieces last a decade on a shirt button sized battery.
| Surely you can afford a bit larger battery on a motherboard,
| probably even a rechargeable one, make the clock sufficiently
| autonomous from the rest of the system, and make the
| motherboard not boot when it doesn't have the battery, so you
| can leave it unattended for a while.
| HPsquared wrote:
| Computers have a lot more temperature variations than a typical
| quartz watch. In the absence of temperature correction, they'll
| be less accurate.
| RetroTechie wrote:
| Enter the temperature compensated crystal oscillator (TXCO).
| A few $ at most should get you one.
|
| This shouldn't be overkill for a server dedicated to
| timekeeping on a large company network, right?
|
| In a datacenter one could even go for a matchbox sized atomic
| clock. Last I checked (years ago) such a miracle device could
| be had for ~$1500.
|
| Then: how often does atomic clock (or even TXCO) fail, in
| practice? My guess: only about as often as even the _backup_
| power fails.
|
| Note that either should provide accurate timekeeping without
| even going outside a physical location. That is: without
| using 'random' NTP server on the internet, GPS or whatever.
| [deleted]
| stefan_ wrote:
| Funny, they made a bad copy of tlsdate and sold it as a super new
| innovation.
| xg15 wrote:
| 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?
| zoky wrote:
| 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.
| xg15 wrote:
| 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...
| zoky wrote:
| I think the idea is that NTP is only supposed to work if
| your clock is close enough to correct, in order to prevent
| wackiness from ensuing due to sudden extreme jumps in the
| system time, presumably from a misconfiguration,
| compromised server, or whatever. I suppose you _could_ just
| rely on an insecure NTP and force the date correction, but
| given that the default is not to do that and you have to
| force it, there's probably some reason why you shouldn't.
| So, if your goal is to get the accurate time over a secure
| connection, getting a "close enough" time over an insecure
| connection and confirming /adjusting the time over secure
| NTP doesn't actually seem like the craziest way to do it.
|
| I don't really know why bootstrapping over HTTP then
| adjusting via secure NTP is better than bootstrapping via
| plaintext NTP then confirming with SSL enabled, but I guess
| it at least means two servers and protocols would have to
| be compromised.
| JohnFen wrote:
| 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.
| gopher_space wrote:
| > That feature is simply insane.
|
| 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.
| pmontra wrote:
| 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.
| JohnFen wrote:
| 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.
| rcme wrote:
| I mean it still seems like a bad idea
| cratermoon wrote:
| 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.
| misnome wrote:
| 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.
| nicolaslem wrote:
| 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 impact
| of something similar happening on a production server.
| matja wrote:
| Coincidence? $ TZ=UTC date --date=@$[$(date
| +%s)*2] Wed 31 Mar 15:33:50 UTC 2077
| jstanley wrote:
| Nice spot.
|
| Perhaps something that is meant to add a delta to a timestamp
| accidentally adds 2 timestamps together.
| almostnormal wrote:
| How is the hardware clock connected? It it is something
| serial it could be an offset by 1 bit.
| rep_lodsb wrote:
| If it's an x86 laptop, it will be compatible with the
| MC146818 chip found in the original IBM AT, and return
| the time in BCD format as yyyy/mm/dd hh/mm/ss.
| lalo2302 wrote:
| I had that with old mac os versions. Fun to finally know why it
| happened
| londons_explore wrote:
| 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.
| _dain_ wrote:
| 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!
| drvdevd wrote:
| I was wondering what the newly exposed vector of exploitation
| was here and I think you nailed it.
| gerdesj wrote:
| 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.
| londons_explore wrote:
| > 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!
| jaegrqualm wrote:
| 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.
| gerdesj wrote:
| 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.
| jmuguy wrote:
| 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.
| yetanotherloss wrote:
| 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.
| ewoodrich wrote:
| 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.
| agentgumshoe wrote:
| 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.
| macintux wrote:
| 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.
| mschuster91 wrote:
| 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.
| Terr_ wrote:
| Hmm, so essentially it's sampling times from different servers it
| thinks are unlikely to be conspiring, and those times are not as
| reliable as expected.
|
| Since it's fun to imagine (and then find flaws in proposals)
| here's an idea for y'all:
|
| 1. If the device reaches out to a dozen servers at different
| usually-trustable domains (e.g. microsoft.com, nist.gov) and they
| _all_ have "expired" certificates, that becomes a sign that My
| Local Time Is Unreliable. (Or that the machine is being booted up
| by an attacker who has connected it to a fake micro-internet.)
|
| 2. The Windows device contains a cert or public key which does
| not auto-expire based on clock-time, but is only replaced as a
| side-effect of OS patches. This cert/key exists for one specific
| purpose, allowing it to securely get a time from an MS time
| fallback server. Such a server would not normally be queried, and
| can have very relaxed performance/accuracy/uptime requirements.
| It could literally just be a GET call returning a epoch integer.
|
| 3. This way the client system can bootstrap up to something
| close-enough-to-current that the regular NTP process can be
| completed for a more-precise time.
|
| Obviously this can fail if the attacker injects a fake cert/key
| into the machine... but at that point isn't it Game Over anyway?
| The same attacker could just put in their own certificate
| authority for any service.
|
| It may not work for computers that are left unplugged and
| unpatched for a few years, but it sounds like the real issue are
| _live_ servers, or ones that just suffered some power-supply
| hiccup.
| HankB99 wrote:
| I always thought that it was a bad decision that Windows tracked
| time as local time. IMO they got it wrong right from the get-go.
| It made more sense to me to track time in an unambiguous
| manner(*) like seconds since midnight January 1. 1970 GMT and
| then convert to whatever representation is convenient locally.
|
| (*) I suppose this does not work as well on Mars. I suspect that
| the time on the various extra-planetary vehicles is tied to earth
| time but would not work so well if Mars were ever colonized.
___________________________________________________________________
(page generated 2023-08-16 23:01 UTC)