yohgaki's blog

Other

VaioのHDD壊れる…

7月 14, 2007 投稿者 yohgaki

Windowsのメインマシンとして利用していたVaio Z1ですがHDDが壊れました…時間がないのでここ数日はZero3のメール（仕事のメールだけ）しか見てません。# メールを送っている方、済みません

なんとなくHDDへのアクセスの感じが変わったので、もしかして、と思い次のノートPCはMacBookに決めていたので新しくMacBookは買っていたのですがバックアップはプロファイルディレクトリだけだったので、最近の書いたサンプルコードが消えてなくなりました。結構がんばって書いたのに… subversionリポジトリ作成を後回しにしていた付けです。同じコードを書き直すのは疲れるんですよね…

壊れたのは数日前でやっとましな環境になった、と思ったらOSXとVistaの両方が使えるようにParallels DesktopをインストールしていたのですがParallelsを起動しているにも関わらず何故かWindowsのボリュームは共有ではなくボリュームとして見えていたので開いてみるとNTFSがボロボロに壊れてしまいました。ボリュームはリードオンリーなのかな?と思っていたらリードライトだったのですね… もしParallels Desktopが起動しているときにWindowsのボリュームが見えても決して開いてはいけないようです。（普通は隠れる）

文面から分かると思いますがまだあまりParallels Desktopは使っていませんが結構便利にできているのでXP/Vistaのライセンスが余っている人にはお薦めだと思います。試用版があるのでためし易いです。（私もまだ試用版）ただし、何もしてなくても50%CPU時間を消費（Vista Business）ので軽くはないです。いざと言うときはにbootcampで起動すれば良いので困らないと思います。

ところでParallels DesktopはbootcampにインストールしたWindowsを起動できるので既にWindowsをbootcampでインストールしている人なら追加ライセンスは要らないようです。（間違っていたら教えてください）共有を利用してWindowsからOSX、OSXからWindowsのファイルが扱えるようになっているのは便利です。直接OSXのファイルをWindowsアプリで開くことができるなどかなり便利です。

追記：プロファイルのデータをコピーしはじめたら1日以上かかるって….

Computer, Development

PHP4のサポート終了は2008/8/8

7月 14, 2007 #PHP 投稿者 yohgaki

現状でもセキュリティフィックスの状態があまり良いとはいえないのでPHP5が利用できる場合は積極的にPHP5を利用すべきですが、2007/12/31まで通常メンテナンス、以後2008/8/8までセキュリティフィックスには対応ということです。

まだの方は早くPHP5に移行しましょう。

間違っても5.1系に移行しないようにしましょう…　5.1系は今現在もメンテナンスされていません… 5.2系のみメンテナンスされています。

Computer, Programming

Example 1428. A “Best Practice” query

7月 4, 2007 #PHP 投稿者 yohgaki

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に渡すべきだと思います。

Security

GDにセキュリティホール

7月 3, 2007 投稿者 yohgaki

GDの開発は終わっている、と思っていたらphp.netでホストしてたんですね。PHPの独自拡張など色々追加されていたので自然な流れとは思います。

CVE-2007-3472、CVE-2007-3473、CVE-2007-3474、CVE-2007-3475、CVE-2007-3476、CVE-2007-347、CVE-2007-3478

とGDライブラリの脆弱性がレポートされています。

整数オーバーフロー等はずっと以前に指摘され、ずいぶん長い間ディストリビュータがパッチで対応していた問題と同一のような気がしますが、どうなんでしょ?

Security

直していなかったのか… mhtml

6月 26, 2007 投稿者 yohgaki

mhtmlの脆弱性は非常に古くから指摘されていたので、大方は直っていると思っていたのですが

http://openmya.hacker.jp/hasegawa/security/ms07-034.txt

によると直してなかったのですね。

これだけではないので、Webアプリを真面目に作っている人からすると真面目にやっているのが馬鹿らしくなります…

Security

携帯用ウィルスが流行しているとは聞いていましたが、12万台とは…

6月 26, 2007 投稿者 yohgaki

最近、画像がらみエントリが多いです。

