----------
長いから追記へ

------------------

http://packetstormsecurity.org/files/view/104479/apacheupdate2-dos.txt


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Apache HTTPD Security ADVISORY
==============================
UPDATE 2

Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x

CVE: CVE-2011-3192
Last Change: 20110826 1030Z
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions

Changes since last update
=========================
In addition to the 'Range' header - the 'Range-Request' header is equally
affected. Furthermore various vendor updates, improved regexes (speed and
accommodating a different and new attack pattern).

Description:
============

A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:

http://seclists.org/fulldisclosure/2011/Aug/175

An attack tool is circulating in the wild. Active use of this tool has
been observed.

The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.

The default Apache HTTPD installation is vulnerable.

There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.

A full fix is expected in the next 24 hours.

Background and the 2007 report
==============================

There are two aspects to this vulnerability. One is new, is Apache specific;
and resolved with this server side fix. The other issue is fundamentally a
protocol design issue dating back to 2007:

http://seclists.org/bugtraq/2007/Jan/83

The contemporary interpretation of the HTTP protocol (currently) requires a
server to return multiple (overlapping) ranges; in the order requested. This
means that one can request a very large range (e.g. from byte 0- to the end)
100's of times in a single request.

Being able to do so is an issue for (probably all) webservers and currently
subject of an IETF discussion to change the protocol:

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311

This advisory details a problem with how Apache httpd and its so called
internal 'bucket brigades' deal with serving such "valid" request. The
problem is that currently such requests internally explode into 100's of
large fetches, all of which are kept in memory in an inefficient way. This
is being addressed in two ways. By making things more efficient. And by
weeding out or simplifying requests deemed too unwieldy.

Mitigation:
===========

There are several immediate options to mitigate this issue until a full fix
is available. Below examples handle both the 'Range' and the legacy
'Request-Range' with various levels of care.

Note that 'Request-Range' is a legacy name dating back to Netscape Navigator
2-3 and MSIE 3. Depending on your user community - it is likely that you
can use option '3' safely for this older 'Request-Range'.

1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.

Option 1: (Apache 2.2)

# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range

# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range

Above may not work for all configurations. In particular situations
mod_cache and (language) modules may act before the 'unset'
is executed upon during the 'fixup' phase.

Option 2: (Pre 2.2 and 1.3)

# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range

The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.

2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.

LimitRequestFieldSize 200

Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.

See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) Use mod_headers to completely dis-allow the use of Range headers:

RequestHeader unset Range

Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.

Furthermore to ignore the Netscape Navigator 2-3 and MSIE 3 specific
legacy header - add:

RequestHeader unset Request-Range

Unlike the commonly used 'Range' header - dropping the 'Request-Range'
is not likely to affect many clients.

4) Deploy a Range header count module as a temporary stopgap measure:

http://people.apache.org/~dirkx/mod_rangecnt.c

Precompiled binaries for some platforms are available at:

http://people.apache.org/~dirkx/BINARIES.txt

5) Apply any of the current patches under discussion - such as:

http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e
http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1161534

OS and Vendor specific information
==================================

Red Hat: Option 1 cannot be used on Red Hat Enterprise Linux 4.
https://bugzilla.redhat.com/show_bug.cgi?id=732928

NetWare: Pre compiled binaries available.

mod_security: Has updated their rule set; see
http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html


Actions:
========

Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.

When using a third party attack tool to verify vulnerability - note that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of
that module.

Planning:
=========

This advisory will be updated when new information, a patch or a new release
is available. A patch or new Apache release for Apache 2.0 and 2.2 is expected
in the next 24 hours. Note that, while popular, Apache 1.3 is deprecated.

- -- end of advisory - update 2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk5Xdu8ACgkQ/W+IxiHQpxvN8ACgwsUJ6oYMq3SyoPHCR7rqsbP6
DFkAoKhZcF87F96h40tQdM1SZsiVX9N5
=07sc
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/





------------------------------------------------------------------------------------------------------------------------------------
全然よめないから翻訳
------------------------------------------------------------------------------------------------------------------------------------





-----メッセージであると署名されるPGPを始めてください。-----
ハッシュ: SHA1

