DBMSの機能比較

Firefoxに未パッチの脆弱性

ドメインに0xADが含まれているとヒープオーバーフローが発生するそうです。
個人的にはIDNは不必要と考えていますが、IDN関係のコードかな? IDN以外でこんなバグがあるとは思えない。

IDNはレジストラだけが儲かる仕組だと思います。一般ユーザやサイト運営に関わる人には全く利益無し、とまでは言いませんが不利益の方が利益を遥かに上回ると思います。IDNサポートは駆逐されて欲しい機能の一つですね。

追記:
http://security-protocols.com/modules.php?name=News&file=article&sid=2910

Technical Details:
The problem seems to be when a hostname which has all dashes causes the NormalizeIDN
call in nsStandardURL::BuildNormalizedSpec to return true, but is sets encHost to an
empty string. Meaning, Firefox appends 0 to approxLen and then appends the long
string of dashes to the buffer instead. The following HTML code below will reproduce
this issue:

A HREF=https:———————————————

Simple, huh? ;-]

パッチはここから
https://bugzilla.mozilla.org/show_bug.cgi?id=307259
というかこれに書いたときにはパッチは有りましたね。広くリリースされてはいませんが。IDNは手動で無効に設定しておいても良いかも。

network.enableIDN=false

回避策として公開されていますね。
https://addons.mozilla.org/messages/307259.html

XPIでインストールしなくても about:config をアドレスバーに入力して network.enableIDN=false に設定すればOKです。

gooの辞書検索がPHPに

少し前の事になりますがgoo.ne.jpの辞書サービスがCGIバイナリ(?)からPHPに変更されました。

具体的にはURLが

http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi

から

http://dictionary.goo.ne.jp/search.php

に変更されました。たいした事ではないですが気が付いたので。

PostgreSQL 8.1のパフォーマンス

PostgreSQLのパフォーマンスはpostgresql.confに大きく影響されるので、速くなったかどうか判りづらい場合も多いです。しかし、8.1では確実に速くなっているようです。現在8.1はbeta1ですが少しだけ比較してみました。

詳しくはWikiのページを見ていただくとして以下の様にpgbenchで計測すると

./pgbench -v -h 192.168.100.204 -U yohgaki -c 20 -t 200

PostgreSQL 8.0.3

tps = 4683.835265 (excluding connections establishing) (Select only)
tps = 1032.798585 (excluding connections establishing) (Update 省略)
tps = 423.926137 (excluding connections establishing)

PostgreSQL 8.1beta1

tps = 5985.801678 (excluding connections establishing) (Select only)
tps = 1428.605103 (excluding connections establishing)(Update省略)
tps = 533.005286 (excluding connections establishing)

という感じの結果になりました。
postgresql.confの設定は多少チューニングした物を使っています。postgresql.confもWikiのページに添付してあります。

pthread版pgbenchの拡張

実はpthread版pgbenchの作成には別の目的もあります。オリジナル版pgbenchのコードを見ると分かるのですが、非同期クエリを使用しているので送信するクエリのカスタマイズが面倒です。pthread版pgbenchの別の目的、と言うより本来の目的、はpostmasterが書き出したログから自動的にクエリを収集し、再生するベンチマークを簡単に行いたいので作る、と言う事にあります。

今の所こんな感じで実装するつもりです。

postgresql.confのログ設定が

log_line_prefix = ‘%r’
log_statement = true

で出力されたログから自動的に各クライアントのクエリを出力し設定されたスレッド数(クライアント数)でベンチマーク出来るようにする予定です。

今のコードだとログの読み取りとクエリ保存を行えるようにして、各スレッドがクエリを実行するように変更すれば良いだけです。簡単なのでそのうち変更します。

PHP 5.0.5リリース

PHP 5.0.5がリリースされました。XMLRPCのセキュリティフィックスが含まれています。

他のディストリビューションも同じとは思いますが、Momonga LinuxのXMLRPCは現行リリース(5.0.4-6m)でもセキュリティ対策済みです。

coMomongaのススメ

遅ればせながら初めてcoLinuxのMomonga版であるcoMomonga2+(今のところ非公開です。8月のコミケで販売していたそうです。私はプロジェクトメンバーなのでscpでサーバから拾ってきました。)を使ってみました。非常に便利かつ思っていたよりレスポンスも良いです。

