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(ブラウザ)を利用する為のTips” の続きを読む

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のサイトには攻撃方法が記載されています。

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を動的に生成する場合に注意を払う」あたりだと思います。

SquirrelMailパッケージの改竄はやはり攻撃目的

前のエントリで改竄は大きなセキュリティ上の問題ではない旨説明がされている、と紹介しましたが新リリースのアナウンス部分に新しい情報が追加されていました。

http://www.squirrelmail.org/index.php

Due to the package compromise of 1.4.11, and 1.4.12, we are forced to release 1.4.13 to ensure no confusions. While initial review didn’t uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim’s server. This could grant the attacker the ability to deploy further code on the victim’s server.

リモートファイルインクルードが可能になっていたらしいです。1.4.11は9月末にリリースされたパッケージなのでかなりの期間、危険なパッケージが公開されていた可能性があります。

利用されている方はバージョンアップしておいた方がよいと思います。また影響範囲が分からないので新しいバージョンがリリースされた場合に直ぐにアップデートできるよう準備する方がよいでしょう。

SquirrelMailのサイトでは前のニュースで影響が少ないとしていた部分は、追記として危険な問題がある事を明記しておかないと勘違いするユーザも少なからず発生するような気がします…

SquirrelMailのコードが改竄される

追記: 攻撃が目的の改竄だった模様です。
http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1

—-

http://squirrelmail.org/index.php

によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。

While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package.

The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised.

攻撃用のコードは含まれていなかったようです。攻撃コードが含まれなかったのであれば、攻撃者は「パッケージを改竄してどの程度で改竄された事実が判明するかを検証する」等の目的を持っていたのだと思われます。

GNUのFTPサーバがクラックされた事例を思い出します。MD5などのシグニチャは必ずチェックするようにした方がよいのは当り前ですが、MD5やSHA1ハッシュの重要性を再認識してもらうにはよい機会かもしれません。

混乱を避けるためにSquirrelMail 1.4.13がリリースされています。
http://squirrelmail.org/download.php
新しいパッケージはGnuPGでもサインされています。

gpgでサインされた署名をチェックするには鍵を取得しなければなりません。gpg署名の確認方法を書いておきます。パッケージとそのパッケージに対応したgpg署名をダウンロードします。

[yohgaki@dev download]$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: 署名を検査できません: 公開鍵が見つかりません

鍵がないので署名が検証できません。鍵ID”F8FD1F73″で署名されているので取得します。

[yohgaki@dev download]$ gpg –keyserver pgp.nic.ad.jp –recv-key F8FD1F73
gpg: 鍵F8FD1F73をhkpからサーバーpgp.nic.ad.jpに要求
gpg: 鍵F8FD1F73: 公開鍵“Jonathan Angliss <jon @netdork.net>”を読み込みました
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、classic信用モデル
gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 次回の信用データベース検査は、2009-02-05です
gpg: 処理数の合計: 1
gpg: 読込み: 1

この公開鍵を利用してもう一度チェックすると正しい署名であることが確認できます。

$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: “Jonathan Angliss <jon @netdork.net>”からの正しい署名
gpg: 別名“Valcor <valcor @netdork.net>”
gpg: 別名“Netdork Abuse <abuse @netdork.net>”
gpg: 別名“Netdork Sales <sales @netdork.net>”
gpg: 別名“Netdork Support <support @netdork.net>”
gpg: 別名“Jonathan Angliss <jon @squirrelmail.org>”
gpg: 別名“Netdork Security <security @netdork.net>”
gpg: 別名“Jonathan Angliss <jangliss @aaxchange.com>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg: この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 676A 1701 665B E343 E393 B8D2 2B83 E814 F8FD 1F73

警告が表示されているのは先ほど取得した公開鍵にサインしていないからです。「“Jonathan Angliss <jon @netdork.net>からの正しい署名」となっているので問題ありません。気になる場合は公開鍵を署名すれば警告メッセージは表示されなくなります。

公開鍵の署名は以下のリンクが参考になります。
http://homepage.mac.com/mio_rhapsody/gnupg/GnuPG_ShellScript.html#SignKey

WordPress Charset SQL Injection Vulnerability

http://www.securiteam.com/unixfocus/6N00D0AKKM.html

に解説されている脆弱性は基本中の基本です。

Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.

addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。

本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。

追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318

(1) Big5, (2) GBK, or possibly other character set encodings that support a “\” in a multibyte character.

BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。

対策を書いておきます。

  • データベースを正しい文字エンコーディングで作成する
  • アプリケーションからデータベースやクライアント文字エンコーディングを変更する場合、データベースのAPI(pg_client_encoding, mysql_set_charsetなど)を利用する(SQL文で変更しない)
  • 文字列をデータベースクエリ用にエスケープする場合はデータベースAPIを利用する(pg_escape_string, mysql_real_escape_stringなど)

別の対策として、プリペアードクエリを利用する方法もあります。

壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。

MySQL5.0.51では不十分

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5968

によるとMySQL 5.1.23には脆弱性ありその概要は以下とされています。

MySQL 5.0系の最新版は5.0.51ですが、これには上記の脆弱性の修正が含まれているか気になったので調べてみました。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5969
これは同じ日付のMySQL 5.0.51のCVEエントリです。これにはBINLOGの脆弱性に関する記述がありませんでした。リリースノートのURLがあったので見てみましたが以下のリリースノートにの記述がありませんでした。(現時点で)

5.0.51のリリースノート
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51.html

5.0.52のリリースノート(現時点では、Enterprise版のユーザしかダウンロード出来ない?)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html

5.0.54のリリースノート(現時点ではまだダウンロード出来ない)
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-54.html

5.0には影響ない?
5.0.51で修正?
5.0.52で修正?
5.0.54で修正?

どれなのかよく分かりません。分かったのはMySQLはコミュニティ版とエンタープライズ版でセキュリティパッチリリースを差別化している事です。5.0.52にもセキュリティフィックスが記載されています。つまり最新のコミュニティ版の5.0.51では不十分です。探せばダウンロードできるのか?アカウントを取ればダウンロードできるのか?いづれにせよどれが最新で安全なのか分かりづらいです。

リポジトリへのコミットを見ていればセキュリティパッチを見分けてインストールする事も可能ですが、とても一般向けとは言い難いです。

MySQL 6.0のバージョン管理にはBitKeeperを利用しているようです。5.1、5.0はsubversionのようなので今はまだよいですが、BitKeeperも障壁の一つになりそうです。リポジトリ自体にアクセスしてみよう、と思ったのですが少しググっただけではどこへアクセスすればよいのか分かりませんでした…

追記
しばらくしてからまた新しいMySQLのCVEが出ています。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5970
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6303
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6304

新しい方は明確にかいてあるので古い方はどうなの?と思わなくてもよいようになっています。

安全性について知っておくべき事

パスワードの解読にも『PS3』が活躍
http://wiredvision.jp/news/200711/2007113023.html

PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起
http://slashdot.jp/security/07/12/02/1931233.shtml

PS3は演算処理性能が高くFoldings@HomeのClient statistics by OSをみるとPCの値に比べおよそ26倍の性能した。

「パスワードの解読にも『PS3』が活躍」の記事では100倍の性能を達成とあります。この100倍が意味するのはランダムな文字列の難しいパスワードを解読するのに100年かかっていたのが1年で済む、1000時間かかっていたのが10時間で済む、と言うことです。時間的にクラッキングが実用的ではなかった物が十分実用的になったと言えます。

「PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起」はアルゴリズムとハードウェアの向上により、数年前から予測されていた「同じMD5値を生成する事は簡単になる」状態になったことが実証された事になります。

Microsoft等のソフトウェア会社大手では随分前にMD5の利用を止めています。SHA1が同様な状態になるまではまだまだ時間が必要ですが時間の問題となってきたのかも知れません。

ところで、Webシステムの中にはいまだにパスワードをプレインテキストで保存している所が多数あります。メールで「パスワード」を教えてくれる大手サイトも少なくありません。最低限、SHA1ハッシュでパスワードは保存しましょう… できればsalt付きで。

パスワードの最大文字数が少なすぎるサイトも稀に見かけます。パスワード文字列が少なすぎるサイトなら簡単にクラックされる可能性があります。256バイトくらいは入力できるようにしておいた方が良いでしょう。数年前の研究結果だったと思いますがその論文によると、文章になっている長い文字列のパスワードの場合、辞書に載っている単語ばかりを利用していても十分な強度持っているとされていました。