年: 2006年

やはり、まだある単純リモートスクリプト実行バグ.. どころか

少し前に「やはり、まだある単純リモートスクリプト実行バグ..」と書いていますが、まだあるどころか「まだまだ出てくる」という感じですです。

まず、phpDocumentator、これのテスト用スクリプトにはリモートファイルを実行できるバグがあります。それから、onBoardこれも全く同じくリモートコードを実行できるバグがあります。

onBoardはよく知りませんが、phpDocumentatorは広く使われていると思います。クラックされる可能性が高いのでテスト用コードは削除しておきましょう。(と言うより普通はphpDocumentatorを公開する必要がないので、非公開にしましょう。これ以外にテスト用スクリプトにはリモートスクリプト実行以外にもXSS問題も指摘されています。)

前のブログで当然直っていると思っていたphp://input問題が修正されていない旨のコメントを頂きました。驚いたことに本当に修正されていません。ですからallow_url_fopen=offすればリモートコードの実行は防げますが、リモートからのコードインジェクションは防げません。

php://inputは生のPOSTデータ扱うときに使えるから、などと言っている場合ではないのですが… php://inputを導入した事により今まで無かった脆弱性を作っているは明らかなのですけどね… 新しい脆弱性が仕様です(しかも簡単に直せる)と言うのは受け入れがたいですね。

ログオン時にインストールできるWMF Hotfix

アンオフィシャルなWMF Hotfixがありますが、ダイアログ、メッセージなどが一切出ずにインストールできるHotfixもあるそうです。ログオンスクリプトでインストールする事も可能になります。

私はこのHotfixをインストールしていません。とりあえずMSサイトに記載されていたdllの登録を解除しただけです。
http://blog.ohgaki.net/index.php/yohgaki/2005/12/30/wmfe_afpa_sa_lamfa_a_a_ra

アンオフィシャルなHotfixは、一部で全てのケースに対応できないなどとも言われているようです。
ところでWindows 3.0にもこの脆弱性があるそうです。古い問題だったのですね。

関連エントリ:
http://blog.ohgaki.net/index.php/yohgaki/2006/01/02/spama_ia_fa_la_sa_rwmfa_ra

RFID防止財布の作り方

RFIDでトラッキングされる事が気になる方は是非どうぞ。
# これなら缶にカードを入れたほうがまし?!

追記: ブログ移行でリンク先が消えたので補足します。RFIDは強い規定以上の強い電磁波を使えば読み取り距離が数ミリのRFIDでも、10メートル以上離れた場所から読み取りが可能だったりします。RFID情報を読み取ることにより誰が入店したのか?などの情報をどんどん集めることが可能になります。RFID情報と所有者の個人情報を結びつけられると詳細な利用情報を得られます。

こういったRFIDカード情報の収集を防ぐにはRFIDカードに対する余計な電磁波を遮断する必要があります。元々付けていたリンク先にはRFID情報の不正読み取りを防ぐ財布の作り方が記載されていたと思います。

エネミー・オブ・アメリカ」でジーンハックマンがやっていたように、アルミで出来ているポテトチップスの袋でも代用可能ですが、現在だとAmazonなどで「RFID 保護 財布」などをキーワードに検索すると、色々な製品を売っています。

激安UPS

随分前から販売しているようですが初めて見ました。

大出力容量(VA/W) 2000/1200 21,800円(税込)
大出力容量(VA/W) 1400/840  15,800円(税込)
大出力容量(VA/W) 500/300   6,980円(税込)

有名(?)な激安楽器販売店だそうです。
あまりに安いので調べてみると次のようなページがありました。

http://sheltie.ddo.jp/~kojima/ups/

テストした当時の製品へのURLは変更になっているようです。
2004年2月のデータのようなので今の出力はどうなのか気になりますね。

http://72.14.203.104/search?q=cache:mH2cJuFFQhAJ:lower.seesaa.net/category/415216.html+%22classic+pro%22+UPS2000&hl=ja

を見るとさすが激安製品専門ブログのオーナ、UPS500を使っている(いた?)そうです。

パソコン用として、私はこの一年、CLASSIC PRO UPS500というUPSを使っております。300Wの最大出力容量ですが6,980円と新品UPSとしてはかなり安く、バッテリーも3,000円で販売されています。値段が安く外観がしょぼいので最初は不安だったのですが、この一年は特に問題になるようなことはありませんでした。

精神衛生上できればUPSを付けたいけど付けていないような機器には買いたくなるような値段ですが、付けたくないような波形です。上位機種の2000VA、1400VAの製品は外観からして違うのでどなたかテストしていないかな?

入門書の書き方

書いてみるとプログラミング入門書はどう書くか結構悩みます。自分の場合、割り切って多少本当にはじめての人に分かり辛くても出来るだけ本当に必要と思われる項目を十分に説明するように配慮しました。イメージ通りの仕上がりとは言えませんが、それなりの出来と思います。amazon.co.jpを見れば分かりますが、予想通り評価は分かれましたが :)

セキュリティ系の入門書もどう書くか結構悩みます。今回も結構割り切って書いています。また今回も評価は分かれるかと思います。今回の予想、前の本と反対の評価になりそうな気がします。どんな本でも同じとは思いますが、どの読者層に対して書くか、決めるのは難しいですね。

サニタイズと言わない

珍しくサニタイズという考え方自体が間違っているという意見を見ました。

