cles::blog

数日前から騒がれていますが、CGIで動作させているPHPに影響度が大きい脆弱性が見つかったようなのでメモ。
普通の人は php を mod_php として動かしていると思うので、関係する人はそんなに多くないとは思いますが、心あたりがある人はチェックしておいた方が良さそうです。

「PHP 5.4.2」におけるCGI関連のバグ修正は不完全、5月8日に再リリースへ - SourceForge.JP Magazine : オープンソースの話題満載

この脆弱性はCGIベースでPHPを動作させている一部の環境で発生するもので、悪用されると遠隔からコードが実行されてしまうという。脆弱性情報のCommon Vulnerabilities and Exposures（共通脆弱性識別子）では「CVE-2012-1823」と識別されており、Apache＋mod_phpや、nginx php-fpmは影響しないとしているが、Apache＋mod_cgiを利用している場合は影響を受ける可能性があるとしている。PHP開発チームでは確認方法として、URLの最後に「?-s」を加えてページを開いた際にソースコードが表示された場合は影響を受ける可能性があるとしている。

† 参考

• CVE - CVE-2012-1823 (under review)
• CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823) | 徳丸浩の日記

AWS Elastic Beanstalk が Apache Tomcat に続き PHP をサポートすることを表明しているのでメモ。
PHP が動くとなるとウェブ系の様々なアプリをデプロイできるようになるので、これは面白くなってきますね。

【AWS発表】 AWS Elastic BeanstalkにてPHPのサポート開始、Gitを用いたデプロイも可能に - Amazon Web Services ブログ

AWS Elastic Beanstalkを用いると、AWSクラウド上で、素早く簡単にアプリケーションのデプロイや管理ができます。単純にコードをアップロードすれば、Elastic Beanstalkが自動的にEC2、ロードバランシング、オートスケーリング等を含むデプロイメントを処理してくれます。それに加え、もし必要なときは、上記のAWSのリソースを直接管理することも可能です。例えば、EC2インスタンスに直接ログインして変更を加えることもできるのです。Elastic Beanstalk自体には料金はかかりません。実際に利用しているEC2インスタンスなどの料金のみ必要となります。

php で PHP Fatal error: Cannot use string offset as an array という見慣れないエラーが出たのでちょっと調査。
これは PHP4 の時にはエラーになっていなくて、PHP5 からエラーになるようになった模様。

とりあえず一番短い実証コードは下記のような感じ。

stringoffset.php

これを実行すると、5行目でエラーが発生します。「phpでcannot use string offset as an arrayエラー - Neo Inspiration」でも触れられている通り、 String に対して３次元配列でアクセスしようとすると発生するエラーのようです。ちなみに $str[1] の var_dump() の結果は string(1) なので、string(1) だけ扱いが違うのかもと思って、下記のようなプログラムを作って検証してみました。

stringoffset2.php

こっちは通ってしまいました。 var_dump() の結果はどちらも string(1) ですが、内部的には扱いが違うということなのでしょうね。
とりあえず１つの array に string や array や　int をごっちゃに格納しなければいいということですね。

少し前に Facebook から HipHop Virtual Machine というものがリリースされたというものが流れていたので気になっていたんですが、これについても、原型の Hiphop compiler についても、動かした（動かせた）という情報をあまり見かけなかったのですが、その最適化内容を考察しているサイトを見つけていたので忘れないうちにメモ。

PHPのJITコンパイラ「HipHop Virtual Machine」、Facebookがオープンソースで公開 － Publickey

Facebookは10日、PHPを高速に実行する仮想マシン「HipHop Virtual Machine」（hhvm）を公開しました。
HipHop Virtual Machineは、PHPを高速に実行するためにPHPのコードをC/C++に変換してg++でコンパイルし、バイナリコードにするHiphop compiler（hphpc）と、PHPのインタプリタであるHipHop interpreter (hphpi)を組み合わせたもの。PHPのコードをダイナミックにバイナリコードへと変換することで、高速な実行を目指しています。

実際に HipHop Compiler を動かす環境を作るのは結構めんどくさい作業のようで、これが普及の妨げになっているようです。

　・hiphop php でPHPからジェネレートされたC コードを読んでみよう。 - お前の血は何色だ!! 4
　・hiphop php でPHPからジェネレートされたC コードを読んでみよう。 (後編) - お前の血は何色だ!! 4

ちょっと時間を作って上記の環境を実際に作って試してみようと考えています。

ウェブアプリケーションに共通する DoS 攻撃手法として hashdos というものが出現しているらしいのでメモ。

徳丸浩の日記: Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策

連想配列の実装には、高速な検索が要求されるためハッシュテーブルが用いられます。ハッシュテーブルは、文字列を整数値（ハッシュ値）に変換するハッシュ関数を用いて、平均的には一定時間に検索・挿入・削除が行えるデータ構造です。しかし、ハッシュ値が一致する（衝突する）キー文字列については、通常ハッシュテーブルは順次的な探索となり、検索・挿入などが遅くなります。
hashdosは、ハッシュ値が同じになるキーを多数POSTパラメータに含ませることにより、CPU資源を枯渇させる攻撃です。