この容疑者が開発したウィルスはBuletooth内蔵型の携帯電話で用いられているSymbian 社製の組み込み機器用OSに感染するというもの。アダルト画像ファイルなどを経由して他の携帯電話に感染。ウィルスに感染した携帯電話は12万台近くにも及んでいた。

作者が逮捕されたそうですが、どこから出所が判ったのか興味があります。

最近のエントリで画像のバリデーションにフォーマット変換を用いた方法を紹介しました。「自分のサイトだけ守れれば良いのでは?」とされる意見を頂いていたのですが、そうは言っていられない事例の一つだと思います。

参考：
http://blog.ohgaki.net/index.php/yohgaki/2007/06/24/c_ra_a_a_ia_ca_la_ljavascripta_e_na
http://blog.ohgaki.net/index.php/yohgaki/2007/06/24/c_ra_a_a_ia_ca_la_lphpa_sa_fa_a_a_a_effa

Computer, Security

画像ファイルにJavaScriptを隠す

6月 24, 2007 投稿者 yohgaki

前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか 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を埋め込んだイメージファイルがアップされています。

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

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

PHP Security, Security

画像ファイルにPHPコードを埋め込む攻撃は既知の問題

6月 24, 2007 投稿者 yohgaki

国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。

典型的な攻撃のシナリオは次の通りです。

追記：Tokenizerを使った例に修正しました。

Security

日本語ドメインは覚えやすい、分かりやすい、そしてだましやすい

6月 23, 2007 投稿者 yohgaki

いくら個人ブログで「信頼するに足る会社は日本語ドメインを利用すべきはない」

http://blog.ohgaki.net/index.php/yohgaki/2007/04/03/xxxa_a_ia_ca_sa_aac
http://blog.ohgaki.net/index.php/yohgaki/2005/02/12/a_fe_a_a_a_ia_ca_sa_a_ra_a_pa_a_ma_sa_de

と書いても、そのうち日本語ドメインが氾濫するのでしょう…

お名前.comから送信されたメールに次のように書いてあります。

┏━━━━━━━━━━━━━━━━━━━━┓
┃日本語ドメインは覚えやすい！　　　　　　┃
┗━━━━━━━━━━━━━━━━━━━━┛
長い名称やキャッチコピーをドメイン名にする際に、ローマ字ドメインに比べて日本語ドメインの場合、「覚えやすい」「入力しやすい」といったメリットがあります。

1.商品名・キャッチコピーで登録
　　http：//お名前.com
　　http：//ドメイン取るならお名前.com

日本語の名詞をドメインに利用するだけでも問題ですが、最悪なのはキャッチコピーをドメインに利用する場合です。

http://ドメイン取得はお名前.com/

とフィッシャーが登録したらどうでしょうか? お名前.comそっくりのサイトにしてユーザ名とパスワードを盗んだ後、本当のサイトに接続させれば多くのユーザはIDが盗まれた事に気がつかないと思います。ドメイン登録情報の改ざんはサイトの価値に関わらずお金になりそうです…

信頼が重要な会社は、TLD、ccTLD以下のドメインには以下のようなルールを作るべきだと考えています。

– 国際化ドメイン(IDN)は使用しない
– 子会社などを”-“使用したドメインを使用しない
– キャンペーン用のドメインは作成しない
– 製品名でドメインは作成しない
– 広く認知されているドメインのサイトで利用しているドメインを全て記載する

などの対策が必要です。子会社、キャンペーン、商品・商標名で絶対にドメインを作ってはならないとまでは言いませんが、ほとんどの場合はサブドメインやURLのパスで十分でしょう。

顧客を大切にする会社はドメインを節約しましょう。使用するドメインが少ないほど、顧客がフィッシング詐欺被害に合う確率が減るはずです。

Computer, Development, Security

tidy_parse_string() オーバーフロー

6月 22, 2007 #PHP, #脆弱性投稿者 yohgaki

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) 」とレーティングされても仕方ないところでしょう。

Security

Perlアプリ(YaBB)でローカルファイルインクルード

6月 21, 2007 投稿者 yohgaki