アパッチHTTPDセキュリティ状況報告
==============================
アップデート2

タイトル: 範囲ヘッダーDoS脆弱性アパッチHTTPD 1.3/2.x

CVE: CVE-2011-3192
最後に、変化してください: 20110826 1030Z
日付: 20110824 1600Z
製品: アパッチHTTPDウェブサーバー
バージョン: アパッチ1.3、すべてのバージョン、アパッチ2、すべてのバージョン

アップデート以来の変化
=========================
'範囲'に加えて、ヘッダー、'範囲要求'ヘッダーは等しく影響を受けます。 その上、様々なベンダーアップデート、改良されたregexes(速度と異なって新しい攻撃隊形に対応します)。

記述:
============

サービスの弱点の否定は複数の重なる範囲がアパッチHTTPDサーバによって扱われる方法で見つけられました:

http://seclists.org/fulldisclosure/2011/Aug/175
攻撃ツールは荒野を循環しています。 このツールの能動的使用は観測されました。

攻撃は、離れてすることができて、サーバで控え目な数の要求で非常に重要なメモリとCPU用法を引き起こす場合があります。
デフォルトアパッチHTTPDインストールは被害を受け易いです。

現在、この脆弱性を修理するアパッチHTTPDのどんなパッチ/新しいバージョンもありません。 長期フィックスが利用可能であるときに、この状況報告をアップデートするでしょう。
完全なフィックスは次の24時間で予想されます。
バックグラウンドと2007年のレポート
==============================

この脆弱性への2つの局面があります。 1つは新しく、アパッチは特定です。
そして、このサーバサイドフィックスで、決心しています。 もう片方の問題は、基本的に2007までさかのぼるプロトコル設計結果です:

http://seclists.org/bugtraq/2007/Jan/83
HTTPプロトコルの現代の解釈は、(現在)、複数の(重なること)に範囲を返すためにサーバを必要とします。 要求されたオーダーで。 これは、人がただ一つの要求における非常に大きい100範囲(例えば、バイト0から端までの)回を要求できることを意味します。
そうすることができて、IETF議論の(たぶんすべて)のwebserversと現在の対象が変える問題はプロトコルですか:

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311

この状況報告はどのようにアパッチhttpdとそのような「有効な」要求に役立つとのそのいわゆる内部の'バケツ旅団'取引に関する問題を詳しく述べるか。 問題は、現在のそのような要求が内部的に100の大きい吹送距離に爆発するということです。そのすべてがメモリに効率の悪い方法で保たれます。 これは2つの方法で扱われています。 事態をより効率的にすることによって。 そして、扱いにく過ぎると考えられた要求を取り外すか、または簡素化することによって。

緩和:
===========

完全なフィックスが利用可能になるまでこの問題を緩和するために、いくつかの即座のオプションがあります。 以下の例は様々なレベルの注意で'範囲'とレガシー'要求範囲'の両方を扱います。
'要求範囲'がネットスケープナビゲータ2-3とMSIE3までさかのぼるレガシー名であることに注意してください。 あなたのユーザーコミュニティに頼ります--あなたはこのより古い'要求範囲'に安全にオプションを'3フィート使用できそうです。

1) SetEnvIfかモッズ_書き直しを使用して、多くの範囲を検出して、次に、Rangeを無視してください: ヘッダー、または、要求を拒絶します。

オプション1: (アパッチ2.2)

# 5つ以上の範囲であるときに、Rangeヘッダーを下げます。
# CVE-2011-3192
SetEnvIf Range、(--、:、1RequestHeaderの据え付けていないRange env=の悪い. *)? {5、5}悪い範囲=範囲

# 私たちはいつもRequest-範囲を下げます。 これがレガシーであるので
# MSIE3とNetscape2と3までさかのぼること。
RequestHeaderの据え付けていないRequest-範囲

# 任意の伐採。
悪い範囲のCustomLogログ/範囲CVE-2011-3192.logの一般的なCustomLogのログ/範囲CVE-2011-3192.logの一般的なenv=envは悪いreq-範囲と等しいです。

上では、構成がすべてのために働かないかもしれません。 '据え付けていなさ'が'fixup'段階の間、実行される前に、特に状況モッズ_キャッシュと(言語)モジュールは行動するかもしれません。

