PS3でも動作するMomonga Linux 3 for PPC64

Momonga Linuxメンバーの方がインストール可能なPPC64のDVDイメージの公開を準備中です。

rpm系では初!と思われる full 64bit(ppc64) の環境です。
Momonga ppc64 環境が初めて日の目を見るかも…

との事です。

私はISOイメージを手に入れたのでとりあえずDual G5のMacに入れてみよう。

Zero3 esにプレミアムバージョン

名刺リーダーが追加されて3000~4000円増しで発売されたのですね。知りませんでした。既に購入済みユーザーにも販売されるようです。連絡先に自動登録できるのかな? 名刺リーダーは欲しかった機能なので買います。

個人的には必要ないですがコレを見るとワンセグチューナーもあるようです。無線LANカードプロジェクタにつなげるオプションもあったり(MiniSDに付けるタイプはこちら)至れり尽くせりです。

電話としてはちょっと困る事(フリーズしたり)もありますが、お勧めの1台と思います。私の周りではZero3 es人口急増中です。

追記:
モニタに出力できるIMSV-841が買える場所がない、と思っていたらこんなページを見付けました。

http://kureyon88.seesaa.net/article/21568393.html

価格差が大きいですね。

VAIO Z1をメモリ増設して延命

プリンストンテクノロジーのページを見ると自分が持っているVaio Z1は1GBのDIMMを付ける事ができるようです。Core2DuoのMac Bookを買おうかと思っていたのですが1GB DIMMに交換して少し延命する事にしました。どちらにしてもこのノートも捨てる訳ではないので512MB -> 1GB DIMMに交換しても良いかなと。

多分載せる事ができるだろうとは思っていましたがこれで安心して買う事ができました。ありがとうプリンストン 🙂

と言うことで今日、通販で買ったプリンストンのメモリ(バルクより高いですが情報提供料としてプリンストンテクノロジー製を購入。今値段を調べたらこのメモリ、買った時に比べてめちゃくちゃ安くなってますね…)が届きました。768MBと1256MBではWindowsの動作は雲泥の差です。メモリが少なくてディスクアクセスが多くて困っている方には、この手のアップグレードはお勧めです。
# 一部のVaio Z1には1GBのDIMMは付けれないようです。ご注意下さい。

ところでノートPC用の512MB DIMM(PC2100)が余ってしまいました。送付するのは面倒なので高松近郊にいらっしゃる方限定になってしまいますが、STLUGのオフ会に来れる方でこのDIMMが有効活用できる方であれば差し上げます。メール下さい。
# STLUGの方、私のブログ読まれているかな??

Momonga Linux 3のX

Momonga Linux 2では普通にXも使えていたPCにMomonga Linux 3をインストールしたところXが起動するとZAPもVCへの切替えもできない状態になりました。インストールまでは通常通りGUIでインストールできたので設定の問題であることは明らかです。勘でDRIかな?とxorg.confを編集してdriモジュールをロードしないようにしたら普通に使えるようになりました。
# 当然DRIは使えませんが、Xは使えるようになりました。
# ディスプレイドライバはviaです。

もしインストール後にXが使えなくなった方、DRIを無効にしてみると良いかもしれません。

この他にもnVidiaカードを使っている方はxorg謹製のnvドライバを利用するよりvVidiaが提供しているドライバを使用した方が良いと思います。nvドライバだとXが全く動作しなかったり、少し動作してもすぐにおかしな状態になる場合あります。nVidiaが提供しているドライバもバージョンによって当たりハズレがあります。ハズレに当たるとどうやっても正常に動作しない事があります。私はIA32用(i686)の

NVIDIA-Linux-x86-1.0-9629-pkg1.run

を945チップセット+GeForce6600、TwinView有効で利用しています。特に問題もなく快適です。

IA64(x86_64)の場合、1.0-8776は当たり、1.0-9626はハズレだそうです。

参考:http://wiki.ohgaki.net/index.php?Momonga%20Linux%2FNVidia%20TwinView

SANS TOP20

SANS TOP20が更新されています。

Cross Platformの一位が「Web Applications」になっています。PHP以外のWebアプリにもセキュリティ上の問題が数多くあることに気が付いたと言うことでしょう。といっても解説はPHPが対象となっています。HTTP Response Splittingは最近のPHPでは不可能になっていますが記載されています。(header関数でCR,LFは送信できないよう仕様変更されている。最近ではPythonで作られているtracにHTTP Response Splitting脆弱性が見付かっている)