coLinuxは初めてだったので一番最初はcoMomongaでは無くcoLinuxのインストーラから選択できるDebianをルートファイルシステムを使ってみました。このルートファイルシステムには本当に最小限のパッケージしかインストールされていないようでした。viもemacsも無い状態でした。ネットワーク経由でapt-getすれば良いのかも知れませんがviさえ無くて戸惑いました。Gentooのルートファイルシステムも選択できます。こちらはもう少し多くのパッケージがインストールされているのかも知れませんが試しませんでした。

次にcoMomongaのISOイメージを試す事にしました。coMomongaのISOにはcoLinuxとXming(Xディスクプレイサーバ)インストール方法や設定に必要な全てのファイルが含まれています。WindowsのCDドライブにCDを挿入すると自動的にインストールマニュアルが表示されます。Xmingのバイナリも付いていてX Window環境も直ぐに構築できます。このマニュアル通りに設定するだけで簡単にセットアップできました。

# ただし、このノートPCがWindowServerのドメインメンバー
# であった為、ICS(インターネット接続の共有)がグループ
# ポリシーで無効に設定されていたのでネットワークが使え
# ませんでした。ドメインからワークグループに変えてネット
#ワークを使えるようにしました。

ブートが非常に速いのは助かります。同じノートPCのパーティションにインストールしたMomongaLinuxを起動するより随分速いです。Xも普通にストレスの無いパフォーマンスで動作します。コーディングなどの用途向け十分なレベルです。

私のノートPC
-PentiumM 1.3Ghz
-768MB RAM
-80GB 5200rpm HDD
-WindowsXP Pro SP2

スクリーンショット
coMomonga
(coMomongaをWindows上で実行し、coMomonga上のXクライアントに、Windowsで実行しているXmingからXDMCPでcoMomongaのXを起動している画面。正確に書くと長いですね… 説明は面倒ですがインストールは非常に簡単)

今までノートPCのWindows環境でUNIXライクな環境が必要な場合にはcygwinを、Emacsが使いたい時はMewを使っていましたが今後はcoMomongaを使う事にします。ノートPCにもMomongaLinuxをインストールしていますが、諸事情によりWindowsがメインOSになっています。雑誌などの評価で非常に便利とは思っていたのですが食わず嫌い(嫌いではなかったですが)で今まで損をしていました。

このcoMomonga2+ですが、Momonga Projectから今度のOSCで売りに出るそうです。是非購入(寄付?)しましょう :)

オンライン取引を安全に実行する方法

先日のPHP関西セミナーで、管理者権限で動作しているスパイウェアなどがインストールされたPC上で、Web上のログインやフォーム送信の安全性を保障する方法は(説明した方法では)無いと言いましたがこれは変わりがありません。時間があまり無かったので補足しておいた方が良いと思える点を補足します。

まずパスワードですが、パスワードが盗まれても大丈夫な仕組みは昔からあります。ワンタイムパスワードと呼ばれる方法です。ログインするコンピュータでパスワード生成プログラムを実行するとパスワードの安全性が損なわれる為、通常液晶が埋め込まれたカード型のパスワード生成機等のデバイスを使います。ワンタイムパスワードを利用している場合パスワードが盗まれる事はありません。他のコンピュータからログインされてアカウントを不正に利用される危険性はほとんど無くなります。

ワンタイムパスワードを使えば安全か考えるとまだ安全とは言えません。正規のユーザがコンピュータを利用中にスパイウェア等がデータを書き換えてしまう危険性が排除されている事をWebサイト側では保障できません。現実的な脅威かは別として、例えば銀行のフォーム送信等でデジタル署名などを行っても安全性を保障する事はできません。管理者権限で動作しているスパイウェアがインストールされているコンピュータだけでトランザクションを行うと、スパイウェアが任意の時点でデータのすり替えを行い、本来送信しようとしている送信先とは別の送信先にお金を送信する、等の危険性はなくなりません。そもそも署名に必要な秘密鍵がコンピュータにインストールされている場合、スパイウェアは秘密鍵を盗む事が可能です。USBデバイス等で秘密鍵が絶対に読み取られないようなデバイスの場合、秘密鍵が盗まれる事はないかもしれませんが、液晶などの表示機能が無いと署名した取引情報が意図しているものかユーザは判別できません。

