Posted by & filed under 開発.


追記
タイトルが微妙にミスリーディングだったかもしれません。RangeヘッダのCVE-2011-3192はリバースプロキシとは無関係に起きる問題です。

Rangeヘッダの問題(CVE-2011-3192)が大きすぎて、Apacheにある他のリバースプロクシの問題の影が薄いので書いておきます。きっかけは、このITmediaの記事です。ふたつの別個の問題を混在して伝えている気がするからです(書き方が思わせぶりで詳細を書かないので真相は不明ですが)。

Apacheをリバースプロクシで使った時に次のふたつの問題が最近見つかっています。

前者のCVE-2011-3348のバグ情報はこれです。

mod_proxy_ajpとmod_proxy_balancerを組み合わせた時に起きる問題なので、組み合わせ的には微妙にレアと言えばレアですが、細工したリクエストを送れば簡単にDoS攻撃が可能なので狙われればアウトです。もっとも、CVE-2011-3192のDoS攻撃でメモリを食い尽くされるひどさに比べると、CVE-2011-3348の場合、mod_proxy_balancerがretryを繰り返すだけなので多少マシかもしれません。

問題は最新のv2.2.21で修正済みです。最新版へのバージョンアップ以外の回避策はありません(バージョンアップ以外の暫定的な回避策は、mod_proxy_balancerのretryタイムアウトを短くする設定ぐらいでしょうか。被害は減らせそうです)。

コードの修正を見ると原因はエラー処理です。ただエラー処理自体は元からあります。致命的なエラーにするか否かの判断ミスです。致命的なエラーであればmod_proxy_balancerはretryしませんが、そうでなければretryします。外部からの不正リクエストは致命的エラーにすべきところをしていないため、retryが繰り返されるDoS攻撃が可能になる、というシナリオです。

これは事前にコードだけ見ても見つけるのは困難だろうと思わせるバグです。エラー処理はきちんとしているからです。致命的か否かの判断の漏れがあっただけです。と言うより、これはApacheだから見つかる問題で、世の中の分散処理のコードで冗長性のためにretryするロジックを入れているコードだったら、類似の問題はどこに隠れていてもおかしくないと思われるぐらい発見困難な問題だと思います。

後者のCVE-2011-3368のバグ情報はこれです。

mod_proxyと特定の設定で起きます。最新のv2.2.21でも未修正です(パッチは存在するので次のv2.2.22で修正されるでしょう)。該当する設定を書き換えれば回避できます。

次のようなパターンの設定で問題が起きます。この設定の意図はApacheが受けたリクエストをリバースプロクシで内部サーバ(internalserver)にそのまま投げる動作です。リバースプロクシとしてはそれなりにありふれた設定な気がします。

知っている人には自明だと思いますが、念のため書くと、RewriteRuleとProxyPassMatchの両方を書いたという意味ではなく、どちらでもです。そもそもふたつの設定は同じ動作の設定なので、通常、どちらかを書きます。

下記のように書き換えると回避できます。

面白いと言うと不謹慎ですが、なかなか興味深い攻撃方法です。

のようなリクエストを送ると、リバースプロクシ設定の書き換え結果が次のようになります。

このURLはtarget.example.comのホストにinternalserverのユーザでアクセスするという意味になります。この結果、target.example.comにリバースプロクシが向いてしまいます。見せたくない内部サーバのホスト名を書かれると、リバースプロクシのApacheを踏み台にして外部からアクセスされうる、というシナリオです。


関連文書:

  • 関連文書は見つからんがな

Comments are closed.