PHPではリモートファイルインクルード脆弱性でよく知られている問題ですがなかなか無くならない問題です。探してみるとPerlアプリにも同類の脆弱性が結構見つかるかも知れません。（Perlの場合はローカルのファイルしかインクルードできませんが）

2007/6/19のfull-disclosureに「local File Include Vulnerabilities in YaBB <= 2.1(all version)」と題するメールが投稿されていました。PHPならリモートファイルインクルード脆弱性となる典型的なコードが紹介されていました。

—Sources/Subs.pl:1529—
if (-e “$langdir/$use_lang/$what_to_load.lng”) {
require “$langdir/$use_lang/$what_to_load.lng”;
}
—end—

Perlでもシステムのどこかに攻撃用のPerlコードを保存できれば任意のコードを実行できるようになります。YaBBは名前からも分かるようにBBSアプリなので攻撃用コードをアップロードするのは容易なのかも知れません。もしかして、この種の問題は知られているようで知られていない??

Googleで”Powered By YaBB”で検索すると日本語ページで16900、サイト全体で136万ページヒットしました。アバダや投稿がファイルとして保存されている場合、攻撃は簡単だと思います。（コードを見たことがないので予想です）

追記：
なぜ攻撃が簡単かというと -e によるチェックはヌルバイトインジェクションに脆弱だからです。基本的にファイルの先頭にperlコードを書き込んで保存できる個所があればどのようなファイル名であってもインクルードできます。-eはfile_exists()に書き換える必要がありますがPHPプログラマにとっては常識なはず(?)の動作です。

Security

Apache MyFaces Tomahawk JSF Framework Cross-Site Scripting

6月 21, 2007 投稿者 yohgaki

6/12にApache MyFaces TomahawkにXSS脆弱性が修正されています。

Java Server Faces, JSF, is “a framework used to create server side GUI Web applications. It is comparable to the Java Struts framework. Apache MyFaces Tomahawk is an open source implementation of JSF. The Tomahawk version contains Apache extensions to the base specification”. Remote exploitation of an input validation vulnerability in Apache Software Foundation’s MyFaces Tomahawk JSF framework could allow an attacker to perform a cross-site scripting (XSS) attack.

autoscroll属性に設定された値がバリデーション、エスケープ処理無しにそのまま出力されている事が原因だそうです。1.1.6で修正されています。

http://www.vulnerable.tld/some_app.jsf?autoscroll=[javascript]

の様に簡単に攻撃出来てしまうので価値が高いサイト（JSFで作ってあるサイトの多くは攻撃対象となるようなサイトばかりと思いますが..）の場合は早めに対処した方が良いと思います。

JSFでサイトを作ると結構簡単にインタラクティブなサイトを作れますが、セキュリティの多くはフレームワーク任せになってしまいます。あまりMyFacesの脆弱性は聞きませんが見つかった場合の対処は最初から決めておかなければなりません。JSFを使って開発しているようなサイトの場合、セキュリティポリシーもしっかり定義してあるはずなので大丈夫だとは思いますが、動きが遅いところもあるので…

MyFaces Tomahawk 1.1.6 has been released. This is an important security related update that fixes a severe XSS (cross-site scripting) bug in the Tomahawk 1.1.5 release (CVE-2007-3101).

MyFacesのサイトでは「severe XSS bug」と記載されている様に非常に危険なバグです。

ところで、TomcatにもXSS脆弱性が公開されています。こちらは対策が無い状態ですがしばらくするとアップデートが公開されると思います。きちんとしたサイトがサンプルプログラムをインストールしていたりはしないと思いますが、アップデートが公開されるまでは管理者インターフェースのXSS脆弱性にはログアウトで対策するしか無いです。

Computer, Development, Security

PHPセッションの問題修正

6月 16, 2007 #PHP, #セッション管理, #脆弱性投稿者 yohgaki

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

Computer, Security

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

6月 12, 2007 #OSコマンドインジェクション, #PHP, #WordPress, #脆弱性投稿者 yohgaki

個人的には影響ないですがいろいろなアプリケーションで使われている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

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

Computer, Security

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

6月 9, 2007 #PHP, #脆弱性投稿者 yohgaki

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による寄付もありますが応援メールも有効です。（こういうメールは英語が下手でも問題はないです）