カテゴリー: Computer

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系のみメンテナンスされています。

Example 1428. A “Best Practice” query

PHPのマニュアルページで「Example 1428. A “Best Practice” query」と題されたSQL文用の文字列エスケープ処理のサンプルコードがあるのですが、

$query = sprintf("INSERT INTO products (`name`, `description`, `user_id`) VALUES ('%s', '%s', %d)",
mysql_real_escape_string($product_name, $link),
mysql_real_escape_string($product_description, $link),
$_POST['user_id']);

mysql_query($query, $link);

この方法はよくないですね… $_POST[‘user_id’]は符号付き32ビット整数だと仮定していて64ビット整数や任意精度整数の場合が考慮されていません。”Best Practice”とするなら整数型と思われるuser_idも文字列として処理し、エスケープしてからmysql_queryに渡すべきだと思います。

画像ファイルにJavaScriptを隠す

前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか ha.ckersにJavaScriptをイメージファイルに隠す方法が紹介されています。

http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/

<script src="http://cracked.example.com/cracked.gif">

などとXSS攻撃を拡張する手段に利用可能です。サンプルとしてFlickerにJavaScriptを埋め込んだイメージファイルがアップされています。

	Hide JavaScript code into GIF image

このイメージファイルは上手く細工しているので画像としても表示され、JavaScriptも実行できます。

Flickerは画像ファイルをそのままアップロードできるようですね。もしかしてGDの整数オーバーフロー脆弱性を攻撃する画像イメージなどもアップできる??

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を使っていてもここで問題としている不具合には影響されません。

PHPMailerコマンドインジェクション – WordPress, Mantis, WebCalendar, Group-Office, Joomla, etc

個人的には影響ないですがいろいろなアプリケーションで使われているPHPMailerと言うクラスにコマンドインジェクションの脆弱性があったようです。リンク先を見ればescapeshellarg()かescapeshellcmd()でエスケープすべき個所がエスケープされていない事が分かります。

どの位危険か?と言うと簡単にサーバを乗っ取られる(不正なプロセスを実行される等。プロキシ、SPAMメール中継、SSHアカウントクラック、DoS、etc)くらい危険です。対処が必要な方は早く対処すべきです。

以下はfull-disclosureのメールです。

PHPMailer is a widely deployed utility class used in PHP application to
handle emails sent through sendmail, PHP mailto() or SMTP. It is used in PHP applications such as WordPress, Mantis, WebCalendar, Group-Office and Joomla. The last official release happened on July 11, 2005.

If you have configured PHPMailer to use sendmail it has a remote command execution vulnerability due to a lack of input validation. sendmail isqueried through the popen function which is called with a string constructed from non-escaped user input.

http://larholm.com/2007/06/11/phpmailer-0day-remote-execution/

Cheers
Thor Larholm

追記:調査を行っていないので何となくですが、ファイルインクルードバグよりコマンドインジェクションバグの方が悪用される確率が高いような気がしています。脆弱性的にはファイルインクルードバグの方が強力ですが、攻撃用コードを別ホストに配置するのが面倒なのか(?)コマンドインジェクションの方が悪用されているような気がします。
# ファイルインクルードバグには攻撃用コードを
# 直接挿入できる場合もあります。

PHP 5.2.3のchunk_split()は未修整だった…

http://blog.php-security.org/archives/84-PHP-5.2.3-released….html にも書いてあるのですが、PHP 5.2.3ではchunk_split()が直っているハズだったのですが直っていませんでした。

Fixed an integer overflow inside chunk_split() (by Gerhard Wagner, CVE-2007-2872)

直したつもりが整数オーバーフローが発生するコードになっており、ヒープオーバーフローが発生します…

CVSには修正コードがコミットされています。

http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?r1=1.445.2.14.2.60&r2=1.445.2.14.2.61

Fix chunk_split fix – avoid using floats
Fix money_format – don’t give strfmon more arguments then supplied
Fix str[c]spn integer overflow

他のセキュリティFIXもあるのでPHP 5.2.4のリリースは近い(?)かな…

