アカウント名:
パスワード:
Apache HTTP Server 2.2.20がリリースされているので、2.2系を使用中の場合は更新すればよいようです。
Debian Sqeeze(stable)だと2.2.16-6+squeeze2で対応済み。testingだと近々対応予定。unstableだと2.2.19-2で対応済み。oldstable2.2.9-10+lenny10で対応済み。http://www.debian.org/security/2011/dsa-2298 [debian.org]
いずれも2.2.20に届いていないけど大丈夫という感じなんですよね。他のディストリでもかんな感じなんでしょうかね?
日本Apacheユーザ会のアナウンス [apache.jp]
> Range: bytes=-1が「最後の1バイト」ではなく0-1と同じ意味に解釈されてしまうらしい。> 2. リクエストフィールドのサイズを小さくする。下手に絞るとCookieが食えなくなって動作がおかしくなったりするよ。2chがまさにそれでハマってた。datの差分取得ができなくなるからRangeの無視もできないし。PDFを置いていなければRangeのカウントを絞るのが一番副作用が少なげ
25日に日記 [slashdot.jp]を書いたので、ご参考に。
スクリプト一本で殺せるんだから distributed じゃないじゃん単なる DoS だよ
一週間前に騒がれてたときはゼロデイ事件だったけど、今では違いますね。対策済み新バージョンを待って記事にするのは、ゼロデイのダメージを下げる報道協定みたいなもの?
0-dayではないですね。4年前から分かっていた脆弱性ですよ。
http://seclists.org/bugtraq/2007/Jan/83 [seclists.org]
アレゲな私としては、どういうアルゴリズムで処理したら、メモリを大量消費することになるのかが知りたいのですが、どなたか解説いただけないでしょうか。
http://d.hatena.ne.jp/nice20/20110829/p1 [hatena.ne.jp]
この辺りが回答っぽい。
#「まず最も誤解されそうな点」の通りに誤解してたけどID
リクエストされたとおりにレンジを処理しただけで、「大量消費」になる、ということでは?
だとすると、なぜApacheだけ? そう考えるとおかしいでしょ、その意見は。
検証してないから推測だけど、Rangeヘッダで重複領域を指定することがHTTPに規定されてないなら、400 Bad Requestを返したり、Rangeの重複部分を結合して返したりしてるのでは?仮に規定されていてちゃんと一つのパラメータに対して、それに応じた範囲のデータを返す必要があるならば、複数のパラメータ分のメモリを同時に確保することはせずに、一つずつメモリ確保して処理するという方法採ったりしてるのでしょう。
検証してないので他のHTTPサーバでも同じ脆弱性が存在する可能性は否定できないけど
元のタレコミには2chのことも書いてあったのですが編集者が何らかの理由で消したようです。おそらく「どうして2chのことだけ書くんだ。やっぱスラドは低能だな」みたいな話になるからでしょう。
日記で書いていた人がいたのをアレたまで見かけたんでそれがストーリーとして掲載されるかと思ったんですけどねぇここのApacheのアップデートが遅れてるとかいう理由から掲載しないつもりなのかな?と思いましたよ。丁度スラドがアップデートされた後ですし、やっぱりそうだったんですかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
バージョンて難しい (スコア:4, 参考になる)
Debian Sqeeze(stable)だと2.2.16-6+squeeze2で対応済み。
testingだと近々対応予定。
unstableだと2.2.19-2で対応済み。
oldstable2.2.9-10+lenny10で対応済み。
http://www.debian.org/security/2011/dsa-2298 [debian.org]
いずれも2.2.20に届いていないけど大丈夫という感じなんですよね。
他のディストリでもかんな感じなんでしょうかね?
Re:バージョンて難しい (スコア:3, 参考になる)
2.2.20がリリースされました (スコア:4, 参考になる)
日本Apacheユーザ会のアナウンス [apache.jp]
And now for something completely different...
2.2.20にはバグあり (スコア:3, 参考になる)
> Range: bytes=-1
が「最後の1バイト」ではなく0-1と同じ意味に解釈されてしまうらしい。
> 2. リクエストフィールドのサイズを小さくする。
下手に絞るとCookieが食えなくなって動作がおかしくなったりするよ。2chがまさにそれでハマってた。datの差分取得ができなくなるからRangeの無視もできないし。
PDFを置いていなければRangeのカウントを絞るのが一番副作用が少なげ
手前味噌だが (スコア:3, 参考になる)
25日に日記 [slashdot.jp]を書いたので、ご参考に。
DDoSの必要は無い (スコア:2, 参考になる)
"D"-DOS? (スコア:0, 既出)
スクリプト一本で殺せるんだから distributed じゃないじゃん単なる DoS だよ
報道協定 (スコア:0)
一週間前に騒がれてたときはゼロデイ事件だったけど、今では違いますね。
対策済み新バージョンを待って記事にするのは、ゼロデイのダメージを下げる報道協定みたいなもの?
Re: (スコア:0)
0-dayではないですね。4年前から分かっていた脆弱性ですよ。
http://seclists.org/bugtraq/2007/Jan/83 [seclists.org]
対処法などはわかった。しかし、ここはアレゲサイトなのですから、、、 (スコア:0)
アレゲな私としては、どういうアルゴリズムで処理したら、
メモリを大量消費することになるのかが知りたいのですが、
どなたか解説いただけないでしょうか。
Re:対処法などはわかった。しかし、ここはアレゲサイトなのですから、、、 (スコア:3, 興味深い)
http://d.hatena.ne.jp/nice20/20110829/p1 [hatena.ne.jp]
この辺りが回答っぽい。
#「まず最も誤解されそうな点」の通りに誤解してたけどID
Re: (スコア:0)
リクエストされたとおりにレンジを処理しただけで、「大量消費」になる、ということでは?
Re: (スコア:0)
だとすると、なぜApacheだけ? そう考えるとおかしいでしょ、その意見は。
Re: (スコア:0)
検証してないから推測だけど、
Rangeヘッダで重複領域を指定することがHTTPに規定されてないなら、400 Bad Requestを返したり、Rangeの重複部分を結合して返したりしてるのでは?
仮に規定されていてちゃんと一つのパラメータに対して、それに応じた範囲のデータを返す必要があるならば、
複数のパラメータ分のメモリを同時に確保することはせずに、一つずつメモリ確保して処理するという方法採ったりしてるのでしょう。
検証してないので他のHTTPサーバでも同じ脆弱性が存在する可能性は否定できないけど
Re: (スコア:0)
元のタレコミには2chのことも書いてあったのですが
編集者が何らかの理由で消したようです。
おそらく「どうして2chのことだけ書くんだ。
やっぱスラドは低能だな」みたいな話になるからでしょう。
Re: (スコア:0)
日記で書いていた人がいたのをアレたまで見かけたんで
それがストーリーとして掲載されるかと思ったんですけどねぇ
ここのApacheのアップデートが遅れてるとかいう理由から掲載しないつもりなのかな?と思いましたよ。
丁度スラドがアップデートされた後ですし、やっぱりそうだったんですかね。
Re: (スコア:0)
http://www.apache.jp/news/apache-http-server-2.2.20-released [apache.jp]