Apacheにセキュリティホール 25
ストーリー by wakatono
影響を受けるマシン、激烈に多数 部門より
影響を受けるマシン、激烈に多数 部門より
MITsu_at_mit-net 曰く、 "多分いっぱいたれこみあるだろうけど。 ZDNN：ニュース速報によると、デフォルトで有効 になっている機能にサービス拒否（DoS）攻撃に対する脆弱 性が存在するそうです。 記事によると、影響を受けるのは1.3.24まで のApache 1.3全バージョンと、2.0.36までのApache 2の全バ ージョンとのこと。 色々作業しなきゃならない人がいっぱい出てきそう。"
Apache.orgからAdvisoryもリリースされている。避ける方法がないだけに、早期のFIX Versionのリリースが望まれる。
Apacheのadvisoryの日本語訳 (スコア:5, 参考になる)
http://httpd.apache.org/info/security_bulletin_20020617.txt より翻訳
Date: 2002年6月17日
Product: Apache Web Server
Versions: Apache 1.3 （1.3.24を含む全てのバージョン）, Apache 2
（2.0.36までの全てのバージョン）, Apache 1.2 （1.2.2以前の全バージョン）
はじめに:
Mark Litchfield氏が、Oracleの脆弱性をテストしている際に、Windows上の
ApacheにおいてDoS攻撃を発見した。Apache Software Foundationの調査によ
り、これはもっと広範なもので、あるプラットフォームではDoS脆弱性をもた
らすものの、別のプラットフォームではリモートexploit脆弱性の可能性をひ
きおこすものであることが示された。
我々はまた、本日、ISSから、彼らが同じ件を公表したことを知らされ、この
勧告の早期リリースを迫られることとなった。
Common Vulnerabilities and Exposuresプロジェクト(cve.mitre.org)は、こ
の件にCAN-2002-0392という名前を割り当てた。
解説:
Apacheウェブサーバの1.3.24を含むそれ以前と、2.0.36を含むそれ以前のバー
ジョン2.0、また、2.0.36-devのバージョンは、chunked encodingによりエン
コードされた不正なリクエストを取り扱うルーチンにバグを持っている。この
バグは、入念に組み立てられた不正なリクエストをリモートから送られること
により誘発され得る。この機能はデフォルトで作動可能状態となっている。
たいていのケースでは、この不正なリクエストの結末は、そのリクエストを取
り扱っている子プロセスの終了となる。少なくとも、このことは、親プロセス
が結局は終了させられた子プロセスを取り替えねばならなくなり、無視できな
い量のリソースを使用する新たな子プロセスを起動することによって、リモー
トの攻撃者がDoS攻撃を仕掛けることを手伝い得る。
WindowsおよびNetwareプラットフォームでは、Apacheは、リクエストをサービ
スするために、マルチスレッド化されたひとつの子プロセスを走らせる。崩壊
と続く失われた子プロセスを取り替えるセットアップの時間は、著しいサービ
スの中断をもたらす。WindowsとNetware版は、子プロセスをforkするのでなし
に、新たなプロセスを生成し、設定を再読込みすることから、この遅延は、他
のプラットフォームに比べてより著しいものとなる。
Apache 2.0においては、このエラー条件は正しく検出されるため、これは、攻
撃者にサーバ上で任意のコードを実行させることを許すことにはならない。し
かし、プラットフォームは、子プロセスごとに複数のリクエストのマルチスレッ
ドモデルを使っていることもあり得る（デフォルト設定は、単一スレッドで複
数プロセス、かつ、プロセスごとにリクエストとなっているけれども、たいて
いのマルチスレッドモデルは、複数の子プロセスを生成し続ける）。どのマル
チスレッドモデルを使っても、影響された子プロセスで処理されているすべて
の同時発生のリクエストは、失われることになる。
Apache 1.3においては、この件はスタックオーバーフローを引き起こす。32ビッ
トUnixプラットフォームにおけるオーバーフローの特性により、これは、
segmentation violationを引き起こし、子プロセスが終了することになる。し
かし、64ビットプラットフォームにおいては、そのオーバーフローは制御され
得るもので、そのため、スタックにリターンアドレスを格納するプラットフォー
ムにとっては、それはさらにexploitableとなるだろう。これは、そのサーバ
上で、Apacheの子プロセスを走らせるユーザの権限で、任意のコードを走らせ
ることを許し得る。
我々は、この方法によりWindows上のApache 1.3がexploitableであることを承
知している。
ISSによって提供されているパッチがこの脆弱性を修正しないことに注意して
ほしい。
Apache Software Foundationは、この件を修正する新たなリリースに向けて現
在作業中である。アップデートバージョンについては、こちらを見てほしい。
http://httpd.apache.org/
ちょっと面倒なことになってるらしい。 (スコア:2, 参考になる)
1)Windowsと64-bit *nixは、外部から任意のコードが実行される可能性がある。
2) 32-bit *nixは、任意のコードが実行される心配は少ないが、httpdのサブプロセスが、SIGSEGVで落ちて再起動する。
ということなので、32-bit *nixでも繰り返しプロセスが落されてDOS攻撃される可能性は残っているそうです。ただ、CVSで既に修正(Apache2.0のみ)されているはずのものをISSがバグとして公表したらしく、話がややこしくなっているようです。
完全には修正できていないらしいのですが、 とりあえずは続報待ちって所ですかねぇ、、、。
//Re:ちょっと面倒なことになってるらしい。 (スコア:1)
>ただ、CVSで既に修正(Apache2.0のみ)されているはずのものをISSがバグとして公表したらしく、話がややこしくなっているようです。
ISS社のFUD?いや、知らんけど。
以前SNORTにセキュリティホールがあるとの情報が流れた事がありましたが、 [srad.jp]それは現場ではまずしないであろう設定にしている場合に限られるバグであって、報道(?)はISS社によるFUDにすぎないと開発者に喝破されています。
今回のをFUDというと少々言い過ぎかもしれないけれども、セキュリティ関係の企業としてはこういう情報を流せば点数を稼げるだろうから、バグフィックスの途上であろうとなかろうと遠慮なく公表するんだろうな、と思うのです。
#ちなみに、「Please note that the patch provided by ISS does not correct this vulnerability. [apache.org]」...ISSが「対策パッチ」を配ってるけど、役立たずだって。ホント?
gy0
Re:ちょっと面倒なことになってるらしい。 (スコア:2, 参考になる)
Apache 1.3 のほうの修正は src/main/http_protocol.c 1.317 [apache.org], 1.318, 1.319 が関係ありそうです。
（ちなみに、 2.0 のほうの修正は modules/http/http_protocol.c 1.438 [apache.org], 1.439 だと思います。）
ぱっとコードを見たところ、バグ自体は単純なもののように見えますが、こういうバグが一つ入り込むだけで弱点になってしまうので、つくづく、サーバを書くのは大変だと思います。
// ぼくは Apache のコードを真面目に読んだことなどないので、間違ったことを言っている可能性、大です。
鵜呑みにしてみる？
32bit Unix でも任意のコードを実行可能 (スコア:2, 参考になる)
Solaris 6-8 (sparc/x86)、FreeBSD 4.3-4.5 (x86)、
Linux (GNU) 2.4 (x86)、OpenBSD/i386
などでも exploit に成功した模様。
DoS だけか～と安心していた皆様、お気をつけください。
Re:32bit Unix でも任意のコードを実行可能 (スコア:0)
マジかよ。
OpenBSD神話崩壊?
patch (スコア:1)
ここにあるパッチを当てれば解決されるのではないでしょうか？
http://www.apache.org/dist/httpd/patches/apply_to_1.3.24/proxy_http1.1_chunking.patch
Re:patch (スコア:1)
鵜呑みにしてみる？
fixまでに時間がかかると (スコア:1)
「この機能」はデフォルトで有効 (スコア:1)
鵜呑みにしてみる？
Re:「この機能」はデフォルトで有効 (スコア:1)
Re:「この機能」はデフォルトで有効 (スコア:2, 参考になる)
だとすると、 SetEnv ディレクティブ [apache.org] で適切な環境変数 [apache.org]を設定して、 HTTP/1.0 サーバとして振る舞うように強制してやれば、 chunked transfer coding を使った request を解釈しないようになるのかもしれません。 downgrade-1.0 や force-response-1.0 という環境変数を設定すると Apache の動きがどう変わるのかを知らないので、これでうまくいくかどうかわかりませんが。副作用も大きそうですし。
やっぱり修正されたバージョンが出るまで静観かな……。
鵜呑みにしてみる？
Re:「この機能」はデフォルトで有効 (スコア:1)
NameBasedVirtualHostが使えなくなるので、
ホスティングサイトにとってはかなりイタイと思われ・・・。
GUST NOTCH な気分でいこう!
Re:「この機能」はデフォルトで有効 (スコア:1)
# どちらにしろ、 agent からは HTTP/1.1 リクエストが送られてきますし
HTTP/1.0 でリクエストされた時も Host ヘッダさえきちんと付いていれば VirtualHost 処理されますよん。
Re:「この機能」はデフォルトで有効 (スコア:1)
ということで、 #109581 を読んで何も考えずにいきなり httpd.conf に「SetEnv downgrade-1.0」とか書かないように！ これで弱点が回避できるかどうか、ぼくにはわかりませんし、副作用はいろいろ考えられます。まさかそんな無謀な人はいないでしょうが、念のため。
鵜呑みにしてみる？
1.3.26出ました (スコア:1)
例の問題はFIXされた模様です。
急いで入れ替えなければ・・・。
GUST NOTCH な気分でいこう!
影響の範囲 (スコア:0)
# だって1.3.25まだ上がってないから(T-T
Re:影響の範囲 (スコア:1)
だからUNIX 32bit版では、乗っ取られることはないんじゃないかと思われますが．．．．。
それとデフォルトで有効になっている機能（requests which are encoded using chunked encodingを受け付ける機能）を無効にしたらどうなるかが見当たらないのと、httpd.confのどの設定なのかがイマイチよく判りません。
Re:影響の範囲 (スコア:4, 参考になる)
>this will cause a segmentation violation and the child will terminate.
ということな様子。
全体としては、
1.3/2.0共に、Windows/Netware/32-bitUNIX/64-bitUNIX なんかだと、
「処理をしていた子供(微妙)が死亡する」ので、
「プロセスの上げなおしに資源を奪われ」たり「同一プロセスが処理している他の接続がうしなわれ」たり、しますが、
1.3で 64bit-UNIXを利用している場合には、「（プラットフォームによっては）のっとられる可能性があります」
な感じではないのかな？
全てのケースが網羅されて説明されてるわけではなさそうなので、
多少微妙なところはある様子。
-- LightSpeed-J
Re:影響の範囲 (スコア:2, 参考になる)
ただ、子プロセスが落とされて立ち上げ直す、というのを繰り返したからといって、資源がどんどん減っていくようなことってあるのでしょうか。プロセスを fork するときに一時的に資源を食うだけなら DoS にはなりませんよね。
それと、 32-bit Unix と 64-bit Unix で何が違うのかもよくわかりません。 #109768 [srad.jp] にも書いた ISS のコメント「ISS X-Force response (fwd)」 [neohapsis.com] には、 32-bit Unix のほうが任意コード実行可能の弱点を exploit しやすそうに見えるが、それでも無理、と書いてあるように見えるので、 Apache Project の説明との違いに驚いています。
ISS と Apache Project の言っていることはほかにもいろいろ食い違っています。どうしてこんなに違うのか、という点が一番よくわからないのですが……。
鵜呑みにしてみる？
Re:影響の範囲 (スコア:1)
CNET Japan [sphere.ne.jp]に今回の経緯が掲載されています。
どうもISSはろくに確認もせずに大騒ぎをした模様。
Re:影響の範囲 (スコア:1)
ISS が今回の弱点について、 Windows 版以外は DoS しかできないという間違った判断をして、悪影響の大きさを考えずに公表したということのようですが、その背後にはもともと ISS が Apache 開発チームを信頼していないということがあるようですね。
ISS が間違った判断をしたことはともかく、「自分たちの判断が間違っていたらどうなるか」を考えずに公表したのは非難されるべきでしょう。
しかし、部外者としては、「コードを読んでセキュリティホールを見つける」なんて大変な作業ができる人がそうそういるとは思えないので、 Apache 開発チームにも何とか ISS とうまく付き合ってほしいものだと思ってしまいます。
鵜呑みにしてみる？
Re:影響の範囲 (スコア:1)
こけたくらいでは、普通は OS はこけません。
本家のトピ (スコア:0)
Apache Vulnerability Announced [slashdot.org]
Re:本家のトピ (スコア:3, 参考になる)
ISS がなぜ Apache Project に知らせる前に公表したかについては、「噂だけど」という但し書き付きですがこんなコメント [slashdot.org]があります。 ISS と Red Hat が仲が悪く、 Apache の開発チームの中に Red Hat の社員がいるからだとか。
また、 ISS のパッチで問題が回避できるかできないかについても、少し議論が行われているようです（結局、結論は出ていないみたいですが）。この点については ISS のコメント [neohapsis.com]が参照されており、参考になるかもしれません。この中で ISS は、 Windows で弱点が exploitable である理由を説明しています。また、 ISS のパッチでどうして弱点の exploitation を防げるかも説明しています。もしこれが事実なら、 Apache のチームの言うという表現は、間違いはなくとも少し誤解を招く表現かもしれません。
鵜呑みにしてみる？