PHPのStrictセッション

PHPのStrictセッション

Strictセッション管理パッチのダウンロード数がやっと?100を超えました。

PHP5用のパッチなのが一番の問題なのでしょうか?非常にダウンロード数が少ないように思えます。私はこのパッチはセキュリティ上かなり重要なパッチだと思っています。

PHP4のパッチが必要なのかな? 枡形さんが作ってましたっけ?

関連:
http://blog.ohgaki.net/index.php/yohgaki/2006/02/02/strict_sessioncric_a_a_a
http://blog.ohgaki.net/index.php/yohgaki/2006/02/05/phpa_rsession_fixationa_ei
http://blog.ohgaki.net/index.php/yohgaki/2006/02/27/a_ma_sa_sa_ma_ca_a_ma_a_sa_f

日本ではFirefoxは不調

最も高いのが欧州で20.10%、次いで豪州近辺の18.60%、北米の15.88%、アフリカの9.41%、アジアの8.81%、南米の5.79%だった。日本は中でも低く4%台だという。リリー氏は、「欧州ではかなり人気が高い。これはオープンソース好きという民族性だからだろうか。日本はそれに比べてかなり低いが、正直なところ主な原因は分かっていない。

日本のMicrosoft好きは今に始まったことではないです。WindowsNTが出たときも海外ではまだまだだった時から日本ではかなりの人気でした。日本人はMicrosoft好きという傾向はかなり強いようです。書籍も「Windowsに対応」と書いたり最初のほうに「C:\」が含まれている本の方が桁違いによく売れる(らしい)と聞いています。
# 最近新しい本を書き終えましたが、この法則に従っていませんね :p

だたIEはお勧めできるブラウザではないのは確かです。MS製品が嫌いという事ではないのですがIEは「個人的には怖くて使えない」が本音です。今年に入ってからもかなり過激なセキュリティホールがレポートされていますが、乗り換え組みはまだまだ少ないのですね。

そう言えば、このブログでもGoogleのFirefox Toolbarの紹介リンクを作っていますが紹介料って無かったか、有っても1回ぐらいだったような気がします。本当にあまり使われていないのかな?!

関連
IE, Firefox, Opera? どれを使う?

1秒で100万人の顔を識別し認証

 NEC (金杉明信社長)は、顔認証技術を利用した製品・システム開発用の顔検出・顔照合エンジンソフトの最新版「NeoFace Ver2.4」を発表した。業界最高速レベルとなる1秒間で100万人の顔データが照合できるのが特徴。5月から出荷を開始する。税別価格は250万円から。

100万人/秒とはすごいですね。従来型でも40万人/秒だったらしいです。

顔認証で時刻を登録する出退勤管理システム「NeoFace朝顔」を4月3日、3月6日にそれぞれ発売する。

ということらしいですが、この手の認証は再生攻撃に弱いので学生の出席確認などに利用すると再生攻撃が実際に行われそうです。(顔写真を機械に見せる)

「フェイスキーキャビネット」は事前に登録した顔データを鍵としてキャビネットの扉の開閉管理と利用者すべての操作履歴の顔画像を記録するシステム。不正利用者の特定やオフィス内の重要書類や機密データの流出を防止に利用する。

再生攻撃対策が行われているのでしょうか? 今時はデジタルカメラ・カラープリンタはどこにでもあります。写真での再生攻撃対策に2つくらいはカメラが付いているのかな?

警察に買ってもらいATM等のカメラと連動させれば、犯罪者を逮捕する為に使えそうな気がします。精度も問題ですが100万人/秒ならかなり使えそうな気がしますが、検証する部分を減らしているので変装に脆弱なのかもしれませんね。

顔認証ねたが他のサイトでもありました。

賛否両論ですが顔認証はやはり便利かも?!

商売的にはどうかというと

ドゥーシッチ氏によると、バイオバウンサーは3月中の発売を予定しているという。初期費用は7500ドルで、年間の利用料およびサポート料が6000ドルかかる。これだけの費用が必要になるにもかかわらず、すでに米国内、オーストラリア、ニュージーランド、イタリアから引き合いを受けていると、ドゥーシッチ氏は話す。

ということらしいです。NECさん、キャビネット作っている場合ではないかも?!

Thunderbirdの脆弱性に注意

Thunderbirdでリモートのリソース(Webビーコンの画像ファイルなど)を読み取らない設定にしていてもリモートリソースを取得してしまう問題があるそうです。メールが読まれたか分かってしまうのでSPAMメールなどには特に注意が必要です。

GoogleにXSS

詳しくはリンク先を見ていただくとして(脆弱性の詳しい情報は書いてありません)、パーソナライズド機能やgmailは修正されるまで使わない方がよいらしい。

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

これはコードブログに書こうと思ったら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開発者はもちろんアプリケーション開発者もこのような状況を見据えて開発する必要がありますね。

WikiにgoogleのAdWordsを追加

WikiにAdWords広告を追加してみました。AdWord広告は自分のBlog・Wikiにどんな広告が掲載されるか確認する事が主目的で付けているのですが上の方の広告だけだと見るたびに同じ広告なので面白くありません。右側に追加してみたらいろいろ見たことが無い広告が表示されるようになりました。

blogもそうですが書いてあるコンテンツによって表示される広告が変わるのは割と面白いです。よく出来ているからGoogleは儲かっているのですが、AdWordsよく出来ていますね。

PHP_SELFはそのまま出力できない

追記:現在のPHPでは$_SERVER[‘PHP_SELF’]はクエリ文字列(?以降のクエリパラメータ)を含みません。しかし、index.php/<script>alert(1)</script>/aaa/bbb とすることは可能です。PHP_SELFと同様の変数は以下です。

  • $_SERVER[‘PATH_INFO’]
  • $_SERVER[‘PATH_TRANSLATED’]

 

時々見かけるのでブログでも問題を指摘します。

PHPの$_SERVER配列に入っているPHP_SELF要素はPATHINFOも含めてしまうため、そのまま出力するとXSSに脆弱になる場合があります。

phpinfo()がXSSに脆弱だ、と指摘する人がいるので(元々phpinfo()の出力は管理者・開発者のみ参照できるようにしておくべきですが..)現在のPHPはPHP_SELF内の< > を検出して

<script> </script>

等と書けないようになっています。しかし、この対策はphpinfo()の事しか考えていないので

<?php
echo '<a href="'. $_SERVER['PHP_SELF'] .'">aaa</a>';
?>

の様なケースの場合、

http://example.com/xss.php/%22%20onMouseOver=%22javascript:alert(‘xss’);

等としてJavaScriptの挿入が可能になります。

SCRIPT_NAMEにはPATH情報が無いのでこの問題は発生しません。PHP_SELFでは無くSCRIPT_NAMEを使用すべき所をPHP_SELFを利用しているケースは時々見かけます。

注意が必要かもしれませんね。

UNIX系OSならPHPのソースがあるディレクトリに移動して

find . -name “*.php” | xargs grep -n “PHP_SELF”

等として怪しいPHP_SELFの出力が無いか確認すると良いかも?!