Apache HTTP サーバーで発見された、まだ修正されていない脆弱性により、一部の書き換えルールが適切に定義されていない場合、攻撃者が内部ネットワーク上の保護されたリソースにアクセスできるようになります。
この脆弱性は、負荷分散、キャッシュ、および複数のサーバーにわたるリソースの分散を伴うその他の操作に使用される構成の一種であるリバース プロキシ モードで動作する Apache インストールに影響します。
Apache HTTPD をリバース プロキシとして実行するように設定するために、サーバー管理者は mod_proxy や mod_rewrite などの専用モジュールを使用します。
Qualys のセキュリティ研究者は、特定のルールが正しく構成されていない場合、攻撃者がサーバーを騙して不正なリクエストを実行し、内部リソースにアクセスできるようになる可能性があると警告しています。
この問題は新しいものではなく、同様の攻撃を可能にする脆弱性は10月に修正されています。しかし、Qualysの研究員であるPrutha Parikh氏は、このパッチをレビューしていた際に、URI（Uniform Resource Identifier）スキームの除去手順にバグがあり、この脆弱性を回避できることに気付きました。スキームとは、http、ftp、fileなど、コロン「:」の前にあるURI部分のことです。
比較的一般的な書き換えおよびプロキシルールの一つに「^(.*) http://internal_host$1」があります。これはリクエストをマシンinternal_hostにリダイレクトします。しかし、このルールを使用し、サーバーが例えば「host::port」（コロン2つ）へのリクエストを受信した場合、「host:」の部分は削除され、残りの部分はhttp://internal_hostに追加されて内部転送されます。
問題は、この場合、残りの部分が「:port」であるため、転送されたリクエストが http://internal_host:port に変換され、保護されたリソースが公開される可能性があるという点です。
この問題を軽減するために、サーバー管理者は書き換えルールの $1 の前にスラッシュを追加する必要がある。正しい形式は「^(.*) http://internal_host/$1」だとパリク氏は述べた。
Apache開発者はこの問題を認識しており、現在、最適な修正方法について議論しています。一つの可能性としては、サーバーコードに以前のパッチを適用し、このようなリクエストを拒否するように強化することが挙げられますが、他の回避策が発見されないという保証はありません。
「この修正を改善することも可能ですが、mod_proxyとmod_rewriteのtranslate_nameフックを変更して、適切な場所で要件を強制する方が簡単だと思います」と、Red Hatのシニアソフトウェアエンジニア、ジョー・オートン氏はApache開発者メーリングリストで述べました。オートン氏はパッチを提案し、現在他の開発者によってレビューが行われています。
