パスワードを忘れた? アカウント作成
15531054 story
プログラミング

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」となっている。存在しない日付のバージョンとなるが、このまま新しいシーケンスでバージョン番号が割り当てられていくとのことだ。

これにより、新年早々対策に追われた人も多いようだ。スラドの皆さんはいかがだろうか。
  • Wikipediaの「年問題」記事 (スコア:4, おもしろおかしい)

    by Y-taro (38255) on 2022年01月03日 20時32分 (#4179209)

    年問題 - Wikipedia [wikipedia.org]
    には載ってないから、メジャーな懸念ではなかったのね。
    「2922億7702万6596年問題」とやらは載っているくせに。

    同じ32ビットの上限でいうと、西暦4桁で数値化した「2148年問題」とか年数単独で「21億4748万3648年問題」とかは懸念されていないのだろうか。
    「2922億7702万6596年問題」とやらは載っているくせに。

    ここに返信
  • by yamame (45241) on 2022年01月03日 17時34分 (#4179142)
    2021年12月33日
    ここに返信
  • by Suzuno (48093) on 2022年01月03日 17時44分 (#4179147) 日記

    草々 部門より

    仕様が酷くて草生える、という?
    (テストしてなかったのかしら)

    ここに返信
    • by Anonymous Coward

      実装されたのが大昔。どうせこんな機能すぐなくなるだろう。
      最悪そのうち誰かが直すだろう。でちーん。
      テストすれば見つかる問題なのでテストは無しでしょうね。
      あとシグネチャファイルの動作テストもしてなさそう。

      • by Anonymous Coward

        テスト環境のlongが64bitだった可能性もあり得なくはなくない?
        配布用とテスト用のバイナリが違うってことだから、やっぱりちゃんとテストとしないって話になるのかもしれないけど。

        • by Anonymous Coward

          windowsでlongが64bit幅な環境なんて存在すんの?
          そういうコンパイラを独自実装しました!とかは知らんが。

          • by Anonymous Coward

            この件で使ってる可能性はないがcygwinのgccはLP64
            この環境は、Windowsより、Linux由来コードとの互換のほうが大事だからな

  • by Anonymous Coward on 2022年01月03日 17時58分 (#4179152)

    昨日の夜、スラドにアクセスしても「ないです」と表示されるだけになってたのも同じ理由ですか?(すっとぼけ

    ここに返信
  • by Technobose (6861) on 2022年01月03日 18時33分 (#4179165) 日記

     日付の比較で数字を数値に変換して判定してるんですね。意外。
     てっきり日付型に変換して比較してるかと思ってました。

     ところで、桁に意味を持たせたコードって一般的だと思うんだけど、それを数値に単純に数値として扱うのって一般的なのでしょうか。
     仕事で業務システム間で連携するデータをEUCでやれという状況になってて、Access+VBAでプログラムを作ってます。
     データ交換の資料がCSVの項目しか無かったりで、メーカーのSEと相談することが多いけど、自社製品でユーザーIDは8桁の数字としていて、各桁に意味を持たせたりしてるのに、交換用データにする時は数値として扱うのが普通みたいで驚いてます。

    ここに返信
    • Microsoft CSVでは、「数値に見える文字列」は、たとえクォーテーションマークで括ってあっても数値として扱われます。
      そう言う事じゃないんでしょうか。

    • by Anonymous Coward

      文字列にするのも同程度に一般的かと。

      # JavaScriptで64-bitの整数IDが化ける

    • by Anonymous Coward

      各桁に意味を持たせたn桁の数字をIDとしたときに、CSVとして扱う過程で数値に変換されてバグるとか、まれによくあるやつですね。
      「12345678」を数値に直しても「123456789」のままだけど、「00001234」を数値に直すと「1234」になるので齟齬が生じるという。
      若いIDでテストしないと気付かないでスルーされちゃう。

    • by Anonymous Coward

      dnsのシリアルでは一般的な作法ですね。数値として(おおむね※)大小比較される前提で、日付を桁にエンコードします。

      ※単なる大小比較ではないので、注意。

  • 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日…ぷくく。

    ここに返信
  • by Anonymous Coward on 2022年01月03日 17時46分 (#4179149)

    Exchange Server使ってたとか?

    ここに返信
    • by Anonymous Coward

      記事に直接リンクかモバイルページから飛べば正常に表示されたけど、通常トップページは何度か記事が全くない状態になっていたな。
      とうとう閉鎖かと思った。

      • by Anonymous Coward

        エイプリルフールを正月にやるスラドてわりと違和感ないと思う

  • by Anonymous Coward on 2022年01月03日 17時57分 (#4179151)

    後10年程度しかOSの寿命はないわけで、毎日1つずつ増やしていっても十分余裕はあるか。

    あと、DNSのシリアル番号も32ビットだったな。こちらは符号なしだから大丈夫か。

    ここに返信
    • by Anonymous Coward

      機能更新ごとに最低1000は上がっているWindowsのビルド番号が心配。上限32767なのに。GetVersion(GetVersionExではない)を使うアプリがWin9xと誤判定してもいいなら65535まで延長はできる。まあすでに誤判定の危険がある16383は突破したから今さらかもしれない

  • by Anonymous Coward on 2022年01月03日 17時59分 (#4179154)

    スラドも記事の一覧が表示できない不調がありましたが、
    中の人は新年早々対策に追われた身だったりするのでしょうか?

    ここに返信
  • by Anonymous Coward on 2022年01月03日 18時12分 (#4179156)

    よく日付が埋め込まれているDNSゾーンファイルのSerial値は、同じ32ビットですが符号なしなので倍いけるようです。2147483647案件を見るたびに、なんで符号入れておくんだろう?と思うんです。

    ここに返信
    • by Anonymous Coward

      そして大小比較に減算を使ってバグるまでがセット。

      • by Anonymous Coward

        データ有効範囲を考えれば符号いらない!と思っても途中演算やらの都合でunsignedがバグにつながる事ってけっこうありますよね
        ※もちろんバグらない方法もあるけど安易にコードを書くと(ry
         while (cnt-- >= 0) {
          // 処理
         }

        • by Anonymous Coward

          そのパターンだとそもそも無限ループになるか一回も実行されないかのどっちかでは。

          • by Anonymous Coward

            C/C++の場合、もしループの中で副作用(volatile変数へのアクセスとか)がなかったら未定義動作になる。コンパイラーは、プログラムの実行はいつか終了するものと決めつけてコード生成していい。まあそうでなくては停止問題を解く羽目になりかねないから選択の余地はない

        • by Anonymous Coward

          ポインタの大小比較でundefined behaviorを踏むのでその形のループは書くなとあれほど

    • by Anonymous Coward

      if(error)
              return -1;

    • 単純にたいていのげんごは『int version』とか『long version』とやると符号がつく。深く考えてないとやらかす。そんだけのはなし。
      大体マイナスにならない項目に符号なし整数を使えと言うのは正しいがたいていの場合あんま考えてない人は異常値をマイナスにしたがるので対策としては微妙。
      ちゃんといつまでつかえるコードか考えましょう。期限が切れる前に何とかしましょう。これが常に完璧にできれば問題ない。常にとか完璧とかは不可能なので考えない。

      • by Anonymous Coward

        COBOL「やれやれ、これだから数値型が科学技術計算偏重の言語どもと来たら」

  • by Anonymous Coward on 2022年01月03日 19時44分 (#4179188)

    マルウェアスキャンエンジンがついてないの? サポート終了済み?

    ここに返信
typodupeerror

アレゲは一日にしてならず -- アレゲ研究家

読み込み中...