カテゴリー: Programming

Session Adoptionが攻撃に有用な実例

PHP:既知のセキュリティ脆弱性 – Session AdoptionでWebmailアプリケーションであるSquirrelMailとRoundCubeがこの攻撃に脆弱であることを紹介しました。

タイミング良く(?)同じくPHPベースのWebmailアプリであるIMPにクロスサイトスクリプティング脆弱性が発見され修正されました。(IMP-4.3.3未満/IMP-4.2.2未満)

試しに、ソースコードをチェックしてみました。
もっと読む

PHP:既知のセキュリティ脆弱性 – Session Adoption

追記:より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。

PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。

セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。

セッションアダプション脆弱性を利用すると、攻撃者は長期間に渡って他人のIDを使う成りすましが可能になる場合があります。IDを盗みたい犯罪者には利用価値の高い脆弱性です。

この脆弱性は、10年以上前から問題視されている国別TLD(ccTLD)の属性ドメイン(国別Top Level Domain, co.jp, or.jpなどのドメイン)にも下位ドメインからクッキーが設定でき、サブドメインのクッキー設定が無視される(送信順序、優先順位がいい加減)、というとんでも無いクッキーの仕様と組み合わせると、大量の他人のユーザセッションIDを取得(設定)し、成りすます事ができます。

セッションアダプション問題は全てのPHP、PHP 4.4.9/PHP 5.2.8/PHP 5.3/PHP 6.0に共通する脆弱性です。

最近、影響範囲はかなり狭くなりましたが、まだまだ注意が必要な脆弱性であり、根本的な解決にはパッチと適切なセキュリティ対策が必要です。

もっと読む

文字エンコーディングとセキュリティ(3)

gihyo.jpのブログ型の連載である「なぜPHPアプリにセキュリティホールが多いのか?」の

http://gihyo.jp/dev/serial/01/php-security/0021

で、PHPのサンプルコードを書いているのに「JavaScriptなど」とJavaScript用のサンプルコードであるかの様に書いていました。

JavaScript -> PHPに書き換えても良いのですが、両方JavaScriptのサンプルを掲載するように編集者の方に依頼しておきました。

ご指摘頂いた方、ありがとうございます。

PHP4.4.9のセキュリティ状態

PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。

PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。

もっと読む

ZendFrameworkで作る『イマドキ』のWebアプリケーション

技術評論社さんのPHPセキュリティ関連のブログ、なぜPHPアプリにセキュリティホールが多いのか?も執筆させて頂いていますが、新しくZendFrameworkで作る『イマドキ』のWebアプリケーションも執筆させていただくことにになりました。

今回の連載では私のブログでフィードバックや質問をお聞きしようと考えています。一般的な質問はMLなどでお聞き頂けるようお願いしますが、動作しない、動作がおかしい、説明がわかりづらい、これを説明してほしい、など記事に関連するご意見やご質問をお待ちしています。

Wikiにサポート用のページも用意しました。Wikiにはまとめや必要なリソースへのリンクなどを掲載します。
http://wiki.ohgaki.net/index.php?ZendFramework-Web-Application

今回、連載を開始するにあたりLinux, Mac, Windowsでできる限り同じ環境が作れるように工夫してみました。

当初はXAMPPをベースとした環境にしようと思ったのですが、64bit版が用意されていないのは現在のPC環境を考えると好ましくありません。そこで、PostgreSQLのバイナリ配布版であるPostgreSQL One-Click Installerを利用した環境を利用することにしました。PostgreSQL One-Click Installerを利用すると、Linux, Mac, Windowsでほぼ同じApache/PHP/PostgreSQLの動作環境を構築できます。

CentOS5を利用している環境が公開可能であるため、VMwareイメージも公開しています。VMwareイメージには以下のパッケージが含まれ、必要な設定が行われています。

– CentOS 5.2
– Apache 2.2
– PHP 5.2
– ZendFramework 1.7
– PostgreSQL 8.3
– Eclipse 3.4
– Mercurial 1.1

ダウンロード先など、詳しい情報はWikiをご覧下さい。

エンティティ化された文字による任意コード実行

小泉さんが発見され昨年末に公開された脆弱性です。詳しくはアドバイザリをご覧いただくとして概要を解説します。

CVE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-5557

アドバイザリ
[Full-disclosure] CVE-2008-5557 – PHP mbstring buffer overflow vulnerability

かなり特殊な設定といえる状況で問題となるようですが、ちょうどgihyo.jpで文字エンコーディングに関連したセキュリティ問題を解説しているので紹介します。

http://gihyo.jp/dev/serial/01/php-security/0019
http://gihyo.jp/dev/serial/01/php-security/0020

もっと読む

PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理

これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。

PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。

この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。
もっと読む

Pythonの脆弱性

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.

BootcampのWindows VistaがParallelsで起動するとライセンス認証エラーでログインできない

先月のWindows Update以降、BootcampからはVistaは正常に起動し使えるのですが、Parallelsから起動するとWindowsライセンス認証のエラーが発生しログインできない状態になってしまいました。ちょっと探してみただけでは同じような問題で困っている方の情報は見つかりませんでした。

この状態はかなり使い勝手が悪いので、なんとかしたかったのですが時間の都合で放置していました。ようやく直す事ができました。

Windows側で何かしなければならないと思っていたのですが、Parallelsをアンインストールして再度インストール、ライセンス認証を求められるので認証を行うと使えるようになりました。

環境
OSX 10.5.3
Parallels Desktop build 5600
Windows Vista Business SP1

