個人的なメモと備忘録 2003年 3月

HOME | LastUpdate: 2004-05-03

目次


2003.03.30(Sun)

やっと暖かくなってきました。

PHP のセッションについての問題に、追記を行いました。本に書かれていることとは少し意味が間違っている部分があるようです。

>>セキュリティ関係

*PHP

セキュリティホール memo の 2003.03.28 の情報で知ったのですが、Bugtraq への投稿として、いくつかの PHP のセキュリティホールが報告されていたようです。該当する環境の方は注意してください。

*Sendmail

メールサーバとして、広く使用されている Sendmail に、またセキュリティホールが見つかったようです。

CERT/CC の、CERT Advisory CA-2003-12 Buffer Overflow in Sendmail や、Vulnerability Note VU#897604 によると、メールアドレスの parse を行うコードに問題があり、buffer overflow が起きてしまう問題があるようです。リモートから、Sendmail の権限( 通常は root )で任意のコードを実行することが可能です。

sendmail.org では、Sendmail 8.12.9 が公開されています。ソースからインストールしている人は、これをインストールしてください。近いうちに、各ベンダーからも修正パッケージなどが公開されると思います。

*RedHat Linux

2003年3月31日で、RedHat Linux 6.2 と RedHat Linux 7.0 の Errata Support が終了になるようです。詳しくは、Errata: Security Alerts, Bugfixes, and Enhancements か、RedHat の日本語サイトである、レッドハット サポート & ドキュメント を参照してください。

公式には情報はないので確認はできませんが、次の RedHat のバージョンは 8.1 ではなく、9 になる(スラッシュドット・ジャパン)という話がありました。

修正パッケージとしては、Samba とカーネルの修正パッケージのページが更新されていました。まだ公開されていなかった修正パッケージの追加があったようです。また、Kerberos の修正パッケージが公開されています。

>>気になったニュースなど

▲ 目次へ戻る


2003.03.23(Sun)

残念ながら、戦争が始まってしまいました・・・。早く戦争が終わるといいのですが。

スラッシュドット・ジャパン世界中でウェブサーバのクラッキングが急増という投稿もあります。セキュリティホールの情報も多いようですし、サーバの管理者は気をつける必要がありそうです。

昔の文書を整理中です。CVS サーバ構築メモを書き直しました。

>>セキュリティ関係

*OpenSSL

OpenSSL のページに、2つの Security Adovisory が掲載されています。

FreeBSD では、これらの問題に対して、既に Security Adovisory が出されています。

*SunRPC

SunRPC の XDR ライブラリに問題があり、このライブラリを使用しているアプリケーションで、リモートから任意のコード実行可能にになるようです。CERT Adovisory によると、Sun Microsystems の libnsl や、 BSD 系の libc、linux などで使用されている glibc にこの問題が含まれているようです。

RedHat Linux では、glibc の修正パッケージでこの問題を修正しています。

*RedHat Linux

多くの修正パッケージが公開されています。カーネル更新は、ローカルユーザが root 権限を取得できてしまうというセキュリティホールの修正のようです。セキュリティホールが見つかった Samba の修正パッケージも公開されました。また、SunRPC の XDR ライブラリにセキュリティホールが見つかったため、その修正のために glibc の修正パッケージが公開されました。

*VineLinux

VineLinux でも、修正パッケージが公開されています。

*FreeBSD

SunRPC のセキュリティホールと、OpenSSL に対する Secrity Adovisory が出ています。XDR の問題に関しては、日本語訳が出ています。

*Windows

Windows スクリプト エンジンの問題により、コードが実行される (814078) (MS03-008)という問題が公開されています。Windows 98, Me, NT 4.0, 2000, XP など、ほとんどのバージョンの Windows で影響を受けるようです。同ページで修正プログラムが公開されています。

攻撃者がこの問題を悪用して、Web ページを作成し、ユーザがそのページを閲覧した場合に、そのユーザの権限で攻撃者の任意のコードが実行される可能性があるようです。

