Django 1.4.14, Django 1.5.9, Django 1.6.6, Django 1.7 rc 3 がリリースされました。 この記事は https://www.djangoproject.com/weblog/2014/aug/20/security/ を 元にしたものです。
このリリースでは reverse() が内部のURLを生成する際の問題、 サービス停止を引き起こすファイルアップロード、 remote-user ミドルウェアの潜在的なセッションハイジャックの問題、 Admin インタフェースでの情報漏えいの問題を修正しています。 全ての Django ユーザーにできるだけ早いアップグレードが推奨されています。
他ホストへのURLを reverse() が生成し得る問題 (CVE-2014-0480)
Django は django.core.urlresolvers.reverse というヘルパー関数を持っており、 view へのリファレンスかURLパターン名からURLを生成するために使われます。 特定条件下で reverse() がスキーム相対 (scheme-relative) な、他のホストへのURLを 生成する可能性がありました。 これは問題を知っている攻撃者に任意のサイトへのリンクを生成させる可能性があり、 フィッシングや他の問題を可能にします。
この修正のため、 reverse() の返り値が '//' で始まる場合は 2 つめのスラッシュが (%2F) で 置き換えられるようになりました。
訳注: 元のブログポストを見ると reverse() に '//' で始まる文字列を与えるだけで脆弱性になる ように読めますが、特定のURLパターンと一緒でないと起こりえません。ただその文字列が生成された場合に reverse() が特に何もフィルターせずにURLを返していた、というのがこの問題です。 例えば '(.+)/foo' のようなURLパターンがあった場合に、 このURLにマッチする条件 + '/example.com' という引数を与えると '//example.com/foo' というURLが生成されてしまいます。
サービス停止を引き起こすファイルアップロード (CVE-2014-0481)
デフォルトの挙動で Django のファイルアップロードシステムは、同じファイルパス、同じファイル名 でのファイルアップロードが会った際に、新しいユニークなファイル名を生成します。 ファイル名に対してアンダースコアと数字を末尾に付与して行い、数字は名前の衝突がなくなるまで 順に増やされていきます (_1, _2 など)。
攻撃者は同じ名前をもつ小さいファイルを大量にアップロードすることで、この順によるファイル名生成 の脆弱性を攻撃できます。この場合 Django は os.stat() を呼び出すことでファイル名を生成 しようとし、この数は増え続けます。 結果として、このように割合小さなサイズのファイルのアップロードにしてもパフォーマンスは極端に 低下します。
この修正のために、 Djangoのファイルアップロードシステムは順序の数値を使わないようになりました。 代わりに短い英数字の文字列が付与されます。
RemoteUserMiddleware のセッションハイジャック (CVE-2014-0482)
Django は REMOTE_USER ヘッダーを認証処理に使うミドルウェア django.contrib.auth.middleware.RemoteUserMiddleware と、認証バックエンド django.contrib.auth.backends.RemoteUserBackend を提供しています。
特定の条件下でこのミドルウェアとバックエンドを使用することで、あるユーザーが別ユーザーのセッション を受信し得るという問題がありました。 REMOTE_USER ヘッダーへの変更が、対応する logout/login アクションなしに起こった場合です。
この修正のためにミドルウェアは、脆弱性をつくようなログアウト以外での REMOTE_USER の 変更があった場合に、ログアウトとログインを強制するようになりました。
Admin でのクエリ操作によるデータ漏えい (CVE-2014-0483)
Django の admin インタフェース django.contrib.admin は、関連するオブジェクトを ポップアップウィンドウで表示する機能を提供しています。 このメカニズムは、URLとクエリストリングに値を保持しておき、 表示したい関連モデルとリレーションを実装したフィールドを取得することで実装されていました。 これはパーミッションチェックをモデルクラス全体のレベルで行っていました。
しかしこのメカニズムは、特定フィールドが実際にモデル間のリレーションを扱うものかを チェックしていませんでした。 よって Admin インタフェースにアクセスでき、モデル構造と該当のURLに十分な理解があるユーザー は関連のないフィールドの値をポップアップ上に表示することができました。 アプリケーション開発者が意図していないようなフィールドも表示させれます。
この修正のため admin インタフェースは、通常のパーミッションチェックの追加として、 指定されたフィールドが admin に登録されたモデルのリレーションを扱うものかを確認するように なりました。
Comments
There are currently no comments
New Comment