ほとんどのWebサーバーに影響するメジャーなサービス拒否脆弱性

作者 Jonathan Allen , 翻訳者 尾崎 義尚 投稿日 2012年1月5日

セクション

運用/インフラ

トピック

Glassfish ,

Ruby ,

アプリケーションサーバ ,

Java ,

動的言語 ,

ASP.NET ,

言語 ,

.NET ,

プログラミング ,

PHP ,

Vulnerabilities ,

Tomcat

共有 |

原文(投稿日：2012/01/03)へのリンク

セキュリティ研究者のAlexander Klink氏とJulian Wälde氏は、つい先日まで大部分のWebサーバーに影響を与える可能性のあった深刻な脆弱性を明らかにした。攻撃は、ハッシュコードの衝突を作り出すように設計されたPOSTフォームデータを送る、単一のHTTPリクエストだけである。最初にこの攻撃が発見されたとき、Python、Ruby、PHP、Java、ASP.NETが影響を受けたが、ベンダーは研究者と共同でパッチの開発を行った。

Tomcatアップデート 7.0.23と6.0.35は、POSTフォームのフィールドを10,000に制限することで、この問題に対処できる。変更ログには、この設定は変更可能と書かれているが、詳細は提供されていない。

ASP.NETのパッチは、12月29日に提供されている。このパッチは、デフォルトサービスポリシーのWindows Azureの顧客には自動的に適用される。このパッチは、単一のPOSTフォームフィールド数を、サービス拒否の攻撃に必要な数を下回る1,000に制限する。 appSettingsキーの“aspnet:MaxHttpCollectionKeys”によって、この値を設定することができる。現在、これはサイト全体にのみ適用できるが、ページを明示したオーバーライドに対してのリクエストがあった。修正には、JSON入力と逆シリアライズロジックの欠陥に関連するものも追加されている。

リリース候補のみのPHP 5.4.0もまた、max_input_varsディレクティブを提供している。リリースノートには、デフォルト値がなにかについて明記されていない。

今のところ私たちが議論してきたすべてのベンダーは、単一リクエストのフィールド数を制限することで、Webサーバーレベルの問題に対処している。他の選択肢は、文字列に対して、ランダム化されたハッシュコード計算を使うことである。Rubyは、その言語の一例である。.NETも同様のことをしているが、内部ビルドのみである。この問題の重要度によっては、次回のCLR更新時に現在の製品版で使用されている計算式が変更される可能性がある。開発者がすべてのバージョンをまたいで一貫性が維持されることを信頼しているはずなので、JavaのJVMで文字列のハッシュコード計算式を指定することはここまで簡単ではない。

Oracle Glassfishの更新はおそらく完了しているが、まだ公開されていない。この問題に対処する方法は、提示されていない。

この問題に関するより詳細な情報は、Ars TechnicaとChaos Communication CongressのWebサイトで提供されている。