yohgaki's blog

タグ: PHP

  • BONUS-07-2007:Zend Platform ini_modifier Local Root Vulnerability

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

    (さらに…)

  • BONUS-06-2007:Zend Platform Insecure File Permission Local Root Vulnerability

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

    (さらに…)

  • MOPB-04-2007:PHP 4 unserialize() ZVAL Reference Counter Overflow

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

    (さらに…)

  • MOPB-05-2007:PHP unserialize() 64 bit Array Creation Denial of Service Vulnerability

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

    (さらに…)

  • MOPB-04-2007:PHP 4 unserialize() ZVAL Reference Counter Overflow

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

    (さらに…)

  • MOPB-03-2007:PHP Variable Destructor Deep Recursion Stack Overflow

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

    (さらに…)

  • MOPB-02-2007:PHP Executor Deep Recursion Stack Overflow

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

    (さらに…)

  • MOPB-01-2007:PHP 4 Userland ZVAL Reference Counter Overflow Vulnerability

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

    (さらに…)

  • the Month of PHP Bugs開始

    “the Month of PHP Bugs”が始まりました。できるだけ多くの方が読めるように、Stefanさんの承諾を得て、日本語訳を公開します。「the Month of PHP Bugs」カテゴリがMoPBの翻訳ページになります。

    https://blog.ohgaki.net/tag/mopb

    まずはトップページから翻訳します。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。念の為に記載します。私はPHPプロジェクトのコミッタですがHardened-PHP ProjectおよびMonth of PHP Bugsには関係がありません。日本のPHPユーザが置き去りにされないよう日本語訳を公開しているだけです。

    誤訳、間違い、タイポなどがあった場合、指摘していただけると助かります。

    http://www.php-security.org/

    (さらに…)

  • Month of PHP bugs

    Stefanさんが公言していた通り、セキュリティホールの公開が3月から始まるそうです。

    The Month for the “Month of PHP bugs” was choosen and it will be March. This means I will post every day in March information about one or more vulnerabilities within PHP.

    PHPの開発者は知っているがPHPの利用者はあまり知らないセキュリティ上の問題などもどんどん公開すればよいと思います。（セキュリティホールとして直すつもりがない物もあったりするので… )

    たぶん私も知らない脆弱性もあるはずです。この忙しい時に対応しなければならないので困ったものです。せめて4月にしてもらいたい…

  • PHP 5.2.1リリース

    情報としては古くなっていますが、念のため書きます。PHP 5.2.1がリリースされています。

    JP-CERTのアドバイザリ（JPCERT/CC REPORT 2007-02-07）にMODxのXSSが記載されていましたがこっちの方が重要性は高いと思われます。次のアドバイザリでは記載されるかもしれませんが、例によってPHP4は置き去りにされているので、記載されない可能性も高いと思います。私が編集者だったらどうするかかなり迷います。
    # MODxはコードをチラッとみただけで試すのを諦めたのですが
    # いろいろあるようですね。

    時間ができたらCode Blogの方にいろいろ書いてみたいと思っています。
    # いつできるか？が問題だったり….

  • なぜPHPアプリにセキュリティホールが多いのか?

    技術評論社の新サイトで「なぜPHPアプリにセキュリティホールが多いのか?」をテーマにブログ風の記事を掲載させていただく事になりました。第一回は「CVEでみるPHPアプリケーションセキュリティ」です。

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

    CVEをフォローしている方であればPHPアプリケーションの脆弱性レポートの多さが目立っていることはよくご存知と思います。何故CVEエントリが多いのか解説しています。よろしければご覧下さい。

    技術評論社の須藤さんに編集していただいているので私が書いた文章より読みやすいです。

    今、気が付いたのですが、SecurityForcusに次の様な記載がありました。

    The problem is, PHP applications accounted for about 43% of the security issues in 2006, according to the National Institute of Standards and Technology (NIST).

    http://www.securityfocus.com/columnists/427

    数えると凡そ半分と言っても良いくらいPHPアプリの脆弱性レポートがあったのですね。

  • 今日の驚き!

    何故かmb_send_mailでメールが文字化けする、普通に運用しているサーバでは問題が無いにも関わらず…

    調べてみるとmbstring.languageのaccess設定が6になっていました。6つまりスクリプトからは変更できない状態になっています。運用サーバ環境(開発環境含む)ではphp.ini設定はほとんど全て仮想サーバレベルで設定していたので今まで気が付きませんでした。

    mbstring.languageの設定が変更できないと、mb_send_mail()を使って正しくメールを送信することができなくなります。（日本だけ、とかなら良いですが）この件、かなり「怒」なので時間ができたら誰が変更したか調べる事にします。

    PHPは5.1…

    追記：
    mb_send_mail()で文字化けで困っている方は、php.iniなら

    mbstring.language = “japanese”

    Apacheの設定ファイル、.htaccessなどなら

    php_value mbstring.languge japanese

    と設定します。これで日本語メールでも文字化けしなくなります。デフォルトのmbstring.language設定（neutral)の場合、日本語メールは正しく送信できません。

    パッチをするなら（PHP_5_2ブランチ）

    cvs diff: Diffing ext/mbstring
    Index: ext/mbstring/mbstring.c
    ===================================================================
    RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
    retrieving revision 1.224.2.23
    diff -u -r1.224.2.23 mbstring.c
    — ext/mbstring/mbstring.c 11 May 2006 14:47:34 -0000 1.224.2.23
    +++ ext/mbstring/mbstring.c 10 Nov 2006 05:10:51 -0000
    @@ -739,7 +739,7 @@

    /* {{{ php.ini directive registration */
    PHP_INI_BEGIN()
    – PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_SYSTEM | PHP_INI_PERDIR, OnUpdate_mbstring_language)
    + PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_ALL, OnUpdate_mbstring_language)
    PHP_INI_ENTRY(“mbstring.detect_order”, NULL, PHP_INI_ALL, OnUpdate_mbstring_detect_order)
    PHP_INI_ENTRY(“mbstring.http_input”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_input)
    PHP_INI_ENTRY(“mbstring.http_output”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_output)

    1行パッチなので他のバージョンでも同じ場所を直せばOKです。パッチをすればmb_language()で言語設定を変更しmb_send_mail()で正しくメールが送信できるようになります。

  • PHP 5.1/4.4用のセキュリティパッチ

    PHP 5.2.0がリリースされていますが少なくとも2つ重要なセキュリティフィックスがあります。5.1/4.4ユーザが5.2.0にアップグレードするには時間が必要と思うのでWikiどのパッチが必要か書いておきました。PHP4はこちらです。

    PHP4.4にはありませんがPHP5.1にはecalloc（メモリ確保関数）に整数オーバーフロー脆弱性があります。この脆弱性は随分前にPHP4で修正されたバグですがPHP5ブランチにマージされ忘れていた、という代物です。最も簡単に攻撃可能なケースはserializeされたPHP変数をフォームやURLに埋め込みそれをunserializeで処理しているケースです。

    htmlspecialchars()/htmlentities()のヒープオーバーフローのPoCは見かけていませんがパッチを見ればどのような入力でオーバーフローするのか見る人が見れば直ぐ分かると思います。

  • ログイン後にsession_regenerate_id()を実行するだけで十分か?

    忙し過ぎてタイムリーにブログが書けないです。最近セッション管理の問題が一部で話題になっていました。そこの中に以下のような議論がありました。

    ログイン後にsession_regenerate_id()を実行すれば外部からのセッションIDを受け入れても安全

    確かにログイン後のセッションIDは本来セッションIDが持つべき属性

    •  一意な値であること
    • 第三者に予測不可能であること

    を持っています。

    しかし、ログイン後にセッションIDを再生成するだけでは不十分な場合は2つ直ぐに思いつきます。

    – CSRF(XSRF)防御にセッションID（だけ）を利用している場合
    – 外部に出力したデータの改ざん防止にセッションID（だけ）を利用している場合

    これらの仕組みはログイン後にのみ利用する機能ではありません。フォーム送信は認証無しで行うことは多いです。ウィザード型の入力フォーム（検証済みの前のページの入力値を次ページに保存する方法が最も柔軟な処理方法）も認証前に使用されます。

    私はCSRF(XSRF)防御にはフォームに予測不可な一意なIDを割り当てる方式を、検証済みデータの改ざん防止にはセッションID+マジック文字列（予測できない秘密の文字列）を利用しています。CSRF(XSRF)対策には影響ないですし、セッションIDを利用してセキュリティを維持する仕組みであっても必ずマジック文字列を使用しているので危険な状態にはなりません。しかし、全てのアプリケーションがこのような対策を取っているとは思えないので外部からのセッションIDを受け付けない厳格なセッションID管理を導入するのはセキュリティ上意味があります。

    ほとんどのアプリケーションはログイン後にsession_regenerat_id()を実行するだけで十分な安全性を確保することが可能ですが一部のアプリケーションはそれでは不十分であることは知っておいたほうが良いと思います。

    追記：2001年からウィザード型フォームで前のページのデータを安全に保存するため等に利用できる関数をZendのコードギャラリに載せています。ウィザード型フォームはこのような関数を使用し検証済みの値のメッセージダイジェストを取っておけと繰り返し入力値を検証する必要性がなくなります。