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

マイクロソフト、緊急のセキュリティ更新プログラムを公開 21

ストーリー by hylom
年末年始開けの最初の仕事はアップデートか…… 部門より
headless 曰く、

マイクロソフトは12月30日、.NET Frameworkの脆弱性に関する緊急のセキュリティ更新プログラムを公開した(マイクロソフトセキュリティ情報 MS11-100Security Weekの記事本家/.)。

修正される4件の脆弱性のうち最も深刻なのは、特別な細工を施したWebリクエストをASP.NETサイトに送信することで攻撃者に特権の昇格が許可されるというもの。また、ハッシュテーブルの衝突によりDoSを引き起こす脆弱性も修正される。

ハッシュテーブルの脆弱性は12月28日にドイツで開かれた Chaos Communication Congressで発表されたもので、ASP.NET以外にもPHPやJavaなど多くのWebプログラミング言語が影響を受けるという(Ars Technicaの記事)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2011年12月31日 16時37分 (#2074744)

    修正された問題のうち、ハッシュテーブルの脆弱性について。

    リンク先を読むと、ASP.NET以外にJava/JavaScript/Perl/PHP/Pyhon/Rubyの各実装でも検証されており、その結果、PerlとRuby 1.9系以外のすべての言語実装で同様の脆弱性があることが報告されています。
    また、Ruby 1.8系については、報告を受けて既に脆弱性がふさがれたバージョンがリリースされているようです。
    (「Rubyの開発コミュニティはvery helpfulであり、この問題を真剣に受け止めてくれた」と謝辞が記されています。)

    というわけで、Ruby 1.8系とASP.NETベースのWebシステムの管理者はアップデートを検討したほうがいいかもしれません。

    他の言語のシステムは…どうしましょうね。
    まあDoS攻撃を容易にする類の脆弱性なので、標的にされたらあきらめる、という対応でも仕方ないかもしれません。
    いずれにしろDoS攻撃を完全に防ぐことはできませんし。

    • by Anonymous Coward on 2011年12月31日 17時21分 (#2074752)

      PHPについては以下のサイトに対策がまとまっています。
      脆弱性の中身が詳述されているので、他の言語の人にも役立つかも。

      徳丸浩の日記
      http://blog.tokumaru.org/2011/12/webdoshashdos.html [tokumaru.org]

      POSTの最大サイズを制限すればとりあえず大丈夫っぽい。

      親コメント
      • by Anonymous Coward

        Apacheでの対策については(Apacheを使っていれば)他言語で書かれたWebアプリケーションにも適用できそうですね。

      • by Anonymous Coward

        …いやその対策は大丈夫とは言い難いんじゃね?
        副作用で動かなくなるアプリケーションもあるだろうし、サーバ側で保持して連想配列化するようなプロパティは保護できないし。
        連想配列の実装自体が問題なんだから、連想配列の実装自体を変えない後付の対応は本質的に無意味なはず。
        言語実装レベルでの修正を待つのが正解で、この対策はDoSを被弾している真っ最中な本気の緊急事態に仕方なく適応するようなレベルの付け焼刃だと思う。

  • by tmmt (42080) on 2012年01月01日 11時55分 (#2074953) 日記

    このパッチ当てのためにPCがおかしくなって
    無駄に年末年始の仕事が増えたりしてる人
    いるんだろうなあ

    ご愁傷様です、しかしあけましておめでとうございます

    • by Anonymous Coward

      ハッシュテーブル周りの変更は完全にライブラリの内部実装の話のハズだから運悪くパフォーマンスが落ちることはあっても大した障害はなさそうだし、他の修正はサーバ用の機能だからまず問題ない。
      置き換えられるコンポーネントでDLL地獄(KB地獄と呼ぶべきかもしれないが)が起きない限りは問題ナシ。

      というか、サーバ用のモジュールの修正とサーバ動作のDoS回避修正だから、一般ユーザのPCに入れる意味はないんじゃないかなぁ…?

  • by Anonymous Coward on 2011年12月31日 11時53分 (#2074687)

    まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、
    中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。
    しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。

    これは.NETだけじゃなくJavaなんかもそうで、例えばLibreOfficeなんて現行最新版の3.4.4ですらJava7未対応、
    LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。
    「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。

    いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、
    最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。
    というかWORAという誇大妄想が消滅した瞬間に既に終わっていたのかも・・・・・・

    • by Anonymous Coward on 2011年12月31日 14時13分 (#2074720)

      > まして権限与えなければ、その権限以上のことができない通常の実行ファイルと違って、
      > 中間コードを実行してる核たる部分がセキュリティリスクになるんだから手に負えないわ。

       どの環境orOSでもそれ自体や、ライブラリに不具合があるのは普通だと思います。
       重要なのは、その不具合が放置されないことなので、修正された環境で再コンパイルが
      必要とかでなければ、悲観する必要はないと思います。

      > しかも中間コード自体にバージョン間で互換性が無いから、VMも多数管理しなきゃならない。

      .Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので
      普通にWindowsUpdateさえしていれば気にする必要はありません。
       また、Javaの場合ロードモジュールを実行するVMの管理が必用ですが、大抵のアプリケーションが
      インストーラとランチャの部分でVMのバージョンを意識しなくてよいようにしてくれている事が多いと思いますし、
      エンドユーザは、アップデータがあるので、言われたとおりバージョンアップしてればまず問題ないと思います。

      > LibreOfficeを利用する為には否応なくJRE6u30を入れとかなきゃない。
      > 「別にu29やu28でも良いんじゃね?」と思うだろう? ところがそいつらにはセキュリティホールが空いてるという体たらく。

      セキュリティパッチってそういうもんでしょ?
      これに関しては、何を使っててもおなじでは?

      > いわゆるスクリプト言語のように、中間コードに変換して実行しようと、そうでない場合と比べて本質的な違いがない場合はともかく、
      > 最終的な実行コードとして中間コードを使うのは、もうオワコンだなと痛感した。

       中間言語を含む、ロードモジュールを配布するタイプの言語で、コンパイラにバグがあって、ロードモジュールを
      再コンパイルしないといけない場合以外、スクリプト言語を使ってても、結局実行環境に問題があれば同じだと思います。
      だけだと思いますが?

       そういう意味では、今回の件は、悲観する必要ないと思います。

      親コメント
      • by Anonymous Coward

        .Netは、モジュールのローダがロードモジュールのバージョンを意識しないで良いようにしてくれているので
        普通にWindowsUpdateさえしていれば気にする必要はありません。

        普通はそうなんですが、ビルドした環境のランタイムのほうがあたらしければ古いランタイムを持つ環境では期待した動作しないことはままありますよ。
        ILが異なるのは勿論、挙動から変わる場合があります。大体は元の動作が仕様に沿ってないしろものだったりしますが。
        # それはそれでリリースノートに書いてほしい・・・
        なので開発者は注意しないと入らぬ苦労を背負います。

        まぁ普通の人は無関係だわな。

    • 核たる部分がセキュリティリスクになるんだから手に負えないわ

      親コメント
    • by Anonymous Coward
      巨大なライブラリやフレームワークの保守で,問題が起こるのはその通りだが,中間言語と何の関係があるんだ?
      コンパイラやインタプリタ,ランタイムに欠陥があるのと,何も違わないだろ.

      それらの欠陥が嫌なら,アセンブリ言語や機械語直書きでどうぞ.
      もちろんOSやライブラリは使わないでね.
      • by Anonymous Coward

        んでバッファオーバーランとかやらかしちゃうんだよね。

      • by Anonymous Coward

        車輪の、、、で、バグだらけ!

        「機械語」なんて用語を見るの、何年ぶりだろ?

    • by Anonymous Coward

      それを言い出したらOSなんてセキュリティリスクの塊ですね。
      古いOSじゃないと動作が完全でない、とか
      新しいOSでないと同上、とかも普通のことですし。

    • by Anonymous Coward

      やはりCで使うのライブラリを枯らして使うのが一番安全で効率的かにゃあ。

      • by Anonymous Coward

        Cの自由さが原因の1つなんだけどな。

        • by Anonymous Coward

          任意コード実行可能なセキュリティホールの存在が言語仕様上許されているとかフリーダムにもほどがあるよね。他のまともな高級言語では「処理系のバグである」と断言できるんだが。

    • by Anonymous Coward

      こんな見え見えのトラップに多数の/.erが引っかかるなんてスラドもオワコンだと痛感した……

      # か?
      # ツッコミどころを集めていくと書いた人のプロフィールに繋がるという年末年始のパズルかな?

      • by Anonymous Coward

        >こんな見え見えのトラップに

        トラップはぱっと見トラップだと分かるようにされているからトラップ足りえるもの。
        そうでないのはただの馬鹿、または天然信者や天然アンチです。

typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...