深刻度も緊急になっており、Internet Explorer を使っている人は修正プログラムをインストールする必要があります。

他にも、Windows コンポーネントの未チェックのバッファにより Web サーバーが侵害される (MS03-007)という情報が公開されています。IIS 5.0( Windows 2000 ) で、WebDAV 機能にバッファオーバーフローの問題が見つかり、リモートから IIS の実行権限を取得できてしまうようです。

セキュリティホール memo の 2003.3.18 の情報 に詳しくまとめられていますので、そちらを参考にしてください。さらに、セキュリティホール memo の 2003.3.22 の情報 の情報では、WebDAV を無効にした IIS 5.0 はもちろん、IIS 5.0 が存在しない場合ですら、この弱点を利用した攻撃が可能だと書かれていますので、パッチを当てる必要がありそうです。

>>気になったニュースなど

▲ 目次へ戻る


2003.03.16(Sun)

最近、土曜、日曜日の天気がかなり悪いような気がします・・・。

PHP のセッションについての問題に、結果報告と追記を行いました。実際の運用でセッションを使用する時は気をつけるべきことが多そうです。

インストールメモの中で、PHP4 のインストールメモ と、全文検索システム Namazu のインストールメモ の中で、PHP の Namazu モジュールについての記述が重複していましたので、一つに統合しました。また、古くなった記述の修正や、追記などを行いました。

>>PHP

*Namazu モジュール

最近気がついたのですが、PEAR の Namazu モジュールが 2003.02.15 に随分と久しぶりに更新されていました。どうやら、nmz_set_maxhit(), nmz_set_maxmatch(), nmz_get_maxhit(), nmz_get_maxmatch() という4つの関数が追加されたようです。

PHP-users メーリングリストの [PHP-users 13225] Namazu モジュールのMaxMatch が変更されないという問題に対応した関数のようです。ソースに付属しているドキュメントの方は変更されてないようで、追加された関数の使い方は書かれていませんが、[PHP-users 13275] Re: Namazu モジュールの MaxMatch が変更されない の投稿に簡単な説明が書かれています。

>>セキュリティ関係

*Samba

Samba の 2.2.7a 以前の 2.0.x バージョンでリモートから root 権限を取得することが可能という問題があったそうです。これに伴い、Samba 2.2.8 が公開されています( Samba 2.2.8 のアナウンス )。また、samba-jp のメーリングリストには、Samba 2.2.8 のアナウンス日本語訳が投稿されていますので、そちらも参考にしてください。もし、何らかの理由でバージョンアップや、パッチの適用が不可能な場合の対処についても説明されています。

アナウンスによると、このセキュリティホールは致命的な問題であり、Samba 2.2.8 にバージョンアップするか、TCP Port の 135, 445 へのアクセスを禁止することが強く推奨されています。

Samba 2.2.8 のソースや、バイナリ、パッチのダウンロードは http://master.samba.org/samba/ftp/ から行えます。

*Qpopper

POP3 サーバとして広く使用されているソフトウェア Qpopper のバージョン 4.0.4 以前の Qpopper 4.0.x にリモートから Qpopper の動作権限が取得可能なセキュリティホールが見つかったようです。

既に問題を修正した Qpopper 4.0.5 が公開されていますので、Qpopper を使用されている人は、バージョンアップしてください。

ftp://ftp.qualcomm.com/eudora/servers/unix/popper/ からダウンロード可能です。

*Opera

先日、7.02 が公開されたばかりですが、 Opera 7.03 が公開されたそうです。

Opera、バッファオーバーフロー脆弱性などを修正した「7.03」を公開( Internet Watch )や、セキュリティホール memo の 2003.03.07 の情報にも書かれていますが、バッファオーバーフローに関する問題の修正が行われているようです。また、Flash Player のバージョンアップも行われており、Opera を使っている人は入れ替えた方がよさそうです。

*RedHat Linux

sendmail パッケージが更新されています。

*VineLinux

