月: 2006年4月

Firefox, Thunderbird, SeaMonkyは直ぐにアップグレードが必要

Thunderbirdのアップグレードが出たのでUS-CERTからアドバイザリが出てました。

Firefox: 1.5.0.2
Thunderbird: 1.5.0.2
SeaMonkey: 1.0.1

以外はリモートコード実行の脆弱性があります。重要なのは前にここにも書きましたがMozilla SuiteユーザはSeaMonkeyに移行しなければならないことです。

ついでにFirefoxしか普段使っていない方でIEにFlashをインストールしている方、IEのFlashを削除するかIEのFlashも最新にしなければなりません。
(Mozillaのどこかに書いてあるはず。先月のことだったかな?)

【追記】
Flash Player の更新に関する注意喚起
http://www.mozilla-japan.org/kb/solution/2092

「プロフィールが未設定となっております。」 Yahoo!を語るフィッシング?

備考:かなり古いブログですが公開し忘れしていた分です。

次のようなメールが来ました。一瞬、Yahoo!のメールかと思いました。

From: (profile_page_mail)@yahoo.com <profile_page_mail@yahoo.com>
To: (yohgaki)@ohgaki.net <yohgaki@ohgaki.net>
Subject: プロフィールが未設定となっております。

プロフィールが未設定となっておりますので、プロフィールを作成下さいませ。
すべてが無料となっておりますので、ご自由にご利用出来ます。

↓のURLからプロフィール作成が簡単に行えます。
(http)://www.profile-page.com/?member&mail=yohgaki@ohgaki.net

From:はyhoo.comドメインに偽装しています。
「120% SPAMメールだな」と思いましたがリンク先を確認してみる為にクリック。
やはり出会い系サイトのプロフィールを入力するページが表示されました。一目見てYahooとは関係ないと分かるサイトです。ページには

会員の方々のプライバシーの保護、および個人情報のセキュリティには万全を期しています。
あなたが当会の会員であることをはじめ、あなたの個人情報が外部に漏れることはありませんので、ご安心ください。

と書いてありますが、Phishingメールに載っているようなサイトが信頼できるはずがありません。

このメールはFromアドレスを偽造しているのでSPAMというよりPhishingと言った方が適切と思います。送信元を偽ったメールを送っても罪にはならないかな?

Phishingの危険性はサービス開始当事にあまり認識されていなかったとは言え、Yahoo!メールはgmail.comやhotmail.comの様に一目でフリーメールだと分かるドメイン名の方が良かったですよね。

自分で作るblogツール

Zend Frameworkの参考URLの一つになっている方の著書です。

自分で作るblogツール

著者のブログ個人サイト(?)やOSS公開サイトを見て「この人すごいなぁ」と思っていたら「自分で作るblogツール」と言う本を執筆されているではないでか。早速Amazonで1-Clickしてしまいました。

Amazonのコメントには知り合いのコメントもありますね。細かい事は気にしないので、どのような内容か楽しみです。

ところでWEBXP(Web eXtream Programmingの略かな?)フレームワークのダウンロードはどこからするのだろう?

確かに驚いた…

Winnyやりてぇー! 初心者のための「ファイル共有入門」, 英知出版, 2005年12月発売

の内容すごすぎです。しかも、2005年12月出版という事は昨年末ではないですか、古い本かと思いました… システム管理者は本を買わなくても、せめてリンク先は参照するべきです。とにかく必見です。(ちなみ私は買いません。リンク先の内容だけでも十分…)

エンドユーザがこのような書籍を参考にしているかと思うと夜も眠れなくなるかも?!

国土交通省電子申請システムにも英知出版みたいな記述が

これ地方の電子申請でも同じような感じですよね…
バージョンチェックしているのも有るようだし…

# リンク先はrubyがクラッシュ(?)しているのか最初のアクセスでは空ページ
# になってしまいます。リロードすると表示されます。

Zend Frameworkの参考URL

とりあえず簡単に検索してみた結果です。リリース情報のページばほとんどで中身のあるページはまだあまり無いですね。お勧めがあったら教えてください。

英語
http://framework.zend.com/ (本家)
http://framework.zend.com/manual/en/ (英語マニュアル)
http://framework.zend.com/download/subversion (レポジトリへのアクセス)
http://www.phparch.com/zftut/index.php?p=0  (チュートリアル)

