Apache って標準の Not found のページなどを chunked transfer encode で返すんですね。ごく最近知って驚いたのですが、考えてみたら、 HTTP/1.1 で Content-length をつけずにデータを渡すためには、 Connection: close する以外には chunked を使うしか方法がないのでした(たぶん)。
なお、 transfer encode は要求と応答のどちらでも使うことができ、ここでぼくが言っているのは応答が chunked transfer encode を使っているという話です。 1.3.24 などの弱点は要求が chunked を使っている場合の話だと思うので、 Not found ページと今回の弱点は直接の関係はありません。誤解のなきよう。
○○だからor○○じゃないから安全 (スコア:2, 参考になる)
さて、ここから根拠もなく言ってきます。
よって、マイナスモデレートされるべきかもしれません。
<根拠なしの文>
きっと、CodeRedで話題になったIISじゃないから安心と思って
導入後、ずっと放置してあるApacheとかが
主な長期的なキャリアになるのでしょうね・・・
# いまだにCodeRed系も時々誘惑してるし、
# 当てない人は、いつまでたっても当てないでしょうし・・・
さて、今回のですが、
・分母の数が絶対的に多い
・脆弱性発見から、ワームが出回るまでの期間の短さ
・複数プラットフォームで、似たような脆弱性がある
Re:○○だからor○○じゃないから安全 (スコア:2, 参考になる)
絶望的観測で言うなら、
というところでしょうか。
私はApacheを使っていることを知っていますし混乱もしていませんが、正直な話、HTTPプロトコルは知りません。telnetでポート80に接続して「GETほげほげ」と入力して何かを入手したりすることくらいはできます。しかし「chunked encoding」なんてのは知りません。サーバの管理者は、そこまで知らないといけないのでしょうか?
Re:○○だからor○○じゃないから安全 (スコア:4, 参考になる)
>サーバの管理者は、そこまで知らないといけないのでしょうか?
知らなくてもApacheの管理者はやれますが、知ってればそれだけ
多くのことに対応できるでしょうね。ま、一般論ですが。
ちなみに「chunked転送」とは、送信時にコンテンツのサイズ(Content-Length)
を指定せずにメッセージを送信する方法です。この際Transfer-Encoding: chunkedを
ヘッダに付加します。
動的なメッセージの場合、メッセージを生成しながら転送できるので
(メッセージ全体を生成した後で転送する必要がない)、パフォーマンス面で
有利です。
クライアントのリクエスト、サーバのレスポンスともに使用することができますが、
今回Apacheではクライアントからのchunkedされたリクエストの処理で脆弱性が
発見されました。
#HTTP依存はますます強くなっているので勉強しておくことをお勧めします。
#まずはRFC2616 [w3.org]を見ましょう。
Re:○○だからor○○じゃないから安全 (スコア:2, 興味深い)
// というわけで、いろいろ勉強せにゃぁ。>ぼく :)
Apache って標準の Not found のページなどを chunked transfer encode で返すんですね。ごく最近知って驚いたのですが、考えてみたら、 HTTP/1.1 で Content-length をつけずにデータを渡すためには、 Connection: close する以外には chunked を使うしか方法がないのでした(たぶん)。
なお、 transfer encode は要求と応答のどちらでも使うことができ、ここでぼくが言っているのは応答が chunked transfer encode を使っているという話です。 1.3.24 などの弱点は要求が chunked を使っている場合の話だと思うので、 Not found ページと今回の弱点は直接の関係はありません。誤解のなきよう。
余談ですが、ぼくが chunked transfer encode について知ったのは、2ちゃんねるで mod_gzip を入れる話が出たときでした。 dechunking とかいう言葉が出てきて意味がわからなかったので、話についていくために RFC その他の資料を読んで勉強したのでした。2ちゃんねるでの議論をリアルタイムで読んでいたわけではありませんが。
鵜呑みにしてみる?
chunked ennoding (スコア:1)
いて、このchunked処理にはいろいろ問題がありそうだなと
思っていたところへ、この騒ぎになりました。
ちょっと忘れられているかもしれないDelegateにも、随分こ
の処理がらみでパッチが出ていたり、処理ミスがあったよう
です。また、HTTP/1.1指定によってHTTPコネクションを複数
リクエストに渡って使用すると、途中のプロキシが対応して
いなかったり、バグがあったりで、認証がらみでぼろぼろに
なるような現象がよく出ます。
仕様を作った方が悪いのか、仕様を正しく実現できないのが悪
いのか、どっちもどっちですが、chunked encodingはバグの
山のような気がしてなりません。
Re:○○だからor○○じゃないから安全 (スコア:1)
とりあえずサーバ管理者に必要なのは、それなりに十分な時間的余裕、bugtraqなどの「早い」情報源を適度に読める能力、サーチエンジン使ってそれが何かを調べるぐらいのリテラシー、ですかねえ。
組織としてはダブルチェックできる体制ってのもほしいけど、こっちは個人の能力ではちょっとどうしようもないことが多くて悲しい。
-- Takehiro TOMINAGA // may the source be with you!
Re:○○だからor○○じゃないから安全 (スコア:0)
HTTPプロトコルくらい知っておくべきでしょう。
もしも、それで飯喰うのならばね。
なんちゃってサーバ管理者なら、どーでもいいんですけど。