file の修正パッケージや、VineLinux 2.1.x 用のセキュリティ修正パッケージが公開されました。

>>気になったニュースなど

▲ 目次へ戻る


2003.03.09(Sun)

セキュリティ関係の話題が多い週です・・・。大量の情報がありますので、追いかけるのが大変です。

先週に書いた PHP のセッションについての問題で少し間違っていた部分がありましたので、修正しました。もう少し確認してから書くべきだったと思います。

>>セキュリティ関係

*Sendmail

広く使われている Sendmail にリモートから攻撃可能なセキュリティホールが見つかったそうです。影響を受けるバージョンが sendmail 5.79 〜 8.12.7 ということで、Sendmail を使用しているサーバのほとんどで影響を受けると思われます。

問題は、メールヘッダの From:, To:, CC: に対して不正な値を設定することにより、リモートから root 権限を取得することが可能ということのようです。

以下のサイトに情報があります。

また、セキュリティホールメモの 2003.03.04 に詳しいまとめがあります。

Technical Analysis of Remote Sendmail Vulnerability (Exploit)( SecuriTeam ) に、Exploit コードも出ています。

*Snort

Snort 1.8.0 から 1.9.0 までのバージョンにリモートから攻撃可能なセキュリティホールがあったようです。Snort の動作権限で任意のコードを実行できてしまうという問題で、通常、Snort はスーパーユーザ(root) で動作しているため、非常に危険です。その問題を修正した Snort 1.9.1 が公開されました。

詳しくは、Snort での RPC プリプロッセッシングの脆弱点( ISS ) を参照してください。

また、Snort の ニュース によると、古いバージョンでも、snort.conf で以下のように、preprocessor rpc_decode をコメントアウトすることによって問題を回避することはできるようです。

preprocessor rpc_decode

# 以下のようにコメントアウト

# preprocessor rpc_decode

他にも、Buffer Overflow in Snort RPC Preprocessor( SecuriTeam ) にも情報ががあります。

*Macromedia Flash

Macromedia、「Flash Player」用セキュリティパッチを公開( Internet Watch ) によると、Flash Player 6,0,79,0 が公開されたそうです。Flash Player 問題により、バッファオーバーフローやサンドボックスの脆弱性を利用して、悪意のあるコードが実行される可能性があるということで、入れ換える必要があると思われます。

MPSB03-03 Security Patch for Macromedia Flash Player に詳しい情報があります(英文)。

すぐにダウンロードしたい人は、Macromedia Flash Player のダウンロードページに行くと良いと思います。日本語を選択して、ダウンロードすれば簡単です。トップページからは、少し探しにくい場所にあるような気がします。

*file

指定したファイルのファイルタイプや内容を調べるコマンドの file でセキュリティホールが見つかったようです。

不正なファイルを読み込ませることで、任意のコードを実行することができるようです。既に Exploit コードも出回っていますので、file コマンドを使えないようにするか、バージョンアップするなどの対処を行った方が良いと思います。RedHat Linux では既に修正パッケージが公開されています。

>>気になったニュースなど

▲ 目次へ戻る


2003.03.02(Sun)

もう3月です。時間が経つのが早いです。相変わらずゆっくりする時間がありません・・・。

PHP 4.3.0 の CGI 版に見つかったセキュリティホールの問題について、少し関連情報が見つかりましたので、リンクを追加しました。

>>PHP

*セッション[ 2004.05.03 追記 ]

PHP 4.2.2 でセッション機能を使っていたときの問題に関するメモです。

PHP では、セッション機能を使用することで、ユーザの情報をサーバに保存することができます。セッション機能についてはPHP マニュアルセッション処理関数(Session)のページを参照して下さい。

PHP 4.1.2 以前は、セッションモジュールは簡単にクラッシュするという指摘もありますが、PHP 4.2.x 以降でもセッションに関する問題としては、PHP を --with-mm オプションを付けてコンパイルして、セッション管理に mm を使用した時に、最初のうちは問題ないのですが、しばらくすると Segmentation Fault が起きるという問題で悩んだことがあります。