PHP以外のアプリでも問題が多い事を示している統計情報もあります。例えば、これなど
http://internet.watch.impress.co.jp/cda/news/2006/07/24/12759.html
対象はJavaのWebアプリが多いと聞いています。

XSSと異なり、SQLインジェクションなどは100%防げるにも関わらずこういった状況のようです…

フォームの2重送信はセキュリティ問題か?

備考:前のエントリのコメントに対してこのエントリを作成しました。

セキュリティ対策の3大要素の一つとしてデータの整合性(Integrity)があります。3要素は私が勝手に決めたことではなくISO規格でも決まっています。

個別のアプリでの解釈の問題になりますが、データの整合性に重複送信が含まれない、と考えるのであればコメントされている通り「発想が変」と言う考え方になるかもしれません。重要なデータでなければ(例えばブログへのコメントなど)安全性とは無関係といってもあまり差し支えないです。しかし、注文や送金などのデータでは致命的です。

# 認証システムが無いサイト(必要ないサイト)
# に「認証システムが無い」からといって「セキュリ
# ティ問題だ」と騒ぐ必要がないのと同じでデータ整
# 合性が必要ないサイトではセキュリティ問題になり
# ません。だからと言ってデータ整合性の問題が
# セキュリティ問題でなくなる訳ではありません。

従ってデータの整合性が必要でないサイトやアクセシビリティを気にしないサイトであればREFERERでCSRF対策したサイトでも、2重送信対策をしていないサイトでも問題ないといえるでしょう。データの整合性がセキュリティ問題でないサイトも多くありますが一般的にはセキュリティ問題といっても差し支えないと考えています。(認証の問題がセキュリティ問題であると同じように、データの整合性もセキュリティ問題ということです)

# REFERERを送ってこないクライアントからは
# 接続を受け付けなければアクセシビリティ
# の問題になります。

安全性が低いサイト、アクセシビリティが低いサイトを作ることは自由です。しかし、お勧めできるサイトでないと考えています。完全なCSRF対策(と2重送信対策)を施したサイト作っても手間はほとんど変わりません。これらの理由からREFERERを利用したCSRF対策、ハッシュ値等を利用した2重送信対策は不完全・不適切な対策であると考えています。

refererでCSRF(XSRF)対策…

フォームにランダムで一意なIDを割り当てる方式も十分簡単だと思いますがREFERERでCSRF対策を行っているサイトが結構あるようですね…

FlashでREFERERが書き換えられる問題は別次元の問題だとしても、REFERER自体ブラウザが送信するデータであるため元々信頼できるデータでは無いです。随分前からクライアントレベルのセキュリティ対策ソフトウェアの中にはREFERERヘッダを削除する物もあります… 社内サーバから外部リンクをクリックした場合に社内サーバのURLが外部に洩れないようにREFERERヘッダを削除するプロキシもあります…

一般的な環境からなら使えるから(ある程度安全)といってセキュリティ対策にREFERERを使用するのは良くない考え方です。

ところでREFEERERでCSRF対策を行っているサイトは同じフォームの重複送信対策はされているのでしょうか?送信されたデータのハッシュを取って同じだったら重複とみなすとか?(この手のサイトは「2回以上送信ボタンを押さないでください」と設計ミスが明記されていることが多いです…書いてないサイトも多いと思います)

今日の驚き!

何故かmb_send_mailでメールが文字化けする、普通に運用しているサーバでは問題が無いにも関わらず…

調べてみるとmbstring.languageのaccess設定が6になっていました。6つまりスクリプトからは変更できない状態になっています。運用サーバ環境(開発環境含む)ではphp.ini設定はほとんど全て仮想サーバレベルで設定していたので今まで気が付きませんでした。

mbstring.languageの設定が変更できないと、mb_send_mail()を使って正しくメールを送信することができなくなります。(日本だけ、とかなら良いですが)この件、かなり「怒」なので時間ができたら誰が変更したか調べる事にします。

PHPは5.1…

追記:
mb_send_mail()で文字化けで困っている方は、php.iniなら

mbstring.language = “japanese”

Apacheの設定ファイル、.htaccessなどなら

php_value mbstring.languge japanese

と設定します。これで日本語メールでも文字化けしなくなります。デフォルトのmbstring.language設定(neutral)の場合、日本語メールは正しく送信できません。