試しにローカルで exploit を実行してみましたが CPU を使い切ってしまいました。
mod_security によって対策できるようなので、下記のルールを有効にしておきました。

とりあえずこれで急場はしのげそうです。

NP_Exif で画像の EXIF 情報は出力できるようにしているのですが、レンズが増えてくると、焦点距離よりもレンズ名が表示したくなります。
ということで、レンズ名をプログラムで取得して表示する方法について調べてみました。

生の EXIF データを眺めて見てみると LEICA DG MACRO-ELMARIT 45/F2.8 のような文字はあるので、とりあえずきちんとパースできればデータを取り出すことはできそう・・・・というところまではすぐに分かったのですが、ここから一筋縄ではいきませんでした。どうもこのデータが入っている部分は MakerNotes と呼ばれるメーカー独自の記録領域で php に含まれている read_exif_data() で Panasonic機（GF1 / GX1）の EXIF をパースすると 8kB のバイナリデータとしてしかアクセスすることができませんでした。

とりあえず中身については解析してくれている人がいて、ある程度フォーマットも明らかになっている^*1ようなので、これに対応したパーサーを捜してみたところ、下記のものが見つかったので今回はこれを使うことにしました。

　・The PHP Metadata Toolkit

以下、作業メモ。

• ^*1: Panasonic MakerNote Format Specification
  

PHP から memcached にアクセスするためには普通は PECL の memcache か memcached のどちらかを使うことになると思います。末尾にdがついてるかついていないかという１文字の違いで紛らわしいのですが違うパッケージです。

以前 memcached を使い始めた頃は前者のライブラリを使っていたのですが、今回は後者のライブラリをインストールしてみます。PECL memcached は memcache プロトコルの実装を libmemcached を使って実現していることが特徴のようです。

以下、インストールメモ。

以前、Net::CIDR::LiteというIPアドレスの羅列からCIDR表現を生成するPerlのライブラリを紹介しましたが、今度はその正規表現版とも言うことが出来るphp向けライブラリが公開されていたのでメモ。
これを使うと、複数の単語にマッチする最適化された正規表現を簡単に得ることが出来ます。

正規表現じぇねれーた

改行区切りで単語を入れると、すべての単語にマッチする正規表現を自動的に作成します。

perlにはRegexp::Assembleという正規表現を作成してくれるモジュールがあります。
これを PHPに移植して、 Regexp Assemble For PHPなるモジュールを作って見ました。

例えば、このサイトで使っているコメントのブラックリストの最適化をしてみます。これまで正規表現については単語を単純にOR(|)でつなげていたのですがこのライブラリを使うことでこのように変換することができました。今のところ特に問題はなさそうです。

なかなか面白いライブラリですね。
需要ないかもしれませんが、これを使ってNP_BlackListを書き直したりするとちょっとは動作が速くなったりするかもしれません。

PHP 5.3.7 の crypt() に大穴があったということで騒ぎになっています。
当該のバージョンを使っている場合には、すみやかにダウングレードするのが賢明なようです。
アップデート版のPHP 5.3.8がリリースされたので、速やかにアップデートする必要があります。

徳丸浩の日記: PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)

PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。

過去にはIEが１文字の誤りから脆弱性を招いたということがあったように、バグとしては凡ミスですが、箇所が箇所だけに影響が大きいですね。

ockeghem(徳丸浩)の日記で見つけたphpMyAdminの脆弱性が興味深かったのでメモ。これを読む限りではやっぱり phpMyAdmin は不特定多数の人がアクセスできるところに置かない方がいいということになるのでしょうね。実はこのサーバにも phpMyAdmin は置いてあるにはあるのですが、SSL+BASIC認証がかけてあって僕以外はアクセスできないようになっています。

phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証 - ockeghem(徳丸浩)の日記

phpMyAdminのスクリプト実行の脆弱性（CVE-2011-2505、CVE-2011-2506）について報告しました。
私がこの脆弱性に関心をもったきっかけは、スクリプトが実行される脆弱性とはどのようなものなのだろうという興味からでした。もちろん、ファイルインクルードとか、evalインジェクション、あるいはアップローダの脆弱性など、任意スクリプトが実行できる脆弱性はいくつかあるわけですが、phpMyAdminの脆弱性はどれでもないように思えたからです。

今回のポイントは parse_str でSESSION変数が汚染できるということでしょうか。あまり使ったことない関数だなと思って調べてみたら extract と同じくregister_globalsの時代の残骸みたいなものなので、あまりオススメされない関数みたいです。ちなみにextractの方は下記のように汚染されているデータには使ってはいけないと大きく警告が表記されているので分かりやすいのですが、こちらには何も書いていないというのも要注意なところかもしれません。

警告
extract() をユーザー入力 ($_GET や $_FILES など) のような信頼できないデータについて使用しないでください。 もし行う場合、例えば register_globals を信頼しているような古いコードを一時的に実行したい場合、 EXTR_SKIP のような extract_type の値が上書きされていないことを確認してください。そして php.ini の variables_order で定義されたものと同じ順で展開すべきであることに留意してください。