セッションに mm を使用するには、/usr/local/lib/php.ini では、以下のように設定します。

session.save_handler = mm

その時は、デフォルトである、セッション管理をファイルで行うように設定して問題を回避しました。

session.save_handler = files

この mm の問題に関しては、詳しくは調べていませんので、何が問題かは分かっていません。既に修正されている可能性もあります。

セッションの管理方式をファイルに変更した後、しばらく運営していたのですが、次にセッション切れが起こりやすいという問題が発生し、かなり悩みました。調査のため、久しぶりに PHP マニュアルセッション処理関数(Session)のページを読んでいると、以下のような記述がありました。

session.gc_maxlifetime integer

session.gc_maxlifetime は、データが'ごみ'とみなされてから消去されるまでの秒数を指定します。

注意 デフォルトのファイルに基づくセッションハンドラを使用している場合、使用するファイルシステムは、アクセス時間(atime)を記録できる必要があります。Windows FATはこれができないため、 FATファイルシステムまたはatimeの記録ができない他のファイルシステムで問題を発生した場合は、セッションのガベージコレクト処理を行う他の手段を用意する必要があります。

そのサーバでは、パフォーマンス向上のため、/etc/fstab に以下のような atime を記録しないような設定にしていました。

LABEL=/tmp  /tmp  ext3  defaults,noatime  1 1

このため、読み込み時点では atime が記録されず、うまくセッション管理機能が働かなかったようです。noatime を指定しても書き込んだ時点では atime は更新されるため、大きな問題になりにくく、気づきにくい問題だったような気がします。( 2003.03.09 修正 )

( 2004.05.02 追記 )

この部分の情報は、PHP 4.2.2 までの問題です。PHP 4.2.3 以降では、セッションファイルの管理には mtime が使用されているため、atime を記録できないシステムや、無効にしている場合でも、問題はありません。詳しくは、session.gc_maxlifetime についての説明にある、注意の部分に、以下のように書かれています。

注意: デフォルトのファイルに基づくセッションハンドラを使用している場合、使用するファイルシステムは、アクセス時間(atime)を記録できる必要があります。Windows FAT はこれができないため、FATファイルシステムまたは atime の記録ができない他のファイルシステムで問題を発生した場合は、セッションのガベージコレクト処理を行う他の手段を用意する必要があります。PHP 4.2.3 以降、atime の代わりに mtime(更新時刻)が使用されます。このため、atime が利用できないファイルシステムでの問題は無くなりました。

( 2003.03.09 追記 ) ファイルシステムが ext3 の時にしか確認していませんが、noatime を付けてマウントした場合でも、初回の書き込み時は atime が更新されます。2回目以降のファイルの書き込み時には、更新される時もありますが、簡単なファイル内容の変更では、atime は更新されませんでした。PHP のセッションで使用されているファイルでは、atime は更新されていませんでした。下に確認用の PHP スクリプトを付けておきますので、気になる人は確認してください。

この時は、/tmp で使用していたパーティションを再マウントすることで対処しました。/tmp で、ファイルをオープンしていた Apache と、PostgreSQL を停止し、以下のコマンドを実行しました。

# umount /tmp && mount -o atime /tmp

とりあえず、結論としては、パフォーマンスを優先させると予想していなかったところで問題が発生すると言うところでしょうか。古いファイルを自動的に削除してくれる tmpwatch も使わないので、/tmp もnoatime を指定してマウントしてしまえば良いと思いこんでいたことが間違いだったようです。もっと十分に検証を行ってから設定する必要があることをあらためて痛感しました。

( 2003.03.09 追加 ) ファイルの atime, mtime, ctime の確認スクリプトです。

<?php
$iCount = count( $argv );

for ( $i=1; $i<$iCount; ++$i ) {
    $aFile =& stat( $argv[$i] );
    printf( "File: %-40s atime:%s mtime:%s ctime:%s\n",
        $argv[$i],
        date( "Y-m-d:H:i:s", $aFile['atime'] ),
        date( "Y-m-d:H:i:s", $aFile['mtime'] ),
        date( "Y-m-d:H:i:s", $aFile['ctime'] )
    );
}
?>

