yohgaki's blog

追記：まとめ用のエントリも追加しました下記URLもご覧ください。

http://blog.ohgaki.net/index.php/yohgaki/2005/11/09/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_2

まず先のブログエントリで私が誤解していたため解りづらい状態になっていました。register_globals=offであればアドバイザリ（http://www.hardened-php.net/advisory_202005.79.html）の影響は受けません。この場で深くお詫びいたします。

いくつかのパターンが考えられますが今回Hardened-PHPプロジェクトからのアドバイザリで指摘されている問題によって影響を受ける環境は次のようになります。

影響を受ける環境1

• register_globals=on に設定しているPHP4,PHP5
• 未パッチのPHP - PHP 4.4.0以下、PHP 5.0.5以下
• http://www.hardened-php.net/advisory_202005.79.html

影響を受ける環境2

• parse_str関数を1つの引数のみでユーザが送信したデータに対して使用した場合
• 未パッチのPHP - PHP 4.4.0以下、PHP 5.0.5以下
• http://www.hardened-php.net/advisory_192005.78.html

アドバイザリより参照先とされたリンク先の問題の方が問題です。安全なプログラミングをこころがけているプログラマであれば脆弱なコードを書くことはないと思いますが、後で影響を受ける環境/プログラムについてもう少し解りやすく記述します。

http://www.hardened-php.net/globals-problem

影響を受ける環境3

• import_request_variables等を使ってスコープ内にユーザが送信した変数を初期化しているプログラムを使用している（実装の違いからPHP4とPHP5、パッチの有り無し、バージョン、global_register設定で影響範囲が違う）

環境1のregister_globals=offはPHP4.2からのデフォルトであるため現在register_globals=onで運用しているシステムは無いと思いますが、register_globals=onでなければ動作しないアプリケーションの場合、直接影響を受けるので直ぐにアップデートが必要です。環境2のアドバイザリは事例が限定されていますがregister_globals=off設定でもregister_globals=onに変えてしまう脆弱性です。parse_str関数を引数1つのみで使う事は無いと思いますが一旦register_globals=onに設定が変わるとプロセスが終了するまでそのままになってしまいます。環境3はPHP本体の脆弱性とPHPスクリプトに作ってしまう脆弱性です。

Stefanさんの環境1に対するアドバイザリがCriticalとして設定されているのは次の理由からと考えられます。

• 問題が発見されるまでは安全と考えられていたグローバル変数を利用したコードが危険なコードであること
• PHP 4.4.1以前に添付されているPEAR.php等が攻撃に対して脆弱であること
• 古いPHPとコードと使用している組織が多いこと
• ワームなどが発生する可能性があると考えていること

# 環境2のparse_str関数の問題がLowレベルのアドバイザリとしてリリースした事
# から考えると環境1をCriticalレベルのアドバイザリとしてfile uploadの問題
# を取り上げるのはどうかと思います。言い訳になりますが同時に出されたアド
# バイザリのレベル、参考リンクと必要なパッチを見て誤解してしまう、という
# 失敗をしてしまいました。

典型的な環境3のようなプログラムはregister_globals=onである事を仮定していたレガシーなコードをregister_globals=off環境でも動作するように修正したプログラムと思います。新しいプログラムでもimport_request_variables関数等を利用した古いプログラミングスタイルのプログラムは脆弱になります。import_request_variables関数を利用しなくても自前でforeach文などでユーザ入力をスコープ上に展開した場合も脆弱になります。（hardened-phpの場合、このようなケースでも対応しているそうです）

対策としてはPHP本体とPEARをバージョンアップしできる限り安全な状態も必要ですが、PHPコードの再検査、特にレガシーなPHPスクリプト、を行い危険なユーザ変数のスコープ（クラス、ローカル、グローバル全て）への代入が無い事を確認する必要性があります。この問題をPHP本体のみで対処できれば良いのですがすべては望めません。

function bad1() {
  import_request_variables('g'); // GETの変数をローカルスコープに展開したい
  // prefixを付けないと$GLOBALSなどを書き換えられる可能性がある
}

function bad2() {
  forearch($_GET as $k=$v) $$k=$v;
  // import_request_variables('g')と同じ
}

確かにアドバイザリにあるようなPHP本体の脆弱性が影響する部分もあるのですが、ホワイトペーパーで指摘されているユーザのコード（PHPで書いたスクリプト）の方が問題と思います。上記の様なコードは非常に危険であるため古いコードには十分注意が必要と思います。