同じような問題でお困りの方、一度Parallelsをアンインストールしてみましょう。

Python 2.5.3にリモートコード実行の可能性がある脆弱性

最近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.6

Access 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.

関連:
Python 2.5.2以下に任意コード実行の脆弱性
GoogleのPython採用と脆弱性情報の関係

.Net用OCaml – F#の入門書 – Expert F#

OCamlはプログラミングコンテストで優勝するチームや開発者御用達の言語であることは以前から知っていましたが、個人的に利用しようと思ったありませんでした。しかし、最近関数型言語の人気が非常に高まってきています。関数型言語の簡潔なコードや副作用の少ないコードの生産性が認められてきたからだと思います。

OCamlを勉強しようかと思いましたが、AmazonでちょうどF#の本(英語版)が昨年末出版されている事を見つけて購入しました。
もっと読む

JPUG北海道 RUBY札幌 合同セミナーの資料

2月16日に札幌で行われたJPUG北海道 RUBY札幌 合同セミナーの資料です。

クリックしてPostgreSQL-Performance.pdfにアクセス

セミナーの際には風邪の為、声がでず、非常に聞き辛かったと思います。聞きにお越しいただいた方には申し訳ないです。

fsync=falseなのでかなり速い事は理解していただけたと思います。(かなりのスピートダウンですがfsync=trueでも速いです)セッションをデータベースで管理した場合などにfsync=falseで運用しても問題ないでしょう。しかし、絶対にデータベース上のデータの不整合は困る場合にはfsync=trueに設定しなければなりません。

とは言ってもfsync=falseの速さは捨てがたいと言う方はUPSを利用すると良いでしょう。UPSを付ければリスクはかなり低減できるので、リスクとメリットのトレードオフで選択すれば良いと思います。

UPSを使っても防げないデータの不整合

  • カーネルがクラッシュした場合
  • HDDのケーブルが抜けたなど、物理的問題の場合
  • 電源が壊れた場合(これも物理的な問題ですが、2重化すればかなりリスク低減可能)
  • HDDの冗長化を行っていない場合(RAID組まずにデータ保護の為に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だとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。

ホワイトリストはどう作る?

まずホワイトリストの基本中の基本は”デフォルトで全て拒否するであることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません

例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1

私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力/出力の両方にホワイトリスティング対策をお勧めしています。3

もっと読む

正しいメールアドレスのチェック方法

正しいメールアドレスのチェック方法がちょっとした話題になっているようです。Web屋のネタ帳でも取り上げられていますが、メールアドレスのチェック方法自体は解説していません。ついでなので書いておきます。

「本当に正しいメールアドレスかチェック」するには実際にメールを送信して、送信されたユーザしか知り得ない情報をユーザが知っている事により確認しなければなりません。これはWeb屋のネタ帳で解説されている通りです。

もっと読む

簡単なベンチマーク

最近のPostgreSQL, MySQL, SQLiteのパフォーマンスはどうかな?と言うことで非常に簡単なベンチマークをしてみました。

デフォルト状態のデータベースに郵便番号データ(12万件とちょっと)をINSERTしてみました。フラグを除く全てのフィールドをテキスト型として定義し、全てのフィールドを挿入しました。旧番号と現行番号にインデックスを付けています。スクリプトはPHPで記述し、DBが動作しているPC上からPHP 5.2.4で実行しました。1レコードが分割されている場合などは無視して挿入しているので12万2000レコードになりました。

PC

CPU: PentiumD 2.8GHz
Memory: 3GB
HDD: PATA

DBMS

MySQL: 5.0.45
PostgreSQL: 8.2.4
SQLite: 3.4.0 (PDO)

実行結果(12万行INSERTの実行時間)

InnoDb: 130.70663690567
MyISAM: 131.24672317505
Postgres: 159.47350597382
SQLite: 676.43534302711

MySQLもPostgreSQLもチューニングは一切無しで実行しています。

非同期クエリを利用するとPostgreSQLもInnoDb, MyISAMと同じくらいの速度になりました。

どのDBもペンチマーク中はディスク待ちの状態でCPU時間はあまり使っていませんでした。

MySQLとPostgresは概ね予想通りの結果でしたが、SQLiteが異常に遅いのでPDOを使わないで計測してみましたがあまり変わりませんでした。トランザクションかな?と思いBEGIN, COMMITを付けてみましたが変わりませんでした。

INSERTしたレコードをランダムにSELECTしてみました。番号はmt_rand関数で生成したのでほとんどがINDEXにヒットしないので、インデックスを利用した検索の最悪のケースのテストになります。単純にテーブルから検索をするだけです。永続的接続を利用しています。

Webサーバ:Apache 2.2.6
クライアント: ab -n 10000 -c 10 (別PCから実行。Athlon64 3500+/3GBメモリ)

パフォーマンス:リクエスト/秒

Postgres: 947.58
SQLite: 1096.00
MySQL(MyISAM): 1190.35
MySQL(InnoDb): 1245.85

概ね予想通りの結果ですが、SQLiteが思っていたより遅いです。PostgreSQLは接続のネゴシエーション処理が重いので非永続的接続を利用するとかなりパフォーマンスが落ちます。システム全体でDBへの接続数を上手に制御できていない場合はpgpoolを利用するとパフォーマンス(システム全体のスループット)が改善することがこの事からも分かります。

「Postgresでこんな数字でないよ」という方、pg_pconnectで試してみましょう。コネクションプーリングが無いと話になりません。