使用方法ですが、上のスクリプトを filetime.php というファイル名で保存し、以下のように実行すると、結果が表示されます。

$ cd /tmp
$ php filetime.php sess_*
File: sess_9e4c4f2e2cdf0451cdbea0045837654d atime:2003-03-06:11:54:31 mtime:2003-03-06:19:32:45 ctime:2003-03-06:19:32:45
File: sess_a260a745a28d210f0ef4dd534958ebaa atime:2003-03-07:11:43:45 mtime:2003-03-07:19:37:27 ctime:2003-03-07:19:37:27

atimemtime よりも、早い時間になっているのが分かります。

( 2003.03.16 追加 )

atime を記録させるようにした後、しばらく様子を見ていたのですが、セッション切れの件は緩和されたものの、まだ起こっていたようでしたので、調査すると、一定時間以上アクセスせずにしばらくして(3時間から4時間くらいしてから)アクセスしているようなユーザは、さすがにセッション切れを起こしていました。

この場合は仕方ないので、ハートビート(IPA セキュアプログラミング大全第5章 セキュアVBScript/ASPプログラミング [5-3.] セッションタイムアウト を参照してください )を使用することで対処を行いました。

フレームを使用して、そのフレームの内の1つのページで以下のようなタグを <head> タグの間に記述し、一定期間ごとにセッションを続けるためのアクセスを行わせました。

<meta http-equev="refresh" content="900">

再読み込みを行うページで session_start() が記述されていれば長時間放っておいてもセッションは継続することを確認しました。

フレームを使えない場合、Javascript などでセッションを継続するためのアクセスを行うという方法もあると思います。

さすがに、この対処を行った後は、セッション切れの問題はほぼなくなりました。それでも、一時的に回旋を切ってから別の IP でセッションを継続させるようなケースには対処できないようですが・・・。

( 2003.03.30 追加 )

[PHP-users 14375] Re: セッションと戻るボタンとセキュリティとの投稿で、session.gc_maxlifetime についての触れられていました。

gcプロセスがsession.gc_maxlifetime秒経過したセッション情報を無効にするので、gcが起動しないとセッションは無効になりません。

session.gc_maxlifetime で設定した時間が経過するとセッションデータがごみとして見なされるのではなく、gc(ガーベージコレクション) が発生する確率である、session.gc_probability で設定した値の確率で gc プロセスが起動し、session.gc_maxlifetime で設定した時間が経過したセッション情報を無効にするということのようです。

つまり、セッション情報は、最後にアクセスした時間から、session.gc_maxlifetime で設定した時間が経過した上で、gc プロセスが起動すると、削除されるということになります。もし、長時間が経過したとしても、gc プロセスが起動していない場合、セッションは残り続けることになります。

>>セキュリティ関係

*FreeBSD

セキュリティアナウンスが出ています。OpenSSL のアナウンスでは、修正が入り、2回目のアナウンスがありました。また、日本語訳も出ています。

>>気になったニュースなど

▲ 目次へ戻る


更新履歴

2004.05.03

PHP のセッション関連について記述に追記。

2003.04.07

誤字の修正。内容の変更はありません。

2003.04.06

2003/03/23 の FreeBSD のセキュリティ勧告に、日本語訳のリンクを追加、セキュリティ関係の PHP の部分に追記を行いました。

2003.03.30

3月30日分を追加。2003/03/02 の PHP のセッションについての部分に追記を行いました。

2003.03.23

3月23日分を追加。

2003.03.16

3月16日分を追加。PHP のセッションについての部分に結果報告と追記を行いました。

2003.03.09

3月9日分を追加。PHP のセッションについての間違いの修正と、追記を行いました。

2003.03.02

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

▲ 目次へ戻る

LastUpdate: 2004-05-03 | HOME