Cのコードを読める方なら気が付くと思いますが、整数オーバーフローによりdestバッファに十分なメモリが割り当てられない問題に対してint型の変数とINT_MAXを比較、符号のチェックをしても意味がないのは明白です。(負の値になった時しかチェックしていないので対策になっていない)

この指摘に対してBogusだとかFUDだとか言われるのは非常に心外だと思います。セキュリティ問題に対して正しい姿勢や理解を持っていない開発者と話をするのはかなりの疲労を伴う作業だ、という事がStefanさんのブログからは分かります… 文面からも最近フラストレーションが溜まっているような気もします。コードをチェックするStefanさんがいるPHPといないPHPでは安全性に大きな違いが発生すると思います。Hardened-PHPやMOPBをサポートするにはPayPalによる寄付もありますが応援メールも有効です。(こういうメールは英語が下手でも問題はないです)

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では問題が認識されていたようです。

PostgreSQLカンファレンス2007

明日開催されるPostgreSQL2007は会場費等の為に2000円でローソンチケットでチケットを販売していました。ローソンチケット分は完売で現在購入できないそうです。しかし、当日券を会場にて販売(当日券は3000円だそうです)するそうです。もしチケットを入手できなかった方は現金で購入できるそうです。領収書も発行できるので仕事の都合がつく方は是非お越しください。

PostgreSQLカンファレンス2007

最近忙しすぎてブログの更新が全くできない状態がつづいていますが、PostgreSQLカンファレンス2007が2007/6/5(火)に秋葉原UDXにて開催されます。私もRoom C(定員60名: 16:00~16:55)で講師を務めさせていただきます。私がメールを読んでいなかった為、私の資料は印刷物には入っていません… この為当日自分で持って行くことになってしました…
# 関係者の皆様、ご迷惑をおけしました。

Room C(60名)16:00~16:55
WEB+DBアプリケーションのセキュリティ(仮)
PHPユーザ会/日本PostgreSQLユーザ会
大垣靖男 様

セキュリティ対策はまず基礎知識から、ということでPostgreSQLを安全に利用するための基礎知識を解説させていただきます。今回は初めてデモを予定しています。SQLインジェクションに脆弱だといかに簡単に不正にデータを取得したり、データベース設計を解析できるかをデモンストレーションする予定です。SQLインジェクションに再確認されたい方、SQLインジェクションは知っているがどの程度の攻撃が可能か詳しく知らない方であれば、PostgreSQLユーザのみでなく、全てのSQLデータベースを利用されている開発者に有用な講演になると思います。

ローソンチケットによるとまだチケット(2000円です。会場費などに利用されます)は買えるようです。いろいろ有用なセミナーがそろっています。都合が良い方は是非お越しください。

VMWare上のUbuntu 7.0、CentOS5

VMWare上にUbuntu 7.0をインストール(正確には6.xから7.04にアップグレード)してみました。6.xのときからvmwareのマウスドライバがインストールされないため、ホスト・ゲストOS上でマウスカーソールが移動できませんでした。

あまり気にしていなかったのですがCentOS5をゲストOSとしてインストールしても同じようにマウスポインタが移動できません。さすがに2つのゲストOSでマウスポインタが思ったように動作しないのは面倒なので調べてみることにしました。

CentOS5の/etc/X11/xorg.confをvmwareのマウスドライバを使用するようにすると動作するようになりました。

Section "InputDevice"
Identifier "Mouse0"
Driver "vmmouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "IMPS/2"
Option "ZAxisMapping" "4 5"
EndSection

Ubuntuの方はvmmouseドライバを指定するとドライバファイルが見付からないためXが起動しなくなりました。

ln -s /usr/lib/vmware-tools/configurator/XOrg/7.0/vmmouse_drv.so /usr/lib/xorg/modules/input/vmmouse_drv.so

とするとドライバをロードしマウスが期待どおり動作するようになりました。Ubuntu 7.0のXorgは7.2ですが7.0のドライバでも問題なく動作するようです。