パッチをするなら(PHP_5_2ブランチ)

cvs diff: Diffing ext/mbstring
Index: ext/mbstring/mbstring.c
===================================================================
RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
retrieving revision 1.224.2.23
diff -u -r1.224.2.23 mbstring.c
— ext/mbstring/mbstring.c 11 May 2006 14:47:34 -0000 1.224.2.23
+++ ext/mbstring/mbstring.c 10 Nov 2006 05:10:51 -0000
@@ -739,7 +739,7 @@

/* {{{ php.ini directive registration */
PHP_INI_BEGIN()
– PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_SYSTEM | PHP_INI_PERDIR, OnUpdate_mbstring_language)
+ PHP_INI_ENTRY(“mbstring.language”, “neutral”, PHP_INI_ALL, OnUpdate_mbstring_language)
PHP_INI_ENTRY(“mbstring.detect_order”, NULL, PHP_INI_ALL, OnUpdate_mbstring_detect_order)
PHP_INI_ENTRY(“mbstring.http_input”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_input)
PHP_INI_ENTRY(“mbstring.http_output”, “pass”, PHP_INI_ALL, OnUpdate_mbstring_http_output)

1行パッチなので他のバージョンでも同じ場所を直せばOKです。パッチをすればmb_language()で言語設定を変更しmb_send_mail()で正しくメールが送信できるようになります。

httpOnlyをFirefoxで

PHP 5.2.0のsetcookie/setrawcookie関数からhttpOnly属性をクッキーにつける事ができるようになりました。httpOnly属性はMicrosoftが独自に拡張した仕様で、JavaScriptからクッキーの値を使用できなくする機能です。httpsでのみクッキーを送信するsecure属性に似ています。

Microsoftの独自拡張なのでIEでは利用できましたがFirefoxでは利用できません。しかし、アドオンを使用することでhttpOnly属性をFirefoxでも利用できるようです。

httpOnly
by Stefan Esser

Adds httpOnly cookie support to Firefox by encrypting cookies marked as httpOnly on the browser side, so that JavaScript cannot read them.

Hardened PHP ProjectのSfefanさんが作者です。

XSSで自分のセッションを盗まれるリスクが低減できるのでお勧めのアドオンだと思います。

Firefox 2.0 ではおかしなクッキーの動作が一部だけ直っている模様

備考:名無しさんの指摘でタイトルを変更、一部本文を修正しました。(IEとFFの立場を入れ替えました)

少なくとも2006年1月ころのMozilla系ブラウザには簡単に設定できるべきでないクッキーが設定できてしまう問題がありました。最悪なのはco.jp等、ccTLDの属性ドメインに対してクッキーが設定できてしまう動作ですが、手元のFirefox 2.0で試したところHTTPのSet-Cookieヘッダではco.jpには設定できなくなっています。しかし、この修正が中途半端でJavaScriptからdocument.cookieにco.jpにクッキーを設定できてしまいます。(名無しさん、情報ありがとうございます)

example.co.jpとwww.example.co.jpに同じ名前のクッキーを設定するとexample.co.jpのクッキーが返ってきます。下位ドメインによるクッキーの上書きが出来ないのは従来どおりのようです。(複数のクッキー値がドメイン毎に設定される)明示的にwww.example.co.jpドメインからexample.co.jpドメインのクッキーを上書き/削除できるのも従来どおりのようです。host1.example.jpからhost2.example.jpのクッキーが設定できるのも従来どおりのようです。

# 上位ドメインのクッキーを設定できるのに同じレベルのドメイン
# クッキーが設定できなくてもあまり意味が無いです。
# PHPユーザの場合、my-server.hosting.jpの様なドメインを
# 持つサイトの場合、余計なクッキーの削除と外部からのセッ
# ションIDを受け入れないように注意が必要ということ意味し
# ます。

KHTML(Safari、Konqurer)は2004年くらいにこの問題(ccTLDのクッキー)には対応済みと思います。

IE6/7では今のFFと同じでほかの上位ドメイン等のクッキーの上書き/削除は同じ動作をするようです。

もう少し調査が必要ですが、とりあえずccTLDに関しては最新ブラウザを使っていれば大丈夫なようです。まだまだ最新ブラウザでも安心できないようです。

参考:
Multiple Browser Cookie Injection Vulnerabilities
Client Side State – HTTP Cookies
HTTP State Management Mechanism (RFC2109)
HTTP State Management Mechanism (RFC2965)