信頼できないデバイス、スパイウェアがインストールされたPC等、だけを使用して信頼できるオンライン取引を行う事は技術的には不可能なはずです、安全に使えない、と言うのでは困るのでより安全に取引を行う方法を考えて見ます。安全に取引を行うにはトランザクションを行うデバイス、通信が信用できる必要があります。今の環境であれば、携帯電話に取引情報を送信して、携帯電話上で取引情報を表示・確認してから直接送信するか、署名してからPCで送信する方法が考えられます。携帯電話は信頼できる、と言う前提が必要です。別に携帯電話でなくても信頼できるデバイスで取引情報を確認し、取引情報改ざんを防ぐ署名ができる仕組みであれば何でも良いです。USBで接続された表示機能付き署名デバイス等でもOKです。ワンタイムパスワードの仕組みを知っている方なら思い浮かぶアイデアと思います。

スパイウェアがオンライン取引の最中に取引データを改ざんし、表示された取引情報とは別の取引を行うリスクには対処できませんが、別のPCからの不正な取引を十分なほど防ぐには暗号表を使うのが良いと思います。セミナーでは暗号表は繰り返し暗号表を利用した取引を見ることによって解読できるので安全ではないと言いました。確かに暗号表の解読は、暗号表が固定的であれば、難しくありません。「固定的であれば」と条件が付くので「動的であれば」安全になります。ここでも信頼できるデバイスが必要になりますが、携帯電話メールが信頼できるとすると取引の度に新しい暗号表を携帯電話にメールで送信すればかなり安全といえます。頻繁に携帯電話に暗号表を送信する方法は現実的かつ実用的と思います。既に何処かで利用されているかな?

PHP関西セミナーの資料

9月3日にPHP関西のセミナー講師をさせていただきました。プレゼンテーションファイル作成の時間が足りなかった為、予定していたより内容が薄い資料になってしまいました。話を聞いて頂いた方以外にはよく分からないかも知れませんが、最近のオープンソースのPHPアプリケーション脆弱性レポートからどのように脆弱性が作られたか考察しました。

セミナーを聞いて頂いた方向けに、その時のプレゼンファイル(PowerPoint形式)を公開します。

pgbenchのpthread版

(やはりバグを発見したので修正)

JPUG広報Blogに「pgbenchのpthread版が欲しい」と書いていましたが、先週末にPHP関西のセミナー講師を引き受けていたのでその移動時間中にテキトーに作ってみました。テキトーに作ったので勘違いしてバグを入れていました。今度はたぶん正しい結果になっていると思います。

サーバ環境
Athlon64 3200/3GB Memory/SATA2 HDD/Momonga Linux x86_64
PostgreSQL 8.0.3(64bit)(全てのSQL文をホスト/ポート付きで記録。他はほぼデフォルト。)

クライアント環境
AthlonXP 2500+/2GB Memory

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 10 -t 100
starting vacuum…end.
starting full vacuum…end.
Warming up 15 seconds…
Start benchmarking…
End benchmarking….. (4.96586 seconds)
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 100
total number of transactions processed: 1000
tps = 235.404176 (excluding connections establishing)

real 0m25.739s
user 0m0.214s
sys 0m0.313s
[yohgaki@dev pgbench]$

こんな感じです。

何だか遅くなってしまたのでコードをもう少し効率化してみました。
今度はオリジナル版よりは速くなりました。