日本語
http://tdiary.ishinao.net/?year=2006;month=03;category=Zend+Framework  (使用感など。参考になる)
http://framework.zend.com/manual/ja/index.html  (日本語マニュアル)

日本語のチュートリアル的な物は無いのですね。マニュアルとソースを読めば大方使い方は分かりますからね。

http://tdiary.ishinao.net/ にも書いてありますが、private->protectedの変更は必要ですね。

http://tdiary.ishinao.net/20060329.html#p03 も参考になります。私はまだ「Zend_Frameworkを使ったことがある」とは言えないのでコメントできませんが、下記の感想はマニュアルとソースを読んだ限りでは同じ印象を持ちました。

もちろん動くものを作るだけならなんとかなるんだけど、Zend Frameworkベースのアプリケーションとして、ある程度の将来互換性も確保できるように作ろう、とか思うと現時点の完成度ではまだ無理だ*1。

一応Controller周りは結構完成度が高そうなんで、そこだけならばいけそうではある。かなりフィックスした仕様に見えるし、たとえデフォルトでの挙動が変更されたとしても、現状の拡張性の枠組みの中でカバーできるであろう柔軟性を備えている。プラグインの機構も応用範囲が広そうだ。

Viewに関しては、現状が最終仕様とはとても思えないんで、おそらくまだまだ互換性のない仕様変更があるだろう。っつーか、現在の Zend_Viewを使うくらいだったら、もっとこなれた他のテンプレートエンジン(Smartyとか)を使った方が、現時点ではずっとましだろう。

Zend_Logは、ログの保存がstaticメソッドに集約されたという設計はいいんだけど、デフォルトでCompositeじゃないのが使いにくい。自前のComposite Adapterとかを使ってカバーするという手もあるけど、その辺には仕様変更もありそうだし、現時点ではまだPEAR Logを使っておいた方がましかもしれない。

Zend_Db周りは非常にビミョー。Zend_Db_Adapterはあれで十分なんで、そのままいけるかなーと思いつつも、O/Rマッパー系は現状では実用レベルじゃないよなー。1テーブル単位のselectしかサポートしないO/Rマッパーで完結できるような設計なんて現実的じゃないし、ちょっとでもjoinしたければとたんにO/Rマッパーはつかえなくなっちゃうし。

拡張性と柔軟性重視なので無くても当たり前なのかもしれませんが、コード生成もしてくれたらうれしいのですけどね。

FlashなどをIE仕様変更に対応させる

それにしても、世界中のユーザーとWeb制作者に多くの苦痛を強いるだけのこの裁判の成り行きには、疑問を感じざるを得ません。

同感…
500億くらい、もっとでしたっけ?Eolasの請求額。

日本でもあった某社のコンテクストヘルプもですが、これも特許?!と思わせる内容です。特許が技術革新に必用な仕組みであることは明らかですが「何これ!?」と思われる発明の権利が認められすぎではないでしょうか?

特にソフトウェア特許系は最悪で発明に値しないと思われる事例が多数です。結局、

誰でも思いつく技術を特許データベースで検索

無かったのでとりあえず特許として出願

特許になった

大手が技術を使っている。儲かりそうなので権利を主張してみる

の様な流れになっていると思います。

ブラウザに「オブジェクトを埋め込んで自動的に再生をする事」と「イメージファイルを埋め込んで自動的に表示する事」の違いは500億円の価値に値する発明、独占的に使用が出来る発明として認められべき特許なのでしょうか?

何れにせよ、基本的にはソフトウェア特許は認めるべきではないと思います。
ソフトウェアは著作権で守られているのですから。

PHPを5.1.3RC3相当にバージョンアップ

最近このサーバのPHPをPHP 5.1.3RC1相当バージョンアップしていたのですが、バージョンアップ前のPHP 5.0.5(+パッチ多数)と比べると明らかにApacheがクラッシュする回数が増えていました。とりあえずPHP5.1.3RC3相当にバージョンアップしました。NEWSファイルを見ると分かりますがRC1->RC3だけでもかなりの変更・修正があります。クラッシュがどの程度直っているかな…

