名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。
何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。
# とは言ってもまだ新しい仕様のPHPは無いですが
α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。
もっと読む
ホワイトリストとブラックリストの議論はFirewallの利用が一般的になる過程で十分に議論され、90年代に議論され尽くした、と思っていました。しかし、解説の余地はまだまだあるようです。ネットワークFirewallによるセキュリティ対策を簡単に振り返り、セキュアコーディングの現状を考察したいと思います。
追記：このエントリはネットワークFirewallのポートフィルタリングについて議論しています。ホワイトリストで対策すべきはアプリケーション自体です。ネットワークFiewallはホワイトリスト型セキュリティで対策しますが、WAFなどのアプリケーションFirewallはブラックリスト方式で対策するのが現実的です。ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。
JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。
http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1
もっと読む
「ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。
参考： セキュリティを論理的に構築する方法 （こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ） もっと読む
たまたま目に止まったブログがあるので紹介します。
PHP:session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性
http://www.tokumaru.org/d/20080818.html#p01
[php]session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能
http://www.tokumaru.org/d/20080819.html#p01
この危険性はStrict Sessionパッチが作られた頃にも議論されていました。このパッチを摘要するとセッションアダプション脆弱性も修正します。もし、互換性なので要件で厳格なSession管理ができない場合でもセッションIDに利用可能な文字は安全な文字のみに限定されるのでパストラバーサルなどの問題は発生しません。
話は横道にそれますが、セッションアダプションの問題については、PHP 4.4.9リリース前にPHP Security Response Teamと議論しました。リリースノートを見れば解りますが、残念ながら良い結果ではありませんでした。いくつかの脆弱性をレポートしましたが、その内の一部の脆弱性のみに対応しただけです。これについては時間が出来次第エントリを書きます。
話を戻しますが、セッションモジュールの問題は随分前（何年も前）に議論されており、開発者のスタンスとしては「ユーザ側の問題」「ファイルストレージがあるのに態々自分作って自分の足を打つようなユーザが問題」「RDBMSをストレージに使ってエスケープしないでSQLインジェクションされるのと同じ」といった結論になってしまったと記憶しています。
セッションアダプションの問題を解決すれば、パストラバーサルの問題もSQLインジェクション問題も解決するのですが…
セッションアダプション脆弱性はリスクが不当に低く評価され過ぎです。PHPを利用されている方全てにStrict Sessionパッチをお勧めします。
Googleがクラウドコンピューティングの言語としてPythonを採用したのでセキュリティ研究家が脆弱性を調査し、今年はPythonの脆弱性が多く報告されるはず、とこのブログで予想しています。また新たな脆弱性が報告されているので書いておきます。
今回は整数オーバーフローが多いので、整数オーバーフローを中心に調査したのだと思われます。
Python 2.5.3以上でないと穴だらけと言えますが….
http://python.org/download/
と言った状況のようです。
しかし、予想通りとはいえ数が多いですね。
CVE-2008-3144
Multiple integer overflows in the PyOS_vsnprintf function in Python/mysnprintf.c in Python 2.5.2 and earlier allow context-dependent attackers to cause a denial of service (memory corruption) or have unspecified other impact via crafted input to string formatting operations. NOTE: the handling of certain integer values is also affected by related integer underflows and an off-by-one error.
CVE-2008-3143
Multiple integer overflows in Python before 2.5.2 might allow context-dependent attackers to have an unknown impact via vectors related to (1) Include/pymem.h; (2) _csv.c, (3) _struct.c, (4) arraymodule.c, (5) audioop.c, (6) binascii.c, (7) cPickle.c, (8) cStringIO.c, (9) cjkcodecs/multibytecodec.c, (10) datetimemodule.c, (11) md5.c, (12) rgbimgmodule.c, and (13) stropmodule.c in Modules/; (14) bufferobject.c, (15) listobject.c, and (16) obmalloc.c in Objects/; (17) Parser/node.c; and (18) as…
CVE-2008-3142
Multiple buffer overflows in Python 2.5.2 and earlier on 32bit platforms allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a long string that leads to incorrect memory allocation during Unicode string processing, related to the unicode_resize function and the PyMem_RESIZE macro.
CVE-2008-2316
Integer overflow in _hashopenssl.c in the hashlib module in Python 2.5.2 and earlier might allow context-dependent attackers to defeat cryptographic digests, related to “partial hashlib hashing of data exceeding 4GB.”
CVE-2008-2315
Multiple integer overflows in Python 2.5.2 and earlier allow context-dependent attackers to have an unknown impact via vectors related to the (1) stringobject, (2) unicodeobject, (3) bufferobject, (4) longobject, (5) tupleobject, (6) stropmodule, (7) gcmodule, and (8) mmapmodule modules.
PHP4のサポート終了に伴い、幾つかの未修正のセキュリティホールについてPHP Security Response Teamとやり取りしています。
ついでなので出来る限り多くの脆弱性が修正されるようにしたいと考えています。PHP4.4.8, PHP 5.2.6で未修正の脆弱性やセキュリティ上の問題をご存知の方は是非教えて下さい。
現時点はどの脆弱性をレポートしているのか書けませんが、もしPHP本体やモジュールで修正されていない脆弱性をご存知の方は教えて頂けると助かります。メールやこのブログのコメント、このブログのContactページ等からご連絡ください。
結果については後日このブログにて公開します。
桝形さんから
http://blog.ohgaki.net/php-5-2-strict-session
で公開したパッチのPHP4.4.8版を送っていただきました。私のWikiにも添付ファイルとして掲載させていただきました。
http://d.hatena.ne.jp/masugata/20080714#p2
に掲載されているパッチと同じパッチです。
私は全てのPHPユーザがStrict Sessionパッチ適用すべきと考えています。詳しくはWikiをご覧ください。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
桝形さん、パッチありがとうございました。
最近CVEのコピー&ペーストが続いていますがこのブログに書いていた予想通りの展開なのでまたコピーです。
コアとはいえあまり重要ではない箇所の脆弱性ですが、Python 2.5.3にリモートコード実行の可能性がある脆弱性がレポートされています。
CVE-2008-1679
Overview
Multiple integer overflows in imageop.c in Python before 2.5.3 allow context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted images that trigger heap-based buffer overflows. NOTE: this issue is due to an incomplete fix for CVE-2007-4965.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base score: 6.8 (Medium) (AV:N/AC:M/Au:N/C:P/I:P/A:P) (legend)
Impact Subscore: 6.4
Exploitability Subscore: 8.6Access Vector: Network exploitable , Victim must voluntarily interact with attack mechanism
Access Complexity: Medium
Authentication: Not required to exploit
Impact Type: Provides unauthorized access, Allows partial confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service
直したつもりが直っていないのはよくある事です。直したはずだったCVE-2007-4965は以下の通りです。
CVE-2007-4965
Overview
Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows.
なるほど、と思いました。
http://d.hatena.ne.jp/hoshikuzu/20080328
文字エンコーディングを規格に則り、完全にバリデーションしてもダメな時がある…
頭が痛い問題です。
件名の通り、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でオーバーフローしてます… 教科書通りの解りやすい脆弱性です…
OCamlはプログラミングコンテストで優勝するチームや開発者御用達の言語であることは以前から知っていましたが、個人的に利用しようと思ったありませんでした。しかし、最近関数型言語の人気が非常に高まってきています。関数型言語の簡潔なコードや副作用の少ないコードの生産性が認められてきたからだと思います。
OCamlを勉強しようかと思いましたが、AmazonでちょうどF#の本（英語版）が昨年末出版されている事を見つけて購入しました。
もっと読む
2月16日に札幌で行われたJPUG北海道 RUBY札幌 合同セミナーの資料です。
クリックしてPostgreSQL-Performance.pdfにアクセス
セミナーの際には風邪の為、声がでず、非常に聞き辛かったと思います。聞きにお越しいただいた方には申し訳ないです。
fsync=falseなのでかなり速い事は理解していただけたと思います。（かなりのスピートダウンですがfsync=trueでも速いです）セッションをデータベースで管理した場合などにfsync=falseで運用しても問題ないでしょう。しかし、絶対にデータベース上のデータの不整合は困る場合にはfsync=trueに設定しなければなりません。
とは言ってもfsync=falseの速さは捨てがたいと言う方はUPSを利用すると良いでしょう。UPSを付ければリスクはかなり低減できるので、リスクとメリットのトレードオフで選択すれば良いと思います。
UPSを使っても防げないデータの不整合
等が考えられます。
HDDの冗長化を行っていないサイトのデータベースであれば、fsync=falseが困る訳も無いでしょう。このような場合はfsync=falseでどんどん使ってよいでしょう。
fsync=falseはデータベースサーバ全体の設定なので結局は「ショッピングサイトなどでどんな場合でも受注済みデータが無くなると困る」のような要求があるとfsync=falseで運用できないのでは、とご意見も頂きました。このような場合でもログを別の方法で残す、例えば、メールで送信してしまう、別ディスクにジャーナルとして書き込む、など方法でデータ保存の方法を冗長化していればfsync=falseでも困らないサイトは少なくないと思います。そうは言っても、困る物は困る場合はfsync=trueで利用すると良いでしょう。
データベースに拘らずデータの冗長化を考えると、fsync=falseは強力な武器になります。
# PostgreSQL 8.3ならsynchronous_commit=offに設定してリスク
# を軽減する事も可能です。ところで、別ディスクにジャーナル
# として保存する場合はDBよりも先にジャーナルファイルに書き
# 込み、fsyncを忘れない様に注意してください。
# メール送信する場合はリモートのメールサーバが受け取った後
# にDBに書き込むように注意してください。つまりローカルのメー
# ルキューにいれるのみだとジャーナルのように使えない場合が
# あります。qmailならinjectが正常に終了すればOKだとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。
PHPのTaintモードパッチです。最近更新されていたようです。
ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080130.README.html
Taintモードはあれば良い程度の機能ですが、フールセーフ機能（フェイルセーフでなくフールセーフ – fool safe）としては便利です。入力バリデーション用のコードは必須ですが、そのようなコードが無い場合やあっても不完全な場合には有用です。
PHP 5.2.5よりCVS HEADとPHP_5_3ブランチ用のパッチを作った方が採用されやすいのですが….
このパッチは関数毎に違うマークを付けるtaintモードなのでかなり大きいです。(+遅い）
まずホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません。
例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1
私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力／出力の両方にホワイトリスティング対策をお勧めしています。3