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ライブラリの脆弱性がレポートされています。
整数オーバーフロー等はずっと以前に指摘され、ずいぶん長い間ディストリビュータがパッチで対応していた問題と同一のような気がしますが、どうなんでしょ?
mhtmlの脆弱性は非常に古くから指摘されていたので、大方は直っていると思っていたのですが
http://openmya.hacker.jp/hasegawa/security/ms07-034.txt
によると直してなかったのですね。
これだけではないので、Webアプリを真面目に作っている人からすると真面目にやっているのが馬鹿らしくなります…
最近、画像がらみエントリが多いです。
この容疑者が開発したウィルスは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
前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか 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コードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。
典型的な攻撃のシナリオは次の通りです。
追記：Tokenizerを使った例に修正しました。
いくら個人ブログで「信頼するに足る会社は日本語ドメインを利用すべきはない」
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のパスで十分でしょう。
顧客を大切にする会社はドメインを節約しましょう。使用するドメインが少ないほど、顧客がフィッシング詐欺被害に合う確率が減るはずです。
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ではリモートファイルインクルード脆弱性でよく知られている問題ですがなかなか無くならない問題です。探してみると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プログラマにとっては常識なはず(?)の動作です。
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脆弱性にはログアウトで対策するしか無いです。
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と言うクラスにコマンドインジェクションの脆弱性があったようです。リンク先を見れば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
追記：調査を行っていないので何となくですが、ファイルインクルードバグよりコマンドインジェクションバグの方が悪用される確率が高いような気がしています。脆弱性的にはファイルインクルードバグの方が強力ですが、攻撃用コードを別ホストに配置するのが面倒なのか(?)コマンドインジェクションの方が悪用されているような気がします。
# ファイルインクルードバグには攻撃用コードを
# 直接挿入できる場合もあります。
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による寄付もありますが応援メールも有効です。（こういうメールは英語が下手でも問題はないです）
SPAMはお金になる、ということでCAPTCHAを解読して売っているそうです。
1000のCAPTCHAを解読して7～15＄だそうです。一時間に数百くらいしか解読できないと思われるので、日本なら普通のバイトの方がよっぽど儲かります。しかし途上国では特別なスキルなしに収入になるのでこのような低報酬でも十分です。
CAPTCHAも使い物にならなくなるとSPAM対策は非常に難しくなります…
もう何年か前になりますがStefanさんがPHPプロジェクトへの貢献を始めたころ「整数オーバーフローの修正はセキュリティ脆弱性なのでそのことを明記すべき」と指摘した事がありました。信じがたいかもしれませんが「攻撃可能かどうか分からないし脆弱性でなく普通のバグ修正だ」と主張する開発者がいたためPHPのこの手のヒープオーバーフローセキュリティ修正は「fixed crash」とCVSログに書いてあるだけの場合が多く、NEWSファイルにも記載されない事が当たり前になっていました。
カーソルファイルの脆弱性で.aniブラウズするだけで攻撃される可能性がある、ということですが似たような脆弱性があったと思いググるとありました。
http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20041224/154283/
実際、同じような脆弱性が何度か現れることは非常に多いです。
2、3年後にもう一度はある!?