K-Lite Mega Codec Pack

Real Playerはインストールしたくないのでインストールしていなかったのですが、そうも言っていられない状況になったので少しWindows Mediaで使えるCodecを探してみました。(Quick TimeはiTunesがインストールするので諦めてインストールしています。

K-Lite Mega Codec Pack
というCodecを集めた製品を見つけました。Codecのコレクションになっていて色々そろっています。

私にとってはこれだけCodecがサポートされていても無意味なのでRealPlayer Alternativeだけインストールしました。

inconsistent types deduced for parameter

久々にPostgreSQLの話です。プリペアードクエリのprepare文のエラーで次のようなエラーに出くわす事があります。

ERROR: inconsistent types deduced for parameter $8 DETAIL: timestamp without time zone versus text

パラーメタの番号は振り直している、と思い込んでいたのでこのエラーメッセージを見ても何故だろう状態なり、しばらく悩んでしまいました。ググってみても役に立ちそうなページが一つも無かったので書いておきます。

create table test (
t text,
i int
);

のテーブルの場合に

pg_prepare(‘testplan’, ‘select * from test where t = $1 and i = $1;’);

等とすると(pg_prepqreはPHP 5.1の関数)

ERROR: inconsistent types deduced for parameter

エラーが発生する、はずだったのですがこの例の場合はPostgreSQL 8.0.7で試してみてもエラーが発生しませんでした。自動的にキャストしてしまうのかな?調べてません。

とにかくこのエラーはプリペアードクエリの同じパラメータが互換性のコラムに利用された場合に発生するエラーです。

エラーメッセージが読んで字の如しなので有用なページが無いのでしょうね。

Google Analyticsとタイムゾーン

Google Analyticsのタイムゾーンのデフォルト設定はEST(アメリカ東部時間)のようでそのまましばらく使っていました。

さすがに使いづらいのでJSTに変更したのですが、アクセスログのデータはUTCで記録されていないのですね。時差分の時間がアクセス0として間が開いてしまいました。普通はタイムゾーンの設定を初めにすると思うのでこのような問題にあう事は無いと思いますが、使い始めの時にはタイムゾーンの設定をお忘れなく。

CSSXSS健在…

CSSを文字列として見れないようにしたMSの対策は不十分だったようですね… と言うよりリンク先の情報からすると確信犯で直していなかった(直っていなかった)ようです。

ということで、ユーザは自衛として他のブラウザを使う、サイト運営者はバグがあるブラウザに対するCSRF対策も行う必要がありますね…

Firefox/Mozilla/SeaMonkeyユーザのアップデートをお忘れなく。使えるMozillaプロジェクトの製品はFirefox 1.5.0.2、1.0.8およびSeaMonkey 1.0.1です。
http://www.mozilla-japan.org/projects/security/known-vulnerabilities.html#firefox1.5.0.2

ちなみにOperaは危険な脆弱性が有るので8.54が使えるバージョンだそうです。
http://www.itmedia.co.jp/enterprise/articles/0604/14/news069.html

2006年はIEが安全に使えた日はまだ0日!?

【追記】

他のWindows XP+IE6の最新環境で試してみました。
ダウンロードした.htmファイルを開いてJavaScriptが実行されてもクッキーは表示されませんでした。表示しなかった環境はほとんど何も触っていない状態のWindows XP+IE6環境です。クッキーを表示するのは普段使っているノートPCのWinXP+IE6最新環境です。何か原因があるはずですが今のところ動作の違いの原因は分かっていません。参考までにIE関連で何が入っているかというと

-Google Toolbar (page rank付き)
-Norton Internet Security
-Java(JRE1.5)

が入っています。これらはクッキーを表示しないPCの環境には入っていません。少なくとも手元の環境では脆弱性が再現するWinXP PC1台と再現しないWinXP PC1台がありました。

そこでVMWare5でWinXP SP2をインストールした直後の状態のクローンを作成して試してみました。Windows Updateを全て適用、全ての更新が正しく適用されている事を確認後、「ファイルを開く」でJavaScript付き.htmを開いてみたところクッキーが表示されました。クッキーにアクセスできる脆弱な状態が普通なのか?それとも普通(?)はクッキーにはアクセスできないのかどちらなのでしょうね?

他にCSSXSS脆弱性が直っていないらしいので、どちらにしろ結局IEが安全では無い日は昨年から続いていますが。

———–

IEで意図しないJavaScriptが実行される問題の話です。
この問題は4月の定例パッチの直前に明らかになったので修正できなかった問題と思われます。結果として昨年末から既知の脆弱性があるままの状態が継続しています。

IEが拡張子ではなくデータの内容によって適当(と言うより不適切)に処理してしまう事は有名ですが、この問題は拡張子を優先してしまって問題になったケースと言えると思います。.htmを拡張子に持つファイルを送信する際にContent-Dispositionにattachment指定しても、これを無視してinlineでhtmlとしてファイルを処理してしまい(?)クッキーが漏洩してしまいます。今月のMSの定期更新にはこの件に関する修正が無いようだな、と思っていましたが修正されていないようです。

Googleはこの問題の為に.htmファイルをzipに圧縮するようにしたようです。

脆弱性のデモサイトがあります。

http://xs.vc/content-disposition/

にどのような動作になるかテストでるようになっています。
まず、ここにアクセスすると

SECRET=12456767890

とサイトが設定したクッキーがJavaScriptのAlartダイアログボックスで表示されます。ページ中の添付ファイル(Content-Disposition: Attachment)の.htmはAttachmentであるのでダウンロードされ、サイトが設定したクッキーを表示できるべきではありません。しかし、パッチ適用後のIEでも添付ファイルを開くと添付ファイル中のJavaScriptが実行され

SECRET=1234567890

とJavaScriptのダイアログが開いてしまいます。(Firefoxをデフォルトのブラウザにしている方はIEをデフォルトブラウザに変更してから試してください)

つまりこの脆弱性を利用すると、.htmファイルを添付できるサイトのクッキーを盗めてしまいます。.htmファイルを添付できる仕様のサイトはGoogleの様にzipに圧縮する等の対策を行わないとクッキーを盗まれます。ユーザとしての自衛は簡単で.htmファイルは「開かず保存してから見る」と大丈夫です。

この仕様(というかバグ)はWebメールや添付ファイルをサポートする掲示板、CMS、Wiki、バグ管理システム等で影響があります。私が現時点で把握している最新版IEのセキュリティ上の問題はこれだけです。IEセキュリティのリサーチをしている訳ではないので他にも脆弱性があるのかも知れません。他にあったら是非教えてください。

とにかく、私にが知る限りでも2006年になってからIEが安全に使えた日(攻撃可能な既知の問題が無かった日)はまだ無いです… 残念…

4月のIEのパッチ

MS06-013 Cumulative Security Update for Internet Explorer (912812)

では

CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability

に対応となっているので直ると思っていて良いのでしょうか?多分今度はきちんと直っているのでしょうね。

直るとされているセキュリティホールは次の通り。

CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
CVE-2006-1245 – Multiple Event Handler Memory Corruption Vulnerability
CVE-2006-1388 – HTA Execution Vulnerability
CVE-2006-1185 – HTML Parsing Vulnerability
CVE-2006-1186 – COM Object Instantiation Memory Corruption Vulnerability
CVE-2006-1188 – HTML Tag Memory Corruption Vulnerability
CVE-2006-1189 – Double-Byte Character Parsing Memory Corruption Vulnerability
CVE-2006-1190 – Script Execution Vulnerability
CVE-2006-1191 – Cross-Domain Information Disclosure Vulnerability
CVE-2006-1192 – Address Bar Spoofing Vulnerability

出典:eEye Digital Security

かなり強力な穴ぞろいなのでユーザ全てが直ぐにパッチを当てて欲しいです。しかし今度のアップデートは「Flashが動かなくなる」という噂が先行しているのでアップデートしないユーザも多数でそうな気がします。

数がどれくらいになるか分かりませんが、
CVE-2006-1359 – DHTML Method Call Memory Corruption Vulnerability
のお陰でスパイウェアをインストールされてしまったユーザはかなりの数になると思います。

IEは今年に入ってからリモートから攻撃可能な既知のセキュリティホールが無い状態が1日も無いですが、今度のアップデートで全部直っているのかな?