オプション2: (前2.2と1.3)

# Rangeの5つ以上の範囲であるときには要求を拒絶してください: ヘッダー。
# CVE-2011-3192
#
RewriteEngine、オン
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

# 私たちはいつもRequest-範囲を下げます。 これがレガシーであるので
# MSIE3とNetscape2と3までさかのぼること。
RequestHeaderの据え付けていないRequest-範囲

No.5は任意です。 いくつかの10年代は、問題であるべきでなくて、例えば、非常に高い終わりのeReadersにPDFsに役立つか、またはものを使用するサイトに必要であることで、そのような複雑なhttpがビデオ・ストリーミングを基礎づけたということであるかもしれません。

2) 要求分野のサイズをいくつかに100バイト制限します。 これが怒っているRangeヘッダーを短く保っている間、それに注意してください--他のヘッダーを壊すかもしれません。
かなり大きいクッキーやセキュリティ分野のように。
LimitRequestFieldSize200

攻撃がその分野で発展するとき、さらにこれを制限する、そして/または、他のLimitRequestFields制限を設けなければならない傾向があることに注意してください。

見ます: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

3) モッズ_ヘッダーを完全に使用する、不-、-許容してください、Rangeヘッダーの使用:

RequestHeaderの据え付けていないRange
これが電子読者と進歩的な人/httpストリーミング・ビデオに使用されるものなどの確信しているクライアントを調教するかもしれないことに注意してください。

2-3とMSIE3の特定のレガシーヘッダー--その上、ネットスケープナビゲータを無視するために、以下を加えてください。

RequestHeaderの据え付けていないRequest-範囲
一般的に使用と異なった、'及んでください'というヘッダー--'要求範囲'を下げるのは多くのクライアントに影響しそうにはありません。

4) 一時的な一時しのぎの対策としてRangeヘッダーカウントモジュールを配布してください:

http://people.apache.org/~dirkx/mod_rangecnt.c

いくつかのプラットホームへのPrecompiledバイナリは以下で利用可能です。

http://people.apache.org/~dirkx/BINARIES.txt

5) 以下などの議論で現在のパッチのいずれも適用します。

http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1161534

OSとVendorの特定の情報
==================================

参謀将校: レッド・ハットエンタープライズリナックス4でオプション1を使用できません。
https://bugzilla.redhat.com/show_bug.cgi?id=732928

NetWare: 利用可能な前コンパイルされたバイナリ。

モッズ_セキュリティ: それらの規則セットをアップデートしました。 見てください。
http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html


動作:
========

DoS攻撃に関して彼らのサーバに対して心配しているアパッチHTTPDユーザは、すぐにいずれでもあると上の緩和を実装すると考えるべきです。
_荒野のバージョンの大部分が現在モッズの存在がないかどうかチェックするという脆弱性--メモについて確かめる第三者攻撃ツールを使用するときには、空気を抜いてください。
そして、望んでください、(誤、)、このモジュールが存在していないならサーバが被害を受け易くないと報告してください。 この脆弱性はそのモジュールの存在か欠如に依存していません。

計画しています:
=========

新情報、パッチまたは新版が利用可能であるときに、この状況報告をアップデートするでしょう。 アパッチ2.0と2.2のためのパッチか新しいアパッチリリースが次の24時間で予想されます。 人気がありますが、アパッチ1.3が推奨しないことに注意してください。

- -- 状況報告の終わり-- アップデート2-----PGP署名を始めてください。-----
バージョン: GnuPG v1.4.11(ダーウィン)

iEYEARECAAYFAk5Xdu8ACgkQ/W+IxiHQpxvN8ACgwsUJ6oYMq3SyoPHCR7rqsbP6 DFkAoKhZcF87F96h40tQdM1SZsiVX9N5
=07sc
-----終わりのPGP署名-----

_______________________________________________
完全な開示--私たちはそれを信じます。
憲章: http://lists.grok.org.uk/full-disclosure-charter.html
Secuniaによって接待されて、後援されます-- http://secunia.com/





ようは
みんな、がんばってってことだ