MOBPを訳し終えて

もう何年か前になりますがStefanさんがPHPプロジェクトへの貢献を始めたころ「整数オーバーフローの修正はセキュリティ脆弱性なのでそのことを明記すべき」と指摘した事がありました。信じがたいかもしれませんが「攻撃可能かどうか分からないし脆弱性でなく普通のバグ修正だ」と主張する開発者がいたためPHPのこの手のヒープオーバーフローセキュリティ修正は「fixed crash」とCVSログに書いてあるだけの場合が多く、NEWSファイルにも記載されない事が当たり前になっていました。

もっと読む

.xxxドメイン却下

ここ数年間、議論されていた.xxxドメインが却下されたそうです。当然です。ほとんどフィッシングくらいにしか使われていない!? .infoや.bizよりも悪いドメインになりそうだった.xxxドメインが却下されて何よりです。

新しいTLDはほとんど必要ないし、作って利益があるのはインターネットを利用するユーザでも、サービスの提供者でも無く、フィッシングをする悪人、屋号・商標などを登録して悪用(たとえば恐喝まがいのドメインセールス)する悪人またはレジストラだけです。

IDNも至極迷惑なのですべてのブラウザがデフォルトで無効にしてほしいくらいです。標準に準拠しなくなる!という議論もあると思いますが、今のブラウザは標準準拠していない機能ばかりです。どうせ標準に準拠していないのでIDNに準拠しない方が問題が少なくなる、と考えている人も少なくないと思います。

ha.ckers.orgに載っていたのですがSSLをURLに含めたフィッシング、たとえば

http://evil.example.com/www.target.com/ssl/foo/bar/

も一定の効果があるようです。何故なら、「Look for correct domain」(正しいドメイン名か確認せよ)、「Look for SSL」(SSLであることを確認せよ)と言われているからです。一般のユーザにとってSSLは何の意味もないことが多く、httpsがURLの先頭にあるとSSLになる事も知らない場合が多いのです。フィッシングを成功させるには一部のユーザをだますだけでも十分です。

エンドユーザが安全にインターネットを利用するためにIDNが役に立つとは到底思えません。IDNが一般化すれば先ほどの馬鹿げた例よりもっと効率的にフィッシングできます。往々にしてコンピュータに詳しくないユーザがフィッシングに騙されやすく、新しいTLDやIDNでフィッシング被害に合う確率が高くなる、と予想できます。コンピュータに詳しくないユーザは、怪しいIDNリンクをクリックした後にxnで始まる名前に変換されても意味をなさない場合も多くあると予想できます。

さらに日本語のIDNドメインは安全性の問題は重大だと思います。たとえば、

http://テレビなら○○.com/
http://DVDなら○○.com/
http://○○のテレビ.com/
http://○○のDVD.com/
http://パソコンの○○.com/
http://家電のことなら○○.com/
http://安心の○○.com/
http://○○のユーザサポートコーナー.com/
http://○○のサポートサイト.com/
http://聞いて安心○○サポート.com/

複数の単語を使ったそれらしいフィッシング向きのドメイン名はいくらでも作れます。日本語ドメイン名にすることにより長いドメイン名でも違和感が少なくなります。適当に有名メーカ・ブランドの名前を○○に入れると騙されてしまうユーザはいくらでもいると思われます。匿名組合に投資して「パンフレットに有名企業の企業名とロゴがあったので信用したのに… 損失はその企業に補てんもらわねば」というお国柄です。マーケティングの事しか考えてない日本語ドメイン名が溢れ出すとどうしようもなくなります。

もしIDNの利用が増えるようであれば、有名企業はIDNを使わないことを宣言してユーザに注意を喚起しなければならないと思います。IDN以外のドメインも、サービスを提供しているドメインはメインサイトで一覧にするなどの処置をし「リスト以外のサイトはフィッシングサイトの可能性があるのでご連絡ください」などと協力をお願いする方が良いと思います。

とにかく、またTLDが増えなくて何よりです。IDNも無くなればよいのですが…