2005/12/21 PHP 脆弱性とバージョンアップ 日本 PostgreSQL ユーザ会 四国支部 / 日本 PHP ユーザ会 /Momonga Project 大垣 靖男 / / /

2005/12/22 目次 $GLOBALS 問題 $GLOBALS 問題の危険性を理解する前提 $GLOBALS 問題の危険性 $GLOBALS 問題の影響を受ける環境 $GLOBALS 問題の影響 もし register_globasl=on （相当）が必要な場合 register_globals=on のサーバ対策 PHP プロジェクトの対応 バージョンアップの薦め

2005/12/23 $GLOBALS 問題 セッションの値、サーバが設定する値が信頼できない事態 PHP 4.2 以前は正に最悪な状態であった register_globals=on の場合に大きな影響 PHP 脆弱性の中では「最悪」レベル

2005/12/24 $GLOBALS 問題の危険性を理解する前提 危険なコード その 1 include $_GET[ ‘ file ’ ]; 危険なコード その 2 include $_GET[ ‘ file ’ ]. ’.php ’ ;

2005/12/25 $GLOBALS 問題の危険性 危険なコード その 1 include dirname($_SERVER[ ‘ SCRIPT_FILENAME ’ ). ’ /lib/mylib.php ’ ; 危険なコード その 2 header(dirname($_SERVER[ ‘ REQUEST_URI ’ ). ’ other_file.php ’ );

2005/12/26 $GLOBALS 問題の影響を受ける環境 基本的には register_globals=on しかし、安直な register_globals=off 対策アプリの方が問題が大き い場合も … import_request_variables 関数 foreach ループ

2005/12/27 $GLOBALS 問題の影響 意外に多い影響 …. osCommerce (EC アプリ）は 2005 年 11 月時点でも register_globals=on で無ければ動作しない … register_globals=Off であれば安全 ?! 「ではない」 Wiki! (wiki.sorceforge.net) の様に import_request_variables 関数を 使用を薦めるアプリも Manbo （ CMS ）の様に foreach で resiger_globals=on をエミュレー トするアプリも

2005/12/28 さらに PEAR.php もスクリプトによっては攻撃の対象に！ echo $_SERVER[ ‘ REMOTE_ADDR ’ ] などが XSS 攻撃の対象に ! header 関数が関連すると HTTP Response Splitting 攻撃の対象に ! select * from hoge where ipaddress = ‘ $_SERVER[ ‘ REMOTE_ADDR ’ ] ’ ; などが SQL インジェクションの攻撃対象に ! $_SESSION により認証制御行っていても成り済まし放題に !

2005/12/29 もし register_globasl=on （相当）が必要な場合 1. php.ini で register_globals=off 2. 値に GLOBALS 等のスーパーグローバル配列が含まれていないか確認 3. import_request_variables 関数でインポート  サンプルコード if (!empty($_REQUEST['GLOBALS']) || !empty($_REQUEST['_SERVER']) || !empty($_REQUEST['_ENV'] || !empty($_REQUEST['_FILES'])) { error_log('Crack attempt from '.$_SERVER['REMOTE_ADDR'].' - '.$_SERVER['SCRIPT_FILENAME']); exit; } import_request_variables('gpc');

2005/12/210 register_globals=on のサーバ対策 register_globals=on でサーバを運用すること自体が間違い register_globals=on では実行させない PHP6 では register_globals 設定は無くなる if (ini_get( “ register_globals ” )) die( ‘ Should be register_globals=Off for security reasons ’ );

2005/12/211 PHP プロジェクトの対応 $GLOBALS 問題に対する対応は適切とは言いがたい対応 PHP プロジェクトでは他のセキュリティ問題への対応に不備があ る場合も … 無用のパッチが掲載されていたり … セキュリティレベルを下げる変更が …

2005/12/212 PHP 脆弱性リスト %AD%A5%EA%A5%B9%A5%C8 ChangeLog を見ないと分からない修正も … 中には ChangeLog には載っていない修正も …

2005/12/213 バージョンアップの薦め 基本的に PHP はメンテナンスされている最新リリースバージョン を使用 PHP 4.4.x PHP 5.1.x クリティカルなシステムの場合、 CVS 変更レベルでの注意も必要 バージョンアップ以外では Hardened PHP もオプションの一つ

2005/12/214 最近の mbstring 関数の問題 廣川さんが mbstring 関連の問題に関連するパッチをコミット mb_send_mail 関数 mb_encode_mimeheader 関数 mbfilter が誤変換する問題 PHP 4.4.2( 未リリース）、 PHP で修正済み

2005/12/215 とは言っても PHP 5.1.x は PHP くらいまで待ってもよいかも PHP5.0.x には $GLOBALS 問題がある。パッチ無しでは絶対に registger_globals=on で運用してはならない バージョン間で微妙な不整合が …

2005/12/216 QA 期間でのテスト QA は以前のバージョンとの整合性確認も目的の一つ 互換性問題を発見すれば対応される可能性が高い RC 段階に入った時点で自分のコードでの問題を確認 その為には Unit Test 等の活用が必要

2005/12/217 まとめ オープンソースは参加してこそ使いこなせる RC 期間に QA 参加するだけでも不意のセキュリティホール情報で もスムーズにバージョンアップが可能に

2005/12/218 余談：よくある間違い safe_mode はセキュリティの為の設定である しっかり作ったコードならユーザが直接参照しないファイルを DocuemntRoot に配置しても構わない 入力間違いは十分チェック（サニタイズ）しているので安全な コードである エラーが発生した場合、エラーメッセージを出さなければクラッ カーにスクリプトの脆弱性を知られずにすむ ソースを公開していなければ SQL インジェクション等の攻撃を受 ける可能性は少ない

2005/12/219 余談：フレームワーク万能論