月: 2006年3月

このアドバイザリ、ちょっと待った

これはコードブログに書こうと思ったらTypePadのパスワードが分からなくなっていました。ブラウザに記憶させたはずなんですけどね…. とにかく以下のSECUNIAアドバイザリは(今度こそ)本当に間違っています。
# 前にCVSの更新が異常だったため勘違いしていた件がありました。
# 今度はSECUNIAが勘違いする番ですね。

TITLE:
PHP “mb_send_mail()” and IMAP Functions Security Bypass

SECUNIA ADVISORY ID:
SA18694

VERIFY ADVISORY:
http://secunia.com/advisories/18694/

CRITICAL:
Less critical

IMPACT:
Security Bypass

*省略*

SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.

PROVIDED AND/OR DISCOVERED BY:
Cdric Clerget

詳しいPoCはリンク先のアドバイザリを参照していただくとして、mb_send_mailとmailの第五引数(sendmailコマンドへの追加の引数)は内部関数php_escape_shell_cmdでエスケープされています。

PoCでは普通の引数を渡しているのでphp_escape_shell_cmd関数でエスケープしても、当然ですが、そのままsendmail関数のオプションになります。

つまり、mb_send_mailだけでなくmailでもまったく同じ現象(現象です。これは問題ではありません)が発生します。コマンドの実行に注意をはらうのと同じでmail/mb_send_mail関数の第五引数の指定にも注意が必要です。

オリジナルのアドバイザリはBugTraqにあます。safe_mode/open_basedir設定のバイパスが可能なことがセキュリティ上の問題だ、としていますがsafe_mode/open_basedirはfail safe (フェイルセーフ)の為の機能です。つまり、プログラムのバグがあっても意図しないファイルへのアクセスリスクを低減させるための仕組みであって、悪意を持ったプログラマからシステムを保護する機能ではありません。

CRITICAL:
Less critical

IMPACT:
Security Bypass

となっているので気にする人はいないと思いますが、対策が以下のように書いてあります。

SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.

Secuniaは何を言いたいのでしょうね?

mail関数はconfigureスクリプト実行時にsendmailバイナリを見つけられないと組み込まれません。多分、mail関数も組み込むな、とアドバイザリがでるのでしょう。

別に気にする必要はないアドバイザリですが、この対策は非常にいただけません。
百歩譲っても「disable_functionに指定する」くらいが妥当なのではないでしょうか?

追記:
SECUNIAのアドバイザリは

1) The PHP “mb_send_mail()” function allows additional parameters to be passed to sendmail via the “additional_parameter” parameter. This can be exploited to cause sendmail to read arbitrary files on the system as configuration file and saving the resulting log file to arbitrary writable directories. The saved log file may contain portions of the file that was read as configuration file.

Example:
$additional_param = “-C “.$file_to_read.” -X “.getcwd().”/”.$output_file;
mb_send_mail($email_address, NULL, NULL, NULL, $additional_param);

Successful exploitation allows the bypassing of certain “safe_mode” and “open_basedir” restrictions.

The vulnerability has been confirmed in version 5.1.2 and also reported in version 4.x. Other versions may also be affected.

と書いてあるのですが、safe_modeのバイパスだ、と書いていません。
オリジナルのアドバイザリを良く読むと、safe_modeの時だけ問題がある、旨で書かれています。ソースを確認してみるとmb_send_mailの方はsafe_modeのときに5番目の引数があっても受け付けるようになっていました。
# これは修正をCVSにコミットしました。久しぶりに。

mail/mb_send_mailの両方open_basedir設定はバイパスできるのですが、SECUNIAのアドバイザリではsafe_mode, open_basedirのどっちの事を言っているか分かりませんね。open_basedirがバイパスできることも問題らしいので「mail関数は組み込むな」とアドバイザリを作る(?)のでしょうね。

繰り返しになりますが、SECUNIAのアドバイザリでは対策として

SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.

と書いていますがimapもmbstringも普通に使っていれば安全に使えます。

Mailヘッダインジェクション

PHPのmail関数は\r\n,\r,\nを無視するようになっていてmb_send_mail関数の方は、チェックするマクロがphp_mail(PHPの内部関数)の前のPHP_FUNCTION()の部分で実行されていたので、mb_send_mailを使っているとMailヘッダインジェクションが出来てSPAMの踏み台にされる。という問題がありました。PHPユーザの方は覚えていると思います。

同じ問題がhns(Perlの日記アプリ)にもあったのですね。

PHPのmail関数のチェックは余計なお世話、とも言えるチェックです。PHPに慣れて他の言語でプログラムを書くと同じようなミスをするかも知れません。ユーザ入力は全部、確実にチェックしていれば防げる問題ですね。

HTTPヘッダの挿入も問題があるので今のPHPは\r\n, \r, \n, \tはheader関数ではじく様になっています。

システムではじいていても攻撃されていたかは知っておくべきですし、システムが適当に安全に処理してくれるから、といって未確認のデータを外部システムには送るべきではありません。

攻撃と言えるほどのものではないですが、他人のサーバに悪戯はいけません

攻撃と呼べるほどの物ではありませんが、今日の真夜中から現在にかけてこのblogによからぬアクセスが3つほどありました。全て国内のISPからのアクセスです。
# 海外からの攻撃、明らかにワームなどに感染しているコンピュータからの攻撃、
# 色々ありますが普通は無視ですけどね ;)

そのうちの1つはセキュリティチェック用のスキャナでセキュリティホールの検出を試みていました。子供の遊びのようなものなので目くじらは立てませんが、ODNを使っているあなた、無断で人のサーバにセキュリティチェック用のスキャナをかけてはいけません。

今後20年間はムーアの法則は安泰

半導体メーカーの予測、および米半導体工業会(SIA)の技術ロードマップによると、CPUに集積されるトランジスター数は、現在の10億個から2年後には倍の20億個、4年後にはなんと40億個になるという。SIAのロードマップは、チップの小型化と集積度増大が2020年まで続くと予測している。

 インテル社とAMD社は、ギガヘルツで計測しているCPUのクロック速度について、消費電力と発熱の制約があるため、今後は過去のようなペースでは向上しないと述べている。それでも両社は、さらなる集積度増大により、チップ上に複数のコアを搭載して性能の飛躍を図るはずだ。インテル社によると、10年以内には1個のプロセッサー上に100個ものコアが搭載されるようになるかもしれないという。

100個もコアが乗らなくても、1つのCPUに10も20ものコアが乗るようになるだけで別次元のアプリケーションの可能性が出てきます。システムレベルのS/W開発者はもちろんアプリケーション開発者もこのような状況を見据えて開発する必要がありますね。