私もサニタイズと言う考え方はNagative Security(禁止事項を定義する考え方)からの発想なので、Positive Security(許可する事項を定義する考え方)でプログラムを作るべきと考えていますし、あちらこちらで言っています。この高木さんのブログのでは、デフォルトのコーディングスタイルではサニタイズを考えなくても良いようにする事、と意見されているだと思います。いちいち意識しなくても良いようなスタイルの方が間違いが少なくなるので良いことだと思います。

# Googleで調べるとNagative/Positive Securityの方がよく利用され
# ていることが分かりますが、個人的にはNagative/Positive Security
# と言っても分かりづらい気がします。Reactive/Proactive Security
# と (受動的/能動的セキュリティ)言った方が分かりやすい気がする
# のでこっちを使っています。

Reactive/Proactiveなセキュリティと考えるとコーディングスタイルの変更によるセキュリティ確保はProactiveなセキュリティ対策なので実践していきたいものです。

ところで、常々感じているのは多くのプログラムで「サニタイズ」という概念のおかげで入力値の確認が疎かになっているのではないでしょうか?セキュアなコードでは入力値が

-期待する形式であるか?
-期待する範囲であるか?

確認することが重要です。期待する形式である、ということは文字の種類等だけではなく、selectやradioフィールドの値であるならプログラムで設定した入力値であるか照合する事も含めてチェックします。selectやradioでなくてもプログラムが設定する値であるなら必ずプログラムkが設定している値であるかも確認自由形式の文字列であれば文字数やエンコーディング、数値であれば最小、最大値の範囲内であるかチェックします。もし、おかしなデータがあれば適切はログを取り、適切なエラー画面を表示します。ライブラリ化していれば別に難しい事でも手間がかかる事ではありません。手製のHTMLフォームクラスではJavaScriptとサーバサイドの両方で自動的にチェックするようになっています。
# JavaScriptでチェックしているのはフォームPOST後に
# 「形式が違います」等とエラーになるのが自分が嫌い
# だからです。

多くのプログラムで「サニタイズしようと考えた結果、セキュリティホールを作ってしまった」のは今までのセキュリティホールを見てみれば明らかです。サニタイズには語源のSanitize -(真実を曲げたりして)無害にする、と定義されている通り間違った使用例が多く見受けられます。よくあるサニタイズコードの悪い所は「ダメな部分を取り除く」だけのコードになっている事が多い点です。これでは攻撃されていても攻撃があった事さえ分かりません。攻撃者は不正な入力値を含むデータを送信してもエラーも無く処理が終了する事で、システムはReactive Securityを使用している事が分かります。ReactiveなセキュリティモデルのシステムはProactiveなセキュリティモデルより脆弱である事が多く(現実的にはReactiveセキュリティモデルのみでセキュリティを確保することは無理)、攻撃者のターゲットとして選ばれる確立も高くなります。

念のために、Reactiveなセキュリティモデルが役立たずか、という事ではありません。Reactiveなセキュリティモデルも非常に有用です。その典型的な例はIPSです。本来セキュリティホールがある場合、IPSで対処するのではなくセキュリティホール自体を修正するべきです。しかし、コードがない製品の脆弱性でベンダーがなかなか対応してくれない場合、アプリケーションの修正とテストに多くに時間が必要な場合も多くあります。こういった場合、IPSが無いとセキュリティを確保できません。最終的にはIPSでチェックしなくても良いようにシステムを変更するべきですがIPSは「つなぎ」に欠かせません。

Sanitizeという概念が混乱(?)を起こすのは入力・出力両方に同じ用語が使われていることも原因の一つではないかと考えています。「不正な入力がないようSanitizeし、….」とか「不正な文字列が無いようSanitizeを行ってからHTMLを出力し、…..」等と入力確認と適切な出力形式への変換を同じ用語で説明しています。同じ用語で2つ以上の事柄を意味すると混乱の元です。この意味でもサニタイズとは言わないようにと言う意見には賛成です。

Javaの場合は適切なタグを利用すれば自動的にHTML出力に適した形式で出力してくれますがPHPにはシステムが提供する関数にはそのような関数がありません。つい最近、webappsec MLでやりとりをしている中でOWASP Guideを書いている人(?)のメールにも書いてあったのですが「どうせPHP6はUTF-8対応で互換性の多くを失うのだから

-eche, print, printf: 自動的にHTML用に出力
-echo_raw, print_raw, printf_raw: ダイレクトに出力

のように変えた方が良い」とありました。最初は「どうかな」と思いましたがこれくらいの変更をしないと安全でないコードを駆逐することは難しいかも知れません。この変更を行えばXSS脆弱性を持つPHPコードが激減することは確かだと思います。

SpamメールでのWMF攻撃

WMFの脆弱性を利用した攻撃は新しく再利用しやすい攻撃方法が公開されたり大問題ですね。

http://sunbeltblog.blogspot.com/2005/12/new-wmf-exploit-confirmed-in-spam.html

このリンク先の例はメールに添付されたJPEGファイルからWalwareをインストールする仕組みになっているので、システム管理者は年末年始休暇明けからいきなりMalware対策に大忙しかも…

いろいろなところからリンクされていますが、タイトルのリンク先にもアンオフィシャルなパッチのURLが記載されています。SANSのブログでも「普通はアンオフィシャルなパッチなんて適用しないけど、これは適用した方がよい」という趣旨のエントリもありました。さて、どうする。