RFC2109(Cookie1)はNetscapeクッキーの後追い標準なので仕方ないですが

* A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.

* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.

* A Set-Cookie with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.

* A Set-Cookie with Domain=ajax.com will be rejected because the
value for Domain does not begin with a dot.

と親ドメインへのクッキー設定は標準です。example.co.jpでco.jpにクッキーを設定できないとは書いてありません。

Cookie1の定義では

cookie = “Cookie:” cookie-version
1*((“;” | “,”) cookie-value)
cookie-value = NAME “=” VALUE [“;” path] [“;” domain]
cookie-version = “$Version” “=” value
NAME = attr
VALUE = value
path = “$Path” “=” value
domain = “$Domain” “=” value

とパスとドメイン情報を送信することになっていますが、IEもFirefoxも

Cookie: var=FOO;var=BAR\r\n

という感じでパスもドメイン情報も無しで、複数の値を送ってきます。IE,Firefox共に先に親ドメインの値を設定するようになっているようです。

パス設定が行われている場合は最適なクッキーから順番に書くようになっている

If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific.

のですが、ドメインの方は

Ordering with respect to other attributes (e.g., Domain) is unspecified.

と未指定です。IE,Firefox共にここはRFC仕様と同じでパスが指定されているときは一致度が高いクッキーから順番に返し、ドメインは上位ドメインから順番に返してきます。

PHPの場合、先に設定された値が$_COOKIEに入るので複数のPATHが指定された場合は期待通りの動作をしますが、複数のDOMAINが指定された場合はホストのクッキーではなくドメインのクッキーが使われてしまいます。

このため余計なクッキーが設定されないようにクッキーを設定する場合、setcookie/setrawcookie関数のラッパーを書いてドメインのクッキーを削除してからクッキーを設定するようにしないと問題となる場合があります。

# セッションIDが設定されている事によるDoSやSessionIDの固定化を
# 防ぐにはsetcookie(‘PHPSESSID’,”,0,path,domain);
# 等とします。pathはパス、domainはドメインを指定する文字列。

どちらにしてもRFCに記述されている$Version, $Path, $Domainは無視しているのでIE,Firefox共にいわゆるOldクライアントとして動作していることになります。IE, Firefox共にSet-Cookie2:ヘッダは無視しています。Web黎明期の仕様はあまりセキュリティを考慮しておらず今でもその仕様に従わざるを得ないのは仕方ないです。下を見て比べても有意義ではありませんがSMTPよりはマシかな…

しかし、ドメイン指定で複数の値がある場合にホストと完全に一致したクッキーから順番に返してこないのはNetscapeの動作がそうなっていたからなのでしょう。コーディングした人は「順番なんてどちらでも良いや」くらいに思っていたと推測できます。(それともNetscapeクッキーの仕様では親ドメインのクッキー優先?)ドメイン、パスを明記するRFCのクッキー仕様通りならサーバ側で意図通りの値のみを使用する事も可能ですが、IE,Firefox共にパスやドメイン情報を返してきません。複数のパス、ドメインに一致するクッキーは

Cookie: var=v1;var=v2;var=v3;var=v4;

と、どれがどれだか全く判らない状態で値を返してきます。(パスだけ設定されている場合はパスの一致度が高い物から先に値が設定されます)当然ですがこの動作だとパスとドメインで一致度が高いクッキー値をサーバ側で判別不可能です… 自衛策としては上位ドメインで設定されたクッキーを明示的に削除するしかありません…

PHP 5.1/4.4用のセキュリティパッチ

PHP 5.2.0がリリースされていますが少なくとも2つ重要なセキュリティフィックスがあります。5.1/4.4ユーザが5.2.0にアップグレードするには時間が必要と思うのでWikiどのパッチが必要か書いておきましたPHP4はこちらです。

PHP4.4にはありませんがPHP5.1にはecalloc(メモリ確保関数)に整数オーバーフロー脆弱性があります。この脆弱性は随分前にPHP4で修正されたバグですがPHP5ブランチにマージされ忘れていた、という代物です。最も簡単に攻撃可能なケースはserializeされたPHP変数をフォームやURLに埋め込みそれをunserializeで処理しているケースです。

htmlspecialchars()/htmlentities()のヒープオーバーフローのPoCは見かけていませんがパッチを見ればどのような入力でオーバーフローするのか見る人が見れば直ぐ分かると思います。