pthread版pgbench

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
Warming up 0 seconds…
Start benchmarking…
End benchmarking….. (1.16363 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 429.689481 (excluding connections establishing)

real 0m2.655s
user 0m0.047s
sys 0m0.088s

オリジナル版

[yohgaki@dev pgbench]$ time pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10
starting vacuum…end.
starting full vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
number of transactions actually processed: 500/500
tps = 337.674248 (including connections establishing)
tps = 379.093451 (excluding connections establishing)

real 0m1.615s
user 0m0.043s
sys 0m0.210s

と、多少スレッド版の方が速いです。今度は繰り返し実行してみてもスレッド版の方が速い傾向は変わりませんでした(汗

ベンチマークを開始する前にウォーミングアップの時間を設定したかった事、クエリ実行間隔をランダムに設定したかった事もpthread版が欲しかった他の理由でした。そこで

-w ウォームアップ時間(秒)
-r ランダム遅延(マイクロ秒)

も設定できるようにしました。よくあることですがサーバに負荷をかけた直後は良い性能がでるためウォームアップ時間は設定できた方が便利です。

ウォームアップ時間を5秒に設定した場合

[yohgaki@dev pgbench]$ time ./pgbench -v -h 192.168.100.204 -U yohgaki -c 50 -t 10 -w 5
starting vacuum…end.
starting full vacuum…end.
Warming up 5 seconds…
Start benchmarking…
End benchmarking….. (1.48874 seconds)
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 10
total number of transactions processed: 500
tps = 335.854481 (excluding connections establishing)

real 0m6.671s
user 0m0.124s
sys 0m0.260s

とこの様な感じです。オリジナル版にウォームアップ時間オプションを追加して欲しいな、と書いておいたら石井さんが追加してくれるはず :)

ソースは
http://www.ohgaki.net/wiki/index.php?PostgreSQL%2Fppgbench
からダウンロードできます。変更するかもしれないので日付を入れておきました。日付が入っていないソースは古いソースです。もし古いソースをお持ちの場合、新しいソースを使ってください。古い物にはバグがあります。

グラフィックテキストも安全ではない

昨日に引き続き「絶対安全」と誤解されているかもしれないセキュリティ対策の話です。

CSRF(クロスサイトリクエストフォージェリ)対策、アカウント作成ボット対策としてグラフィック上に書かれたテキストを読み取らせるサイトが多くあります。普通のOCRで読み取れるような簡単なグラフィックテキストでもコメントスパムなどのボット対策としては(今のところ)十分有効ですが、認証用のグラフィックテキストを生成するプログラムにはCAPTCHAが有名です。

単純なグラフィックテキストだとOCRで機械的に読み取られてしまう事は明白です。昨日、IRCで話をしていてOCR技術はかなり向上してきており単純な物は100%認識できてしまうようなってしまっている事を知りました。この分野はあまり気にかけていなかったので昨日PWNTHAと言うCAPTCHAなどで作成されたグラフィックテキストを読み取るツールを知りました。リンク先を見ると分かりますが、今では結構OCRで読み取りが難しいと思われるようなグラフィックでもかなりの高確率で読み取れるようです。

仕掛けは多少大掛かりになりますが、グラフィックテキスト情報を人間に読ませる攻撃方法も考案されています。例えば、こんな感じです。

前準備:音楽、映画、アダルトコンテンツなど多くのネットユーザが参照したくなるWebサイト(以下、「解読サイト」)を用意する。

1. プログラムで攻撃対象のWebサイトのグラフィックテキスト付きページを開きページを保存する。
2. グラフィックテキストを解読サイトのコンテンツダウンロードの認証キーとしてユーザに解読させる。
3. ユーザが解読してくれたテキストを攻撃対象のWebサイトの認証キーとして利用する。

このような手法を用いられた場合、グラフィック上に記述されたテキストや写真情報を使った防御策も完全とは言えません。

セキュアキーボードは安全ではない

SSLが流行しはじめた頃、「このサイトはSSLを使っているので安全です」とうたっていたサイト多く見かけました。これが大嘘であった事は周知の事実となっていると思います。

最近セキュリティ対策として「セキュアキーボード」と呼ばれている「ソフトウェアキーボード」が流行しつつあります。特に金融機関を中心に急速に浸透してきています。ソフトウェアキーボードとはWeb画面上に口座番号・暗証番号などを入力するボタンを表示してID情報を入力する仕組みです。残念ながら「セキュアキーボードを使っているので安全です」とうたっているサイトも大嘘をついている事になります。

セキュリティ関連MLではどのようにセキュアキーボード(ソフトウェアキーボード)を破るか話題になっていました。この対策は簡単に敗れる事が知られています。スクリーンラッパーという名称になる(?)ようですが、クリックした瞬間の画面イメージを攻撃者に送信する、という単純な手口でセキュアキーボードは破られてしまいます。すこし考えれば直ぐに破り方くらい分かると思うのですが何故か「セキュアキーボード」(安全なキーボード)と言う名称が付いているサイトが多くあります。

スクリーンラッパー付きのスパイウェアがいつ頃出回り始めるかな、と思っていたらもう出回っているようです。セキュアキーボードは”古い”キーロガーだけを使うスパイウェアには有効ですが、新しいスパイウェアには無力です。「セキュア」キーボードという名称は利用者に「安全である」と錯覚させる呼び名と思います。直ぐにセキュアキーボードや安全と思わせるような名称は使わないようにした方が良いと思います。

やはり基本に忠実にスパイウェアをインストールされないようにするしか本当に有効な方法は無いです。しかし、クライアントにスパイウェアをインストールされていない事をWebサイト側から確認することは不可能です。サービスを提供しているサイトは非常に悩ましいですね。

追記:ちなみにスパイウェアを植えつけるWebサイトと認知されているサイトは900ちょっとだそうです。私が見た統計情報にはjpドメインのサーバはありませんでしたが、用心は必要でしょう。