GLOBAL Problem

PHP脆弱性とバージョンアップ
日本PostgreSQLユーザ会四国支部/日本PHPユーザ会/Momonga Project
大垣靖男
[email protected] / [email protected] / [email protected] /
[email protected]
2005/12/2
1
目次
$GLOBALS 問題
$GLOBALS問題の危険性を理解する前提
$GLOBALS問題の危険性
$GLOBALS問題の影響を受ける環境
$GLOBALS問題の影響
もしregister_globasl=on（相当）が必要な場合
register_globals=onのサーバ対策
PHPプロジェクトの対応
バージョンアップの薦め
2005/12/2
2
$GLOBALS 問題
セッションの値、サーバが設定する値が信頼できない事態
PHP 4.2以前は正に最悪な状態であった
register_globals=onの場合に大きな影響
PHP脆弱性の中では「最悪」レベル
2005/12/2
3
$GLOBALS問題の危険性を理解する前提
危険なコードその1
include $_GET[‘file’];
危険なコードその2
include $_GET[‘file’].’.php’;
2005/12/2
4
$GLOBALS問題の危険性
危険なコードその1
include dirname($_SERVER[‘SCRIPT_FILENAME’) .’/lib/mylib.php’;
危険なコードその2
header(dirname($_SERVER[‘REQUEST_URI’).’other_file.php’);
2005/12/2
5
$GLOBALS問題の影響を受ける環境
基本的には

register_globals=on
しかし、安直なregister_globals=off対策アプリの方が問題が大きい
場合も…


2005/12/2
import_request_variables関数
foreachループ
6
$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/2
7
さらに
PEAR.phpもスクリプトによっては攻撃の対象に！
echo $_SERVER[‘REMOTE_ADDR’]などがXSS攻撃の対象に!
header関数が関連するとHTTP Response Splitting攻撃の対象に!
select * from hoge where ipaddress = ‘$_SERVER[‘REMOTE_ADDR’]’;
などがSQLインジェクションの攻撃対象に!
$_SESSIONにより認証制御行っていても成り済まし放題に!
2005/12/2
8
もしregister_globasl=on（相当）が必要な場合
1.
2.
3.
php.iniでregister_globals=off
値にGLOBALS等のスーパーグローバル配列が含まれていないか確認
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/2
9
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/2
10
PHPプロジェクトの対応
$GLOBALS問題に対する対応は適切とは言いがたい対応
PHPプロジェクトでは他のセキュリティ問題への対応に不備がある場
合も…


2005/12/2
無用のパッチが掲載されていたり…
セキュリティレベルを下げる変更が…
11
PHP脆弱性リスト
http://wiki.ohgaki.net/index.php?PHP%2F%C0%C8%BC%E5%C0
%AD%A5%EA%A5%B9%A5%C8

ChangeLogを見ないと分からない修正も…
中にはChangeLogには載っていない修正も…
2005/12/2
12
バージョンアップの薦め
基本的にPHPはメンテナンスされている最新リリースバージョンを使用


PHP 4.4.x
PHP 5.1.x
クリティカルなシステムの場合、CVS変更レベルでの注意も必要
バージョンアップ以外ではHardened PHPもオプションの一つ

2005/12/2
http://www.hardened-php.net/
13
最近のmbstring関数の問題
廣川さんがmbstring関連の問題に関連するパッチをコミット



mb_send_mail関数
mb_encode_mimeheader関数
mbfilterが誤変換する問題
PHP 4.4.2(未リリース）、PHP 5.1.1で修正済み
2005/12/2
14
とは言っても
PHP 5.1.xはPHP 5.1.2くらいまで待ってもよいかも
PHP5.0.xには$GLOBALS問題がある。パッチ無しでは絶対に
registger_globals=onで運用してはならない
バージョン間で微妙な不整合が…
2005/12/2
15
QA期間でのテスト
QAは以前のバージョンとの整合性確認も目的の一つ
互換性問題を発見すれば対応される可能性が高い
RC段階に入った時点で自分のコードでの問題を確認
その為にはUnit Test等の活用が必要
2005/12/2
16
まとめ
オープンソースは参加してこそ使いこなせる
RC期間にQA参加するだけでも不意のセキュリティホール情報でもス
ムーズにバージョンアップが可能に
2005/12/2
17
余談：よくある間違い
safe_modeはセキュリティの為の設定である
しっかり作ったコードならユーザが直接参照しないファイルを
DocuemntRootに配置しても構わない
入力間違いは十分チェック（サニタイズ）しているので安全なコードで
ある
エラーが発生した場合、エラーメッセージを出さなければクラッカーに
スクリプトの脆弱性を知られずにすむ
ソースを公開していなければSQLインジェクション等の攻撃を受ける可
能性は少ない
2005/12/2
18
余談：フレームワーク万能論
2005/12/2
19

Download Report