PostgreSQL 8.1.1リリース

PostgreSQL 8.1.1リリース

PostgreSQL 8.1.1がリリースされました。

http://www.postgresql.org/ のLATEST RELEASESからダウンロードできます。

Outer Join、CHECK文の不具合、sub selectの不具合などが修正されているそうです。他にも色々修正されているので不具合でお困りの方は試してみてはいかがでしょうか?

Athlon64 3200+/3GB/SATA HDD/1GbE/MomongaLinux x86_64開発版 にPostgreSQL 8.1.1をインストールしてPentiumDのマシンからpgbenchを実行した結果 (スケールファクタ 10、TCP接続設定以外はデフォルト)

[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000
starting vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 282.428887 (including connections establishing)
tps = 282.667102 (excluding connections establishing)
[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000 -S
starting vacuum…end.
transaction type: SELECT only
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 4822.840200 (including connections establishing)
tps = 4892.360725 (excluding connections establishing)
[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000 -N
starting vacuum…end.
transaction type: Update only accounts
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 301.807334 (including connections establishing)
tps = 302.361132 (excluding connections establishing)

share_buffers=20000 (デフォルトは1000)

[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000
starting vacuum…end.
transaction type: TPC-B (sort of)
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 329.863325 (including connections establishing)
tps = 330.396068 (excluding connections establishing)
[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000 -S
starting vacuum…end.
transaction type: SELECT only
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 5771.386160 (including connections establishing)
tps = 5875.513153 (excluding connections establishing)
[yohgaki@dev php-4.4.1]$ pgbench -p 5432 -h 192.168.100.120 -U yohgaki -c 10 -t 1000 -N
starting vacuum…end.
transaction type: Update only accounts
scaling factor: 10
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 397.720948 (including connections establishing)
tps = 398.210553 (excluding connections establishing)

インターネットエクスプローラーで Googleローカルへアクセスすると地図が…

グーグルローカルではかなり複雑なJavaScriptを利用しているのですが「これでトラブルは発生していないのかな?」と思っていたらやはり結構苦労が多いようです。

1. Internet Explorer を起動し、[ツール] をクリックします。
2. [インターネット オプション] を選択します。
3. [全般] が選択されていない場合は、[全般] をクリックします。
4. [インターネット一時ファイル] で [ファイルの削除…] をクリックします。
5. [OK] をクリックして終了します。

これは基本ですよね。理由は知りませんが大量のキャッシュファイルが残ると何もかもおかしくなってしまいます。設定をはるかに超える量のキャッシュがキャッシュディレクトリに残ってしまう事があります。全てのファイルを消すまでに1時間以上かかったケースを目の当りにした事も…

ところで、URLを見ると.pyなのでpythonなのかな?
http://local.google.co.jp/support/bin/answer.py?answer=21849

ちなみにMSの http://local.live.com/ ですがFirefox 1.5(Windows版)でアクセスするとクリックしないとドラッグしたままになる問題がありました。Firefox 1.0(Linux版)では問題なくドラックできました。Firefoxを利用してlocal.live.comでズームするとlocal.google.comの地図をIEでズームした様に画像がズームアップしていきます。Firefoxでも同じ事がやろうと思えばできるんですね。

衛星画像ですがlocal.live.comの方がより細かい画像でした。しかし、場所によっては夜に撮影したと思われる画像もありました。少なくともNew York市の衛星写真は夜撮影したと思われる画像でした。

MS、Google両方ともアメリカの地図であれば経路検索もできるようになっていました。カーナビがGoogle化する日も近い?! G-Book危うし?!

VS 2005のExpress Editionは事実上,無償提供へ

自分のWikiのAdWords広告に以下のようなVisual Studioの広告が載っていたので見てみました。

Web アプリを開発するなら
Microsoft Visual Studio 2005 シンプルで使いやすい充実の機能満載

Beta2版とは言え自由にダウンロードできそうな感じだったので検索してみると

VS 2005のExpress Editionは事実上,無償提供へと言う記事を見つけました。1ヶ月も前の事なんですね。

1年間限定らしいのでVSを持っていない方はとにかく正式版がリリースされたらダウンロードだけはしておいても良いかも知れません。

改訂版PHPポケットリファレンスに載るはすだったページ

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

改訂版PHPポケットリファレンスに載るはずだった「言語仕様」に関する記述をWikiに載せました。私が直接聞いた感想ではこの言語仕様のページを気に入っているとおっしゃる方も多かったです。短いのでPHPをまったく知らない方が感じをつかむには便利(?)かも知れません。

脆弱性がオークションに

eBayでEXCELの脆弱性が売りにだされたそうです。eBayの基準に合わないとして削除されたそうですが、0.01ドル(1セント)から売りに出され21件の応札があり$56にまで値上がりしたそうです。
# 似たような事は前にもあったと思いますが見つけられませんでした。

qmailの脆弱性なら作者から$500、qmailのユーザグループから$1000djbdnsの脆弱性なら$500の懸賞金がもらえます。

途中で削除されたとはいえ$56は高いのか安いのか?

JNSAセキュアシステム開発ガイドライン

今の所ベータ版のようですがJNSAから「JNSAセキュアシステム開発ガイドライン」という文書が公開されています。

非常に細かい部分では追加・修正しても良いのかな?と思える部分もありますが、全体としては非常に良い文書だと思います。Webシステム開発で不十分なRFPをもらった時には利用させてもらいます。確かJNSAの文書は会員でないと自由にダウンロードできなかったので正式版になる前に非会員はダウンロードできなくなると思います。参考にされたい方はダウンロードはお早めに!?

RedHatのWeb開発スタック

LAMP+PostgreSQLはシンプルなサイト用に

Red Hat says the Web Application Stack is for simple web sites and applications, and includes the key LAMP components Apache HTTP Server, MySQL database and the PHP scripting language on top of Red Hat Enterprise Linux. Customers will be able to choose the PostgreSQL database, which will be an option with the Web Application Stack.

http://www.redhat.com/docs/manuals/database/
にあるようにRedHatはPostgreSQLを推進(RedHat Databaseの中身はPostgreSQL)するはず、だったのですがRHDBをバージョンアップしませんね…

Javaは何でもあり用に

It says the Java Web Application Stack is for more dynamic web applications and supports all the components of the Web Application Stack – in other words LAMP plus PostgreSQL – as well as the Apache Tomcat servlet and JSP Container. There will be support and updates for the key Java development libraries and tools – Apache Struts, Apache Axis, Spring, Hibernate, Lucene, Ant, Junit, Jython, Log4J and key XML libraries.

JythonがあるあたりはRedHatらしい。

基情報となる情報をRedHatのサイトを探してみまると2005/12/6のプレスリリースが基ネタのようです。

PHP/tips/モジュールにバグがあった場合の対処

今更… という方もいらっしゃるかも知れませんが「PHP/tips/モジュールにバグがあった場合の対処」ページをWikiに作りました。

PHPのモジュールは基本的にはモジュールAPIが同じであればどのPHPと一緒に使っても構いません。つまり前のバージョンのモジュールが期待通りに動作していたのであれば、新しいPHPで古いモジュールを使えばよいのです。

# ただしセキュリティFIXが含まれる場合はセキュリティ用のパッチ
# を別途含めることをお忘れなく。

IE7の新機能

Intranet ZoneでもActiveXは自動インストールできなくなるようです。

http://blogs.msdn.com/ie/archive/2005/12/07/501075.aspx

As a safety precaution in IE7, we have set the default for the Trusted Sites zone to Medium, the same level as the Internet zone in IE6.

管理者権限が無くてもプラグインがインストールできるのは良いですね。

http://blogs.msdn.com/ie/archive/2005/09/20/471975.aspx

1. Start IE with elevated permissions: click Start, point to All Programs, right-click IE, and then select Run Elevated.
2. Perform the ActiveX installation.
3. Exit the current instance of IE.
4. Start a new instance of IE normally (without Administrator permissions).

Webサイトを運用する側としてはSSLv2が使われなくなる点に注意が必要かも知れません。

Microsoft will also discontinue the use of the SSLv2 (Secure Socket Layer) protocol in IE7 and use the stronger TLSv1 (Transport Layer Security) protocol—part of an overall plan to improve the security and user experience for HTTPS connections.

しかし互換性の為にいろいろやってますね。管理者権限を持たないユーザでWindowsを使っていると分かりますが、管理者権限を持っている事が前提に作られているアプリケーションはかなりあります。Windowsの歴史と仕様などからある程度仕方ない部分もあるのですが、普通のユーザでWindowsを使うと本当に使いづらいです。OSXは気にならないように作られているのですけどね。


20周年記念WinXPアップグレードパッケージ
を買うとVistaのプレビュー版がもれなくもらえるそうです。そのためだけに3万弱は高過ぎですが、WinME、Win2000等をアップグレードしたい方にはちょうど良いかも?

PCセキュリティ対策は日米そう変わらず?

News.comの記事によると、平均的(?)な家庭のPCは

-56%はアンチウィルスソフトをインストールしていないか、1週間以内にシグニチャを更新していない。
-44%はファイアーウォールを正しく設定しない。
-38%はスパイウェア対策がとられていない。

とあります。これでも昨年に比べるとかなり改善されているそうです。

MSの悪意のあるプログラム駆除ツールにWinnyのウィルス(Antinny)も含まれるようになり20万件駆除したそうです。それでも6割りほどしかウィルスが発生させるトラフィックが低下しなかった、と言うことは4割程度のユーザは適切な時期にWindows Updateを実行していない事になります。再感染もあったり、Winnyを使うユーザ層が一般的なユーザを代表しているとは言えないので直接は比較できませんが、Antinnyに感染しているPCがホームPCのみと仮定すると日米ともにホームユーザの安全性対策は同じ程度なのかも知れません。

ブログエントリを更新

もうちょっと検証してからブログエントリを公開しては?とご指摘いただいたので。

ブログの紹介にエクスキューズとして「個人的に気になったことなどを思いのままに書いています。他の方に役立つかは不明です。」とは書いていても読まれる方が増えているので、そうも言ってられません。2005/12/06のエントリには間違いがあったので修正・追記しました。既に2005/12/06のブログエントリを読まれた方は修正版も是非どうそ。

http://blog.ohgaki.net/index.php/yohgaki/2005/12/06/a_a_ia_ca_la_a_a_a_lphpa_sa_ma_oa_a_a_ua
http://blog.ohgaki.net/index.php/yohgaki/2005/12/06/e_e_a_pa_a_ca_a_a_ca_pa_o_php

気を取り直してPHP5.1.2リリース予定

PHP 5.1.0がリリースされた時のブログエントリに「PHP 5.1を評価しはじめるのはPHP5.1.2からでは」とコメントを書きました。そのPHP5.1.2ですが次のような予定にしては?と本家のMLには投稿されています。

PHP 5.1.2から評価しては、と自分で書いていますが、バグを見つけてバグデータベース

http://bugs.php.net/

に投稿するには今が良い時期と思います。

Date Summary: (not be confused with date extension ;-) )

Until Dec. 10, 2005: Minor features and bug fixes requiring major changes
Dec. 22, 2005: RC1
Jan. 05, 2006: RC2
Jan. 12, 2006: Final (pending critical issues since RC2)

Planned Changes:

* Resolve all currently opened Engine bugs, ideally 5.1.2 will be
released without any unresolved engine problems.
* Resolve all currently open PDO bugs.
* Enable xmlreader extension by default, as we do for all XML
extensions.
* Introduce hash extension via a symlink from pecl into core.
This extension introduces native implementation of common hash
algorithms with streams support, making it an excellent solution
for people requiring better hashing then provided by md5/sha1.
Merits of this extensions have been discussed on this list few
weeks ago, just scroll past the recent flame wars ;-)
* Introduce xmlwriter extension via a symlink from pecl into core and as
other XML extension enable it by default.
* Backport oci extension into 5.1, this is mostly for bug fixing
reasons, as the new code fixes over a dozen bug reports in that
extension.

不適切なアドバイザリ(was 間違ったアドバイザリ) – PHP

SECUNIAから間違った不適切なアドバイザリがレポートされていました。アドバイザリは下記の引用を参照してください。(Web版は修正される可能性もあるので直接貼り付け)

基本的にはメールに送信するTOをスクリプトでチェックしていない事がスクリプトの問題です。

TO(あて先)RFC822の仕様に従いヘッダに記載される情報をCR/LFと1以上の’ ‘(スペース)かタブで区切れる事になっています。この処理に問題がありSPAMメールを送信する踏み台にされるケースがあったようです。mailは元々はsendmailコマンドを使ってメールを送信(Windowsの場合はSMTPですが)するように作られているのでTOにRFC822仕様のデータを送るのはスクリプト側に問題があると思います。

これはPHPの脆弱性と言えない部分もあるのでそもそものアドバイザリが間違っています不適切と思います。”Moderately critical”と言うレベルも不適切です。さらに対処方法まで間違って不適切です。どちらかと言うとアプリの脆弱性としてレポートした方が良いのではないかと思います。アプリの脆弱性とレポートした方がPHP本体をバージョンアップするより、アプリのバージョンアップの方が簡単なのは明らかですから。しかし、mailと比べるとmb_send_mailの実装に不備があったのは確かなのでPHPの脆弱性である、とも言えるので微妙なアドバイザリだと思います。

スパムメール送信の踏み台に使われたアプリがどのアプリか知りませんが、どれかのWebメールプログラムだと思います。WebメールプログラムはWebアプリの中でも安全に構築する事がかなり難しいアプリの一つです。Webメールアプリを作られる方はTOヘッダに送る情報はチェックした方が良いと思います。

この件と似た例ではsafe_modeのアドバイザリがあります。「DBMSからファイルを読み込めばsafe_modeを回避できる」と言うアドバイザリ等、safe_mode関連ではアドバイザリが幾つかあります。PHP本体の開発者はsafe_modeチェックの不足があれば、問題として捉えるべきとは思います。しかし、DBからファイルロードしてアクセスする、となると話は別です。PHPプログラマはsafe_modeはfail_safe_modeと考えて、意図せずコードに問題があり不正にファイルにアクセスできてしまった時の防衛策、位の安全を提供する機能と考えるべきです。しかし、しばしば本当に安全で完全にファイルへのアクセスを制御できる、と思われがちです。

PHPはプログラミング言語とは言ってもフレームワーク的な要素を持っているので、safe_modeやsafe_modeに順ずるチェック行うべきではない、とも言えません。他のスクリプト系言語でもユーザ入力についてはフレームワーク的に対処していたりしています。どこまで行うべきか悩ましい所と思います。

PHP6ではsafe_modeは削除候補ですが、個人的にはsafe_modeは有用なのでfail_safe_modeとして残っていた方が良いと思っています。悪貨(不適切なアドバイザリ)が良貨(有用な機能)を駆逐している、という感想です。

備考:きちんとTOアドレスを確認している方はこのアドバイザリを気にする必要はありません。きちんと確認していない場合、PHPのバージョンアップは必要ありません。自分のコードを修正しましょう。

追記:最初にこのエントリを書いたときにcvs upの不良でmb_send_mailではチェックしている項目をmailではチェックしていない、と思っていました。しかし、PHP 5.1.1でmailではチェックされていた事をmb_send_mailでもチェックする様になった、が正しいです。komuraさん、ありがとうございました。

<blockquote>From:Secunia Security Advisories <sec-adv@secunia.com>
Date:28 Nov 2005 14:19:43 -0000
Subject:[SA17763] PHP “mb_send_mail()” “To:” Header Injection Vulnerability
——————————

TITLE:
PHP “mb_send_mail()” “To:” Header Injection Vulnerability

SECUNIA ADVISORY ID:
SA17763

VERIFY ADVISORY:
http://secunia.com/advisories/17763/

CRITICAL:
Moderately critical

IMPACT:
Security Bypass, Manipulation of data

WHERE:
>From remote

SOFTWARE:
PHP 4.4.x
http://secunia.com/product/5768/
PHP 5.0.x
http://secunia.com/product/3919/

DESCRIPTION:
s.masugata has reported a vulnerability in PHP, which potentially can
be exploited by malicious people to use it as an open mail relay.

The vulnerability is caused due to an input validation error in the
“mb_send_mail()” function. This can be exploited to inject arbitrary
headers in a mail sent via a script calling the “mb_send_mail()”
function where the “To” parameter can be controlled by the attacker.

SOLUTION:
Update to version 5.1.0.
http://www.php.net/downloads.php

Do not call the “mb_send_mail()” function in scripts where input
passed to the “To” parameter originates from untrusted sources.

PROVIDED AND/OR DISCOVERED BY:
s.masugata

ORIGINAL ADVISORY:
The PHP Group:
http://www.php.net/release_5_1_0.php

s.masugata:
http://bugs.php.net/bug.php?id=35307

———————————————————————-

ファイルが勝手にスクリプトとして実行される

また困った問題が見つかりました…(問題と言うより仕様に気が付きました)

full-disclosureで「これおかしくない?」と報告されています。Wikiがフィッシング(Phishing)に利用される問題などがあったので影響を受けるシステムは少なくなっている、とは思いますが直ぐに攻撃のまだまだ影響を受けるシステムも多いと思います。

個人的にはLinux上のApache 2.0.54上のPHP 5.0.5/PHP 5.1.1が影響を受ける事を確認しました。
(Mac OSXでも同様の動作である、と聞きました)

http://137.113.100.11/manual/ja/mod/mod_mime.html

によると

ファイルは複数の拡張子を持つことができ、拡張子の順番は通常は関係ありません。例えば、ファイル welcome.html.fr がコンテントタイプは text/html に、言語はフランス語にマップされる場合、welcome.fr.html もまったく同じ情報にマップされます。 同じメタ情報にマップされる拡張子が複数あるときには、右側にあるものが使用されます。たとえば、”.gif” が MIME タイプ image/gif にマップされ、”.html” が MIMEタイプ text/html にマップされる場合は、ファイル welcome.gif.html は MIME タイプ “text/html”に関連付けられます。

複数の拡張子のあるファイルが MIME タイプとハンドラの両方に関連付けられているときは注意する必要があります。その場合、普通はリクエストがハンドラに関連付けられた モジュールによって扱われることになります。たとえば、拡張子 .imap が(mod_imap の) “imap-file” にマップされていて、 .html が MIME タイプ “text/html”にマップされているときは、ファイル world.imap.html は “imap-file” ハンドラと “text/html” MIMEタイプに関連付けられます。ファイルが処理されるときは “imap-file” ハンドラが使用されますので、そのファイルは mod_imapのイメージマップファイルとして扱われることになります。

つまり、test.php.bakがPHPスクリプトとして実行されるのは仕様のようです。

記憶が曖昧ですが古いApacheはこんな動作ではなかったと思ったのですが、調べてみると1.3からはずっと同じのようです。

拡張子による適用されるハンドラのチェックは普通に行われているので、この仕様には十分注意が必要ですね。

■概要

アップロードされたファイルなどがスクリプトとして実行できる。

■問題

Aapche 1.3系、2.0系のSAPIとして動作(Apacheモジュールとして動作)させている場合、httpd.confのAddTypeディレクティブで登録された拡張子のファイルのみPHPスクリプトとして実行されるべきです。最近(?)のPHPのApache SAPIは登録された拡張子以外のファイルをPHPスクリプトとして実行してしまう仕様のようです。

例えば、test.php.bak, test.php.rar などhttpd.confにAddTypeでPHPスクリプトとして登録されていないファイルの場合でも勝手にPHPスクリプトして実行されます。PHP以外の言語ハンドラでも同様です。

サンプルスクリプト

<?php echo “This file is executed as PHP script” ?>

このスクリプトをtest.php.bakとしてドキュメントルート以下のディレクトリに保存し、PHPがインストールされている場合、PHPスクリプトとして実行する事が可能です。

Apacheに登録されていない特殊な画像ファイル(psd等)、圧縮ファイル(rar等)、マイナーな文書形式(.jwt等)、etcを取り扱っているサイトは注意が必要です。

私の環境では.html, .txt, .gif, .png等Apacheに登録済みの拡張子はスクリプトとして実行されませんでした。

未検証ですがPHPのみでは無くCGIでもAddHandlerで登録されたハンドラでも同じだそうです。

/cgi-bin/test.cgi.bak

でも同じ様にスクリプトが実行されるそうです。

■影響

主にこの問題の影響を受けるアプリケーションはファイルをアップロード可能なシステムです。アップロードされたファイルがドキュメントルートに配置されている場合、簡単に任意スクリプトをローカルホスト上で実行される可能性があります。

例えば、PHPの

bad.php.bak

等のファイルアップロードされ、ブラウザから参照できるディレクトリに置いてあるとリモートから任意のスクリプトを実行される場合があります。

■対処策

対処策にはいくつかの方法があります。

1.ユーザからアップロードされたファイル等、信頼できないファイルをドキュメントルート以下に配置しない。(そもそも、アップロードされたデータ全てはドキュメントルート以下に配置するべきではありません)
2. Apacheで明示的にTypeが指定されていないファイルはアップロードさせない。(1の対処をするべきです。直ぐには不可能な場合のみ。非推奨)
3.アップロードされる可能性のある拡張子はhttp.confで別のTypeとして登録する(1の対処をするべきです。直ぐには不可能な場合のみ。非推奨)

備考:PHPに限らずイメージ識別関数はファイルのヘッダ部分のみチェックしています。PHPの場合、スクリプトタグ以外の部分単純にecho出力されるためイメージ形式識別関数で形式をチェックしていても普通にエラーの無いPHPスクリプトとして実行可能です。イメージ形式を識別しているからと言って安心することは出来ません。

■まとめ

ファイルアップロードをサポートしている場合、ファイルはドキュメントルート以下に配置しない(基本)を守らないと色々ありますね…