web-dev-qa-db-ja.com

Apache-CVE-2014-0050を回避するためにContent-Typeヘッダーの長さを制限する方法は？

木曜日にDoSの問題TomcatがTomcatメーリングリストで発表されました（ "[SECURITY] CVE-2014-005 Apache CommonsFileUploadおよびApacheTomcat DoS " ）。

メッセージを一目で理解できる限り、攻撃者はファイルのアップロード時に長すぎるcontent-typeヘッダーを送信することで無限ループを引き起こす可能性があるようです（サーブレット3.0以降のアップロード機能がWebアプリケーションで使用されている場合）。 。

誰かが（AJPとmod_jkを使用して）Apache httpdサーバーの背後でTomcatサーバーを操作している場合、推奨事項「Content-Typeヘッダーのサイズを4091バイト未満に制限する」？

もちろん、バグ修正リリースが（ダウンロードページまたはLinuxディストリビューション固有のパッケージリポジトリから）利用可能になり次第、更新する必要があります。質問なし。しかし、現時点では 現在利用可能なTomcatバージョン7.0.5 はまだ影響を受けているようです。

しかし、固定リリースが利用可能になるまで、迅速な防御策として何ができるでしょうか？

（する必要なしに...

  • 現在のTomcatパッケージ（パッケージリポジトリからインストール）をアンインストールし、
  • ソース（SVN）から手動でバージョンをビルドします。
  • それらを手動でデプロイします（apt-getまたはaptitudeなしで）、
  • 後でパッケージリポジトリから快適に更新可能なバージョンを優先して、手動で作成したものをすべて再度アンインストールします）

このトピックの一時的な回避策に似た方法はありますか： http://wiki.Apache.org/httpd/CVE-2011-3192 ？

当時は、mod_headers、mod_setenvifまたはmod_rewriteを使用して問題に対処できました。不正な形式のmultipartアップロード要求をダウンストリームのTomcatサーバーから遠ざけるための同様のApache httpdトリックはありますか？

apache-2.2tomcathttpdddos
1
MrSnrub

Apache（Shaneからの変更バージョンを含む; rfc を読むとContent-Stringの長さが常に<129であることに賭けません

RewriteEngine On
RewriteCond %{HTTP:Content-Type} "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}"
RewriteRule ^/(.*)$ /405.html [R=301,L]

# modified 
SetEnvIf Content-Type ^.{3000,}$ bad-content-type=1
RequestHeader unset Content-Type env=bad-content-type

nginx（if（）を回避する方法が見つかりませんでした）

server {
  ...
  if ($http_content_type ~* "multipart\/form-data;(\s*)boundary=[a-zA-Z0-9_-]{3000}" ) {
  return 403; 
  }
  ...

}
1
that guy from over there

はい、うまくいくはずです。 CVEアナウンスは4091バイトと言っていますが、 偶発的な開示 電子メールは開発者が制限として70-128バイトに傾いているようです。 128で行きましょうが、必要に応じて調整できます。

SetEnvIf Content-Type ^.{129,}$ bad-content-type=1
RequestHeader unset Content-Type env=bad-content-type

（リクエストを完全に403するのではなく）ヘッダーの設定を解除するだけで、見かけの攻撃リクエストに対して不必要に穏やかになりますが、これでうまくいくはずです。

1
Shane Madden