Windowsの時刻補正機能の影響で日付が大幅にズレる 41
ストーリー by nagazou
ズレ 部門より
ズレ 部門より
Ars Technicaの記事によると、Windowsのシステムクロックが数日から数か月単位でズレてリセットされる問題が発生しているそうだ。原因は2016年から導入された「Secure Time Seeding」という機能。この問題により、データセンターや携帯電話番号の変更などでトラブルが生じ、影響が広がっているという（Ars Technica、GIGAZINE）。
具体的には、ノルウェーのデータセンターでシステムクロックが55日後にリセットされる事態が発生、携帯端末の電話番号の変更処理が誤って処理されるなどの問題が生じたとされる。2022年8月にも同様の問題が報告されており、ノルウェーのデータセンターのエンジニアのジーメン氏が問題の原因を追求したところ、「Secure Time Seeding」機能が原因であることが判明したとしている。
「Secure Time Seeding」は、システムクロックの正確性を確保するために、2016年から導入された仕組みで、システムの電源が切れている際でも正確な時間を維持する。同様に時計を合わせる方法としてはNTPサーバーを用いる方法があるが、この方法は外部のネットワークに依存するため、サーバーなどではセキュリティ上の問題が生じる可能性がある。そこでSecure Time Seedingでは、リモートサーバーと行うSSLハンドシェイクのデータに基づいて時間を設定する仕組みとなっている。
問題を報告したエンジニアらはMicrosoftにこの問題の対策を求めているが、現時点では効果的な解決策は見つかっていないとされる。Microsoft側は「Secure Time Seeding」が原因で問題が発生する場合、複雑な要因が影響している可能性があるとして、必要に応じて機能を無効化することを推奨しているようだ。
あるAnonymous Coward 曰く、
具体的には、ノルウェーのデータセンターでシステムクロックが55日後にリセットされる事態が発生、携帯端末の電話番号の変更処理が誤って処理されるなどの問題が生じたとされる。2022年8月にも同様の問題が報告されており、ノルウェーのデータセンターのエンジニアのジーメン氏が問題の原因を追求したところ、「Secure Time Seeding」機能が原因であることが判明したとしている。
「Secure Time Seeding」は、システムクロックの正確性を確保するために、2016年から導入された仕組みで、システムの電源が切れている際でも正確な時間を維持する。同様に時計を合わせる方法としてはNTPサーバーを用いる方法があるが、この方法は外部のネットワークに依存するため、サーバーなどではセキュリティ上の問題が生じる可能性がある。そこでSecure Time Seedingでは、リモートサーバーと行うSSLハンドシェイクのデータに基づいて時間を設定する仕組みとなっている。
問題を報告したエンジニアらはMicrosoftにこの問題の対策を求めているが、現時点では効果的な解決策は見つかっていないとされる。Microsoft側は「Secure Time Seeding」が原因で問題が発生する場合、複雑な要因が影響している可能性があるとして、必要に応じて機能を無効化することを推奨しているようだ。
あるAnonymous Coward 曰く、
真っ先に無効にしてたから、今でも時刻が飛ぶ現象が続いてるって知りませんでした。
別原因でも狂う (スコア:1)
録画サーバーの時刻が、一定周期でとんでもない過去の日時に変更される現象に悩まされた。
このマシン、完全オフラインだけど、時刻はデジタル放送に乗っている時刻情報を取得することで自動補正されるようにしている。
長い間原因がわからずに困ってたんだが、Windowsでは標準で設定される「時刻を自動的に設定する」をオフにすると解消されることがわかった。何回かNTPサーバーとの通信ができないと、勝手に時刻が変更される「仕様」みたい。これに何の御利益があるのか、さっぱりわからんけど、迷惑千万。
同じ現象に遭遇する方はあまりおられないと思うけど、もし悩んでいるなら、この対策を試してみるといい。
Re: (スコア:0)
RTCの電池切れてない？
地デジで自動補正が、hwclock -w相当の処理をしてないから、RTCがずれてる。
で、NTPで繋がらない時に、RTC時刻に戻す処理が走ってRTCのずれた日時に戻ってるパターン。
勝手にRTCに同期する機能もある (スコア:1)
NTPやドメインコントローラで時刻同期してない場合、システムクロックとRTCが60秒以上ずれるとシステムクロックがRTCにあわされる。
数か月に1回数十秒動作が止まるというよくわからんバグの原因がこれだった。
時計が狂ってる機械が居るんでしょ？ (スコア:0)
自前のプライベート認証局か、IDS/IPSか、iSCSIとかのSANか、UPSなのか知らないが、時計が狂ってる奴が居るのでは？
Re: (スコア:0)
これって、NTPをSSLでラップしたようなものなのかな?
>リモートサーバーと行うSSLハンドシェイク
この「リモートサーバ」ってどこが用意するもの?
Microsoft?
Re:時計が狂ってる機械が居るんでしょ？ (スコア:3, 参考になる)
どこかのサイトに繋ぐとき、SSLハンドシェイク内に現れるServerUnixTimeというフィールドと、
OCSPに問い合わせて得られた有効期限情報をそれぞれ使うとのこと。
いずれも正しいことを保証する仕組みではないし、意図的に乱数などの値を入れて返す実装もあるが、
ネット上を見てたらだいたい合ってるみたいだし、ええんちゃう？みたいな仕組みらしい。
Re: (スコア:0)
> 意図的に乱数などの値を入れて返す実装
これが原因なのでは。その実装が悪いわけではなさそうだけど
Re: (スコア:0)
いや、そんな保証されていない情報をシステム時刻に使っちゃうMSがマヌケ
ってことでFA?
# ネットは悪意に溢れていると考えていないMSって純情 !!!
Re: (スコア:0)
いやでも内部時間がミリ秒単位で知られると困るからずらすという話で、年単位ずらすことはないんじゃないの？
下手すると証明書期限切れみたいな話になるし。
Re: (スコア:0)
"ServerUnixTime" と呼ばれているのは、おそらくServer Hello内に現れる"GMT Unix Time"のフィールドかと思いますが、これはそもそも乱数の種(シード)として使うことを想定したもので、毎回異なる値でさえあれば十分なものであり、現にTLS1.3では廃止されて [nic.ad.jp]います。
なのでミリ秒単位どころか100年単位でずらしても本来の仕様上は問題ないはずのものなので、それを設計の想定を越えて流用してしまったのが問題の根本と思われます。
Re:時計が狂ってる機械が居るんでしょ？ (スコア:1)
SSL/TLSのプロトコル上正確な時刻をやり取りする必要があるのでそれを流用するというアイデアで、特定の時刻合わせ目的のサーバーを立てる必要はない。福岡大学のサーバーに決め打ちで接続とかしない限り、文字通り「どこでもいい」。
Re: (スコア:0)
> SSL/TLSのプロトコル上正確な時刻をやり取りする必要がある
それは正確な現在時刻がわからないと、とっくに有効期限の切れた証明書を、今も有効と勘違いさせられてしまうし、
あるいは現在有効な証明書をまだ有効になっていないと勘違いしてしまう可能性もある（なのでSSLのエラー画面にはシステム時刻を確認しろと書いてある）。
なのに、どこの馬の骨ともしれぬ「リモートサーバー」が言ってきた時刻を信じ込むって正気の実装とは思えないのですが？
それとも、NTPと同じで、あらかじめ正確な時刻を教えてくれると信頼するサーバーを設定しておくという話でしょうか？
それなら別にNTPで良くないですか？なんかこの機能の利点あるんですか？
Re:時計が狂ってる機械が居るんでしょ？ (スコア:1)
時計の設定で年月日を間違えて設定するようなユーザーからの、
インターネットが見れない(実際は証明書エラー)のサポートコストを削れます。
※NTPは15もしくは48時間以上ズレてる場合は修正しない。
Re: (スコア:0)
結果それで年月月日が誤って設定されるのであれば、サポートコスト上がる上にセキュリティ的にもまずい状態となるよね
Re: (スコア:0)
Microsoftのバグはもっと根深いところに原因がある。
想定外の原因で発生するので変な日付になるのでしょう。
時計がくるっている程度なら時計を直せば解決するし
書いてある通り、時計がくるっている程度ならずれても数時間でしょ。
日付がずれるってのは全く別なところから値がとられいるのでしょうね。
もしくは仕様正しく理解しないまま実装した結果のバグ。
年月日の順番が逆とか凡ミスレベルかもよ。
Re: (スコア:0)
何の根拠もないのに良くもまあ長々と語れるもんだ。
Re: (スコア:0)
顧客のネットワークや機器が原因だと回答困難ってのは有ると思う。
少なくとも原因踏査でSecure Time Seedingで日付が飛んだってなってるわけだし。
確認はしてないけど、数時間の乱数によるズレ程度なら日付や時刻は飛ばないと思う。
RTC電池切れとかであまりに過去日だと前回シャットダウン日時にセットするとかその辺のお節介機能の副作用と考えた方が自然だと思う。
Secure Time Seedingって、1年間違えて日付をセットして、SSL/TLS使ったサイトが証明書エラーで見れないとか、Windows Updateが出来ないとかの対策で実装したのが裏目になってるパターンだと思われる。
なので、狂う該当日付を持ってるマシンがどっかに居るのでしょう。
WindowsあるあるではWindows updateが原因では？ (スコア:0)
そもそもエラーコードで発生してるのでは？
プログラムは各種サービスの上に存在し。
Windows updateの処理が始まるとサービスが停止する。
動いているプログラム側ではエラーが出る。
Windows homeで事故る原因。
WindowsをServerで手動手動更新した場合も同様で
プログラムを停止せずに行っているならエラーが出ている可能性がある。
その引数が日付に混入したなら考えられないこともない。
Re: (スコア:0)
セルフコメント。
ストーリーのリンク先の情報読んだら理解した。
OpenSSL系は互換性で必要な場合 [github.com]以外は、Server Helloのgmt_unix_timeにも乱数を詰め込んでくる [github.com]のね。
結果、SSLのgmt_unix_timeが偶然ヨサゲな値になると採用されて狂うと。
こりゃ、Windowsの当該機能を無効化するしかないねぇ。
55日後にリセット (スコア:0)
起動後49日でフリーズならどこかで聞いたような
Re: (スコア:0)
75日もたてばみんなうやむやになる
かもよ
Windowsふしぎ発見！ (スコア:0)
想定外のトラブルが起こるたびにワクワクします。
Re:Windowsふしぎ発見！ (スコア:1)
通常の想定を超える不思議なバグはマイクロソフト特有なんですよね。
設計する際の詰めがあまい。
または杜撰である。と言うのが適切な意見。
フェールセーフの考えがない。
品質より納期が大事。バグっても後で直せばいいや。
それで乗り切ってきたつもりなんだろうけど
もう直せなくなっているよね。
Re: (スコア:0)
Appleのバグは原因確認するとマヌケなものばかりだもんな。
Re: (スコア:0)
設計工程を飛ばして思い付きで実装して動かしてみてから考えるんでしょ？
Re: (スコア:0)
macOS Ventura 13.5に不具合、Macアプリが位置情報取得できず
https://iphone-mania.jp/news-548612/ [iphone-mania.jp]
Re: (スコア:0)
だれもmacの話なんてしてませんよ
Re: (スコア:0)
なぜかWindowsの不具合だけこうやって大々的に取り上げられてmacOSの不具合はスルーされるんですよね不思議ですねえ・・・
Re: (スコア:0)
反Apple教徒だとストーカーのごとく気になって仕方がないかもしれませんが、単にシェアの低いマイナーなクライアントOSだからでしょう
Re: (スコア:0)
誰も困らんから。ユーザー少ないし、大したことに使っていない。
Re: (スコア:0)
誰もタレコミすらしないし、俺も含めてスラドのセキュリティ厳格なマカーは位置情報は完全ブロックしてるからこの機能自体使ってないのでどうでもいい
使えない (スコア:0)
＞Microsoft側は「Secure Time Seeding」が原因で問題が発生する場合、
＞複雑な要因が影響している可能性があるとして、必要に応じて機能を無効化することを推奨しているようだ。
原因がわかっているなら、原因が特定され修正されるまでは
機能を無効にし、他社の機能に置き換えるのが普通ですね。
複雑な要因じゃないんです。日付がくるってしまうのを回避しなければならない。
日付が狂うサービスなんて仕えたもんじゃないし、エンドユーザーが困るだけ。
エンドユーザーの立場になって考えてください。 お願いしますよ。
Re: (スコア:0)
日付時刻が変なActiveDirectoryサーバーのドメインに参加して、
手元のマシンの日付が変になったって言うようなもんだからなぁ。
全マシンの時刻が正しい環境ならこうならないと思うよ。
無効化手段も用意されてるしね。
Re: (スコア:0)
ドメインコントローラーの時刻が狂っているのは管理組織の責任だが、インターネット上のランダムなサーバーのせいとか言われたらそんなもの参照している方が悪いにしかならんだろ
Re: (スコア:0)
インターネットじゃなくて、イントラネットだからなあ
バグの原因がわからないと直せない (スコア:0)
放置ですかね？
Re: (スコア:0)
> バグの原因がわからないと直せない
普通そうだと思いますが...
もしかしてprintfを入れてみるんですか？
Re: (スコア:0)
普通に考えて、Microsoftの回答のことでしょ
Re: (スコア:0)
業務目的での損害はマイクロソフトが負担してくれそうもないので
普通は別な方法に差し替えるでしょうね。
Re: (スコア:0)
放置ですかね？
# なぜか2倍になるのでここで2で割る
的な修正を稀によく見るみたいな
Re: (スコア:0)
つか問題ではあるがバグではないでしょ