Exchange Server、新年早々「2201010001」を long に変換できないエラー 147
ストーリー by headless
草々 部門より
草々 部門より
Microsoft Exchange Server 2016 / 2019 のマルウェアスキャンエンジンで「2201010001」を long に変換できないというエラーが発生して電子メールメッセージがトランスポートキューにたまる事態となった
(Exchange Team Blog の記事、
Neowin の記事、
On MSFT の記事、
BleepingComputer の記事)。
Microsoft によると「2201010001」はマルウェアスキャンエンジンで使用するシグニチャファイルのバージョンだという。バージョンの先頭 6 桁は YYMMDD であり、2021年までは問題なかったものの、2022年の日付のバージョンでは long (int32) の最大値 2,147,483,647を超えて問題が発覚したようだ。
Microsoft は自動または手動でスキャンエンジンを削除してから最新版へ更新する手順を紹介しており、新しいバージョンは「2112330001」となっている。存在しない日付のバージョンとなるが、このまま新しいシーケンスでバージョン番号が割り当てられていくとのことだ。
これにより、新年早々対策に追われた人も多いようだ。スラドの皆さんはいかがだろうか。
Microsoft によると「2201010001」はマルウェアスキャンエンジンで使用するシグニチャファイルのバージョンだという。バージョンの先頭 6 桁は YYMMDD であり、2021年までは問題なかったものの、2022年の日付のバージョンでは long (int32) の最大値 2,147,483,647を超えて問題が発覚したようだ。
Microsoft は自動または手動でスキャンエンジンを削除してから最新版へ更新する手順を紹介しており、新しいバージョンは「2112330001」となっている。存在しない日付のバージョンとなるが、このまま新しいシーケンスでバージョン番号が割り当てられていくとのことだ。
これにより、新年早々対策に追われた人も多いようだ。スラドの皆さんはいかがだろうか。
Wikipediaの「年問題」記事 (スコア:4, おもしろおかしい)
年問題 - Wikipedia [wikipedia.org]
には載ってないから、メジャーな懸念ではなかったのね。
「2922億7702万6596年問題」とやらは載っているくせに。
同じ32ビットの上限でいうと、西暦4桁で数値化した「2148年問題」とか年数単独で「21億4748万3648年問題」とかは懸念されていないのだろうか。
「2922億7702万6596年問題」とやらは載っているくせに。
Re:Wikipediaの「年問題」記事 (スコア:2)
英語版Wikipediaの記事 [wikipedia.org]でもYear 2022の項が足されたのは今年に入ってからだったようだ。
Re:Wikipediaの「年問題」記事 (スコア:2)
なるほど。
日本語版でも今朝、本件が記載されました。
Re:Wikipediaの「年問題」記事 (スコア:1)
「2000年過ぎたしこのシステムは過去の日付を扱わないからあと100年は大丈夫だぜ!」
Re:Wikipediaの「年問題」記事 (スコア:1)
1999年4月1日にはすでに想定されている
http://www.cam.hi-ho.ne.jp/mendoxi/rfc/rfc2550j.html [hi-ho.ne.jp]
Re:Wikipediaの「年問題」記事 (スコア:2)
Wikipediaは、編集者個人の主張を書くところではない [wikipedia.org]んですよ。
私個人が懸念を持っているかどうかは全く問題ではなく、信頼できる情報源 [wikipedia.org]の形で、そのような情報が公表されていたかどうかが問われます。
私の元コメは、私が懸念しているとも、Wikipediaに何かを記載すべきとも書いていません。
Re:Wikipediaの「年問題」記事 (スコア:2)
本件事例について、適当なニュース記事等を出典に記載することはできるでしょう。
本件事例を記事に記載するかどうかについては、私は元コメでは全く言及していません。
私が元コメで記事に記載されていないことに言及したのは、本件より前に、本件のような処理方法と、派生して私が思いついた第2段落の処理方法が記載されていないことを確認した部分です。
本件より前に、私が、本件のような処理方法の問題点に気付いたとしても、それだけでは出典のない独自研究ですので、Wikipediaに記載することはできません。
第2段落の方は、今なお出典とすべき適当な情報が見つけられないので、やはり独自研究です。
独自研究を禁じたルール上、編集者がWikipediaに情報を記載するにあたっては、そのような情報が公表されていたかどうかがコミュニティから問われます。
「『2922億7702万6596年問題』とやらは載っているくせに。」とは、「メジャーな懸念ではなかった」ということの比較対象としてが3分の1、「おもおか」が3分の1。
そして、到底「問題」とはいえないどうでもいいことを「問題」として記載していることの揶揄が3分の1です。
「くせに」という言葉の矛先を挙げるならば、これを記載した人。
この点でいうと、「自分が書け」ではなく、「自分が消せ」の方が、まだ指摘として筋が通っていましたね。
あなたは、私の元コメのどの部分から、私が何をWikipediaに記載するよう求めていると読み取りましたか。
Re:Wikipediaの「年問題」記事 (スコア:2)
Wikipediaは「編集者個人の主張かどうかは、まず、記事を投稿して、コミュニティに諮らなければチェックが始まらない」などという仕組みではありません。
Re:Wikipediaの「年問題」記事 (スコア:2)
個別ソフトの話はなく、日付データの処理方法一般の話ですよ。
「2000年以降に西暦下2桁から始まる10桁の数字列を32ビット符号付整数型に変換したとき、2022年に型の上限値を超える」という。
（理屈としては和暦でもいいのだろうけど。）
技術規格やプラットフォームの制限数値の問題だけでなく、「日付データをある方法で処理したとき、ある年（時）に問題がおきる」という、「年問題」記事で解説されいてる範疇の話でしょう。
2000年問題からしてそうですし、記事にあるものだと、1999年問題、2001年9月9日問題も該当しますね。
Re:Wikipediaの「年問題」記事 (スコア:2)
該当事例が複数なければ一般論ではない、ということにはなりませんよ。
僕の冬休み (スコア:1)
部門名 (スコア:1)
草々 部門より
仕様が酷くて草生える、という？
（テストしてなかったのかしら）
Re: (スコア:0)
実装されたのが大昔。どうせこんな機能すぐなくなるだろう。
最悪そのうち誰かが直すだろう。でちーん。
テストすれば見つかる問題なのでテストは無しでしょうね。
あとシグネチャファイルの動作テストもしてなさそう。
Re: (スコア:0)
テスト環境のlongが64bitだった可能性もあり得なくはなくない？
配布用とテスト用のバイナリが違うってことだから、やっぱりちゃんとテストとしないって話になるのかもしれないけど。
Re: (スコア:0)
windowsでlongが64bit幅な環境なんて存在すんの？
そういうコンパイラを独自実装しました！とかは知らんが。
Re: (スコア:0)
この件で使ってる可能性はないがcygwinのgccはLP64
この環境は、Windowsより、Linux由来コードとの互換のほうが大事だからな
ないです (スコア:1)
昨日の夜、スラドにアクセスしても「ないです」と表示されるだけになってたのも同じ理由ですか？（すっとぼけ
Re: (スコア:0)
「もうない」じゃなかった？
Re: (スコア:0)
内容までは覚えてないけど、エラー表示は２～３パターンぐらいあってリロードするたびに変わってた
Re:ないです (スコア:1)
数字と数値 (スコア:1)
日付の比較で数字を数値に変換して判定してるんですね。意外。
てっきり日付型に変換して比較してるかと思ってました。
ところで、桁に意味を持たせたコードって一般的だと思うんだけど、それを数値に単純に数値として扱うのって一般的なのでしょうか。
仕事で業務システム間で連携するデータをEUCでやれという状況になってて、Access+VBAでプログラムを作ってます。
データ交換の資料がCSVの項目しか無かったりで、メーカーのSEと相談することが多いけど、自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに、交換用データにする時は数値として扱うのが普通みたいで驚いてます。
Re:数字と数値 (スコア:1)
Microsoft CSVでは、「数値に見える文字列」は、たとえクォーテーションマークで括ってあっても数値として扱われます。
そう言う事じゃないんでしょうか。
Re: (スコア:0)
文字列にするのも同程度に一般的かと。
# JavaScriptで64-bitの整数IDが化ける
Re:数字と数値 (スコア:2)
> JavaScriptで64-bitの整数IDが化ける
ちょっと話は変わるけど、VBAは符号無しの数値型が無いですね。
困ったのがutf-8で外字かどうかの判断。
私用領域（外字範囲）の途中から補数で負になってしまうため、文字コードを範囲指定できないのですね。
仕方なく正規表現で判断するようにしたけど、何か方法があるのかしら。
Re:数字と数値 (スコア:1)
> Unicodeの区別がついていないとかそういうレベルの混乱を疑っている
御明察のとおりです。それとデータ交換する歳の外字についての話です。
(文字集合でUnicode,文字エンコードでutf-8)のつもりでutf-8と書いてました(日本語でutf-8を使うならUnicodeだろうという思い込みで)。
Re:数字と数値 (スコア:1)
つ BigInt
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_... [mozilla.org]
# BigIntが使えないブラウザの対応を止めるのは駄目なんだろうなぁ
Re: (スコア:0)
各桁に意味を持たせたn桁の数字をIDとしたときに、CSVとして扱う過程で数値に変換されてバグるとか、まれによくあるやつですね。
「12345678」を数値に直しても「123456789」のままだけど、「00001234」を数値に直すと「1234」になるので齟齬が生じるという。
若いIDでテストしないと気付かないでスルーされちゃう。
Re:数字と数値 (スコア:4, おもしろおかしい)
ちょっと待て
Re: (スコア:0)
> まれによくあるやつですね。
さすがに桁数が増えるのはないかなぁ。
Re: (スコア:0)
dnsのシリアルでは一般的な作法ですね。数値として(おおむね※)大小比較される前提で、日付を桁にエンコードします。
※単なる大小比較ではないので、注意。
TrendMicroと採番体系を比較・・・そして設計レビュー観点の一助としての考察 (スコア:1)
TrendMicroが2021年から新しい採番体系を採用している [trendmicro.com]。
まあ、製品自体への批評は抜きとして、採番体系について、
以下の部分をMS社はTrendMicro社を見習うべきだった。
1)年・月・4桁と、日を入れてない。
…内部管理含めて
ひと月に9999回も値を更新することすら考えにくいのに、
MS社は1日に9999回も更新することがあると本気で考えているのだろうか？
まず、現実的な値域を想定すべきだろう。
2)1月～12月を550～620とした。
…バージョン番号の採番方法として、中間値から始める手法がある。
A～ZならNから始める、などだ。
というのも、メジャーバージョンを変えられないとき、
万が一バージョンを下げたいニーズがあった場合でも対応できるようにするため。
DBのマスタとか、コード体系を決めるときには一般的だが、
TrendMicroのケースだと、年の途中にバージョンチェックに関わる大改造を
しなければならなくなった際に、1xx～、3xx～、7xx～と、4つの別体系を
入れ込む余地がある。
例えば、WindowsのSIDは「ユーザーID」という括りの中で、
さらに区分けをするため、Administratorに500、Guestに501を割り当て、
ユーザーやグループを1000から採番するようにしている [itmedia.co.jp]。
3)末尾4桁を1000から始める。
…Exchange ServerのS/W設計者の最もダメな点。
1000以上から始めることで、ゼロサプレス／パティングによらず、
必ず4桁になる。
これによって、
・文字として連結する時の桁数の数え誤り、
・JavaScriptで処理するときの「0始まり(かつ2文字目が7以下)は8進数」の考慮もれ、
・表示形式を変えないときのExcelのゼロサプレスの考慮もれ、
等に伴う実装ミスを避けることが出来る。
S/W設計者として、Exchange Serverの検知エンジンを作った人はちょっとどうかと思った。
12月33日…ぷくく。
スラドも新年早々アクセス不調だったけど (スコア:0)
Exchange Server使ってたとか？
Re: (スコア:0)
記事に直接リンクかモバイルページから飛べば正常に表示されたけど、通常トップページは何度か記事が全くない状態になっていたな。
とうとう閉鎖かと思った。
Re: (スコア:0)
エイプリルフールを正月にやるスラドてわりと違和感ないと思う
1つずつ増やしていくならあと3500万回 (スコア:0)
後10年程度しかOSの寿命はないわけで、毎日1つずつ増やしていっても十分余裕はあるか。
あと、DNSのシリアル番号も32ビットだったな。こちらは符号なしだから大丈夫か。
Re: (スコア:0)
機能更新ごとに最低1000は上がっているWindowsのビルド番号が心配。上限32767なのに。GetVersion(GetVersionExではない)を使うアプリがWin9xと誤判定してもいいなら65535まで延長はできる。まあすでに誤判定の危険がある16383は突破したから今さらかもしれない
「スラドの皆さんはいかがだろうか」じゃあないよ (スコア:0)
スラドも記事の一覧が表示できない不調がありましたが、
中の人は新年早々対策に追われた身だったりするのでしょうか？
Re:「スラドの皆さんはいかがだろうか」じゃあないよ (スコア:1)
なるほど「スラド（の中の人）の皆さんはいかがだったでしょうか」って意味か
符号、要ります？ (スコア:0)
よく日付が埋め込まれているDNSゾーンファイルのSerial値は、同じ32ビットですが符号なしなので倍いけるようです。２１４７４８３６４７案件を見るたびに、なんで符号入れておくんだろう？と思うんです。
Re: (スコア:0)
そして大小比較に減算を使ってバグるまでがセット。
Re: (スコア:0)
データ有効範囲を考えれば符号いらない！と思っても途中演算やらの都合でunsignedがバグにつながる事ってけっこうありますよね
※もちろんバグらない方法もあるけど安易にコードを書くと(ry
while (cnt-- >= 0) {
// 処理
}
Re: (スコア:0)
そのパターンだとそもそも無限ループになるか一回も実行されないかのどっちかでは。
Re: (スコア:0)
C/C++の場合、もしループの中で副作用(volatile変数へのアクセスとか)がなかったら未定義動作になる。コンパイラーは、プログラムの実行はいつか終了するものと決めつけてコード生成していい。まあそうでなくては停止問題を解く羽目になりかねないから選択の余地はない
Re:符号、要ります？ (スコア:1)
そこらへんの文言を入れた理由も書いてあるから、N1528を読め。
それでもなおmay be assumed が書いてあるから未定義だと思うのなら、そう思った根拠付きでcommiteeに言ってやれ。
Re: (スコア:0)
ポインタの大小比較でundefined behaviorを踏むのでその形のループは書くなとあれほど
Re: (スコア:0)
if(error)
return -1;
入れてない。何も考えずにやると勝手に入るだけ。 (スコア:0)
単純にたいていのげんごは『int version』とか『long version』とやると符号がつく。深く考えてないとやらかす。そんだけのはなし。
大体マイナスにならない項目に符号なし整数を使えと言うのは正しいがたいていの場合あんま考えてない人は異常値をマイナスにしたがるので対策としては微妙。
ちゃんといつまでつかえるコードか考えましょう。期限が切れる前に何とかしましょう。これが常に完璧にできれば問題ない。常にとか完璧とかは不可能なので考えない。
Re: (スコア:0)
COBOL「やれやれ、これだから数値型が科学技術計算偏重の言語どもと来たら」
Exchange Server 2013以前は? (スコア:0)
マルウェアスキャンエンジンがついてないの? サポート終了済み?
Re:何もしてないのに壊れた (スコア:2, すばらしい洞察)
年とって仲間入りしただけだよ・・・