[#39699] デーモン・プロセスの作り方 — "Mitsuyasu Ichimura" <mitsuyasu@...>

こんにちは、市村と申します。

27 messages 2004/06/01
[#39710] Re: デーモン・プロセスの作り方 — Masayoshi Takahashi <maki@...> 2004/06/01

高橋征義です。宣伝モードです(_o_)

[#39711] Re: デーモン・プロセスの作り方 — nobu.nakada@... 2004/06/01

なかだです。

[ruby-list:39779] Re: Hiki の脆弱性に関する注意喚起

From: Hidetoshi NAGAI <nagai@...>
Date: 2004-06-22 01:31:20 UTC
List: ruby-list #39779
永井@知能.九工大です.

From: SASADA Koichi <ko1@atdot.net>
Subject: [ruby-list:39777] Re: Hiki の脆弱性に関する注意喚起
Date: Tue, 22 Jun 2004 05:02:38 +0900
Message-ID: <20040622050223.9e240ef%ko1@atdot.net>
>  さて,今回の件の原因はどのようなものであったのかの開示はあり
> ませんでしょうか.次のような理由で原因の開示は必要だと考えます.

これはかなりデリケートな問題だと思います.

原因情報の開示はありがたいことではあるのですが,これは攻撃を意図
する者の作業を容易にしてしまうことにもなります.
つまりこの情報を開示することは,既存ユーザが移行の作業を行うため
の時間を短くしてしまう (緊急性が高まる) ことでもあるわけです.
運用の形態にも依るとは思いますが,都合上どうしてもすぐには作業で
きないという人は非常に困ります.

# セキュリティホールが見つかった場合には即座に対処するというのが
# 基本かつ当然であるということは,もちろん承知しています.

そういう意味で,最初の告知情報としては「どういう状況で,いかなる
被害を受けうるのか.対処方法は何か」というもので必要かつ十分では
ないかと考えます.

> 1. 今後,Hiki(もしくはHikiを一部利用しているようなソフトウェア)
>    を利用していくうえで,本当にその穴が埋まっているかの確認が第三
>    者からはできない(しにくい)

これはあまり理由にはならない気がします.これまで信用して使ってき
たわけですから,今回の修正作業を含め,これからも信用するのかどう
かという話ですよね?
もし信用できなくなったということであれば,どれだけの情報をもらっ
たところで「他にもあるかも」などと疑心暗鬼に陥るだけです.そのよ
うな状況なら,他のソフトウェアの利用を検討すべきでしょう.

> 2. Hiki のような有名なソフトに穴があったんだから,おれの xxx
>    にも同じような穴があるかもしんない.だけれど,その確認を
>    しようにもできない(しにくい)

これは確かに嬉しいのですが,上記の理由で今すぐに行うことは不適切
と考えます.少なくとも数週間は過ぎて,移行のトラブルの報告なども
発生せず,おおよその移行は完了した or 即座になにも考えずにシステ
ムだけを置き換えても問題は生じないと言えるほどの状況になってから
でも十分ですし,(もし開示するなら) そうすべきかと思います.
-- 
                                         永井 秀利 (九工大 知能情報)
                                             nagai@ai.kyutech.ac.jp


In This Thread