いたさんのブログ

2009年9月のMicrosoftのセキュリティアップデートのうち、TCP/IP関連の３つの脆弱性を対象とするMS09-048が、延長サポート期間中のWindows 2000で提供されていない事に、海外で論議が起きているようです。

Microsoft: Patching Windows 2000 ‘infeasible’

翻訳をしてくれている方がいらっしゃいました。

MS09-048 の修正が Windows2000で出ない理由

マイクロソフトの情報も、夕方ようやく日本語訳がでました。

マイクロソフト セキュリティ情報 MS09-048 – 緊急

「Microsoft Windows 2000 のシステムには TCP/IP の保護を適切にサポートするアーキテクチャーが存在しないため、脆弱性を排除する Microsoft Windows 2000 Service Pack 4 用の更新プログラムを作成するのは極めて困難です。それを実現するには、影響を受けるコンポーネントだけではなく、Microsoft Windows 2000 Service Pack 4 オペレーティング システムの非常に多くの部分を再設計し直す必要があります。そのような再設計がなされた製品は、Microsoft Windows 2000 Service Pack 4 との互換性が不十分になり、Microsoft Windows 2000 Service Pack 4 で実行するように設計されたアプリケーションが更新されたシステムで引き続き稼働する保証がありません。」

というのが理由のようですが、後１年もしないうちにサポートが切れるので、いまさら修正したくないというのもあるのかもしれません。

また、気になるのが、上記のセキュリティ情報にあるWindows XPの扱いです。セキュリティアップデートは提供されてないのですが、FAQの「Windows XP の既定の構成がこの脆弱性の影響を受けないのはなぜですか?」に対して下記のような説明があります。

「既定で、Windows XP Service Pack 2、Windows XP Service Pack 3 および Windows XP Professional x64 Edition Service Pack 2 にはクライアント ファイアウォールで構成されたリスニング サービスが含まれていないため、この脆弱性の影響を受けません。サービス拒否が起きる場合、影響を受けるシステムにクライアント ファイアウォールで例外を持つリスニング サービスが含まれる必要があります。Windows XP Service Pack 2 およびそれ以降のオペレーティング システムには、ステートフル ホストのファイアウォールが含まれており、インターネットまたはプライベート ネットワーク上の近隣のネットワーク デバイスからの受信トラフィックに対する保護がコンピューターに提供されます。「脆弱性に関する詳細」のセクションの緩和策および回避策は、Windows XP Service Pack 2、Windows XP Service Pack 3 および Windows XP Professional x64 Edition Service Pack 2 にも適用します。」

「クライアントファイアウォールが有効になっており、それの例外としてパケット受信を行うサービスが設定されていると脆弱性が生じるが、Windows XPでは出荷時にはそのようなサービスは有効になっていないため、「安全」だ。クライアントファイアウォールが設定され、例外としてのサーバーサービスが構成された場合、回避策をとる必要がある。」というふうに解釈されるのですが、これってXPにアップデートが提供されない理由にはならないのでは？

[9/10追記]

マイクロソフトがセキュリティ情報を更新しました。Windows XPも脆弱性の対象になる事が明記されました。しかし、修正プログラムは提供されません。理由はこうです。

「サービス拒否の攻撃は、持続的な特別に細工した大量の TCP パケットを必要とし、それが停止するとシステムが回復します。このため、Windows XP についての深刻度を「注意」と評価しています。さらに、Windows XP Service Pack 2 およびそれ以降のオペレーティング システムには、ステートフル ホスト ファイアウォールが含まれており、インターネットまたはプライベート ネットワーク上の近隣のネットワーク デバイスからの受信トラフィックに対する保護がコンピューターに提供されます。Windows XP は CVE-2009-1925 の影響を受けません。」

攻撃が止めば回復するので深刻度が低いとの判断だそうです。うーん。

Ruby on RailsアプリケーションをBDDで開発する際の標準となった感のあるCucumberとRSpecですが、フィーチャやスペックを日本語で記述することになります。 Mac OS XやLinuxでは全く問題にならないのですが、Windowsの場合、UTF-8の出力をコンソールに表示する事が問題となります。 NetBeansを使えば、出力ウィンドウでUTF-8を表示可能ですが、特定のフィーチャを指定して実行する機能などがないため、実用てきではありません。

コードページ変更による方法

コマンドプロンプトのコードページを65001(UTF-8)にする方法もあるようですが、日本語表示フォントの設定がうまく行かなかったり、コマンド入力が正しく実行されなかったりして、手元の環境では使用できませんでした。

何度か試しているうちに気がついたのが、設定の順序です。次の方法だとうまく行くようです。

1. 日本語フォントを明示的に設定する
2. コードページを変更する

1は、コマンドプロンプトのウィンドウの左上をクリックして、「プロパティ」を選択し、「フォント」の設定を「MSゴシック」に変更します。

2は、コマンドプロンプトでchcp 65001と入力して、65001(UTF-8)に変更します。

win32consoleをハックする方法

Windows上で、RSpecや Cucumberのカラー出力をしようとするとwin32consoleをインストールするようにアドバイスされます。

このモジュール自体は、日本語に対応している訳ではなさそうですが、Win32::Console::ANSI::IO#_convをハックする事で、出力文字をShift-JISに強制変更させます。

require "Win32/Console" 
require "kconv" 
....
module Win32
  module Console
    module ANSI
      class IO < IO
....
        def _conv(s)
          if @concealed
            s.gsub!( /\S/,' ')
          elsif @conv
            if EncodeOk
              from_to(s, cpANSI, cpOEM)
            elsif @@cp == 'cp932cp932'
              s = s.tosjis
            elsif @@cp == 'cp1252cp850'      # WinLatin1 --> DOSLatin1
....
      end
    end
  end
end

ただし、この方法はコンソールに出力する場合のみコード変換を行うため、リダイレクトを行う場合にはうまく行きません。ZenTestのautotest(RSpecの場合のautospec)は内部でリダイレクトを行っているため、うまく行きませんでした。