脆弱性届け出られ側のお話

2008年1月19日(土曜日)

脆弱性届け出られ側のお話

JPCERT/CCとの「脆弱性情報ハンドリング」の記録 (dsas.blog.klab.org)。興味深いです。

とりあえず、この制度の正式な名前は「情報セキュリティ早期警戒パートナーシップ」だと思うのですが、正しく呼ばれることはほとんど無いような気がしますね。名前が長い上に、いまいちピンと来ないからでしょうか……?

さらに、公表日に一般へ開示する情報はあくまでも脆弱性の概要であり、悪用される可能性のある詳細な情報は公表日以降も機密として扱わなければならない、と先方から説明を受けました。

あれ、そうなのですか? そういうルールだとしたら、届出側に対してもそういう説明があって良さそうなものですが、言われたことがないような……。

ともあれ、JVN の情報公開はイマイチな印象があります。たとえば、「JVN#29273468 QRcode Perl CGI & PHP scripts におけるサービス運用妨害の脆弱性 (jvn.jp)」なんてのがありますが、原理については「特定のリクエストによって」としか書かれていないので、何がどうなって DoS 状態になるのか良く分かりません。

ところで最近、私は仕事で開発中のアプリケーションに脆弱性が存在することに気づき、リリース前に対応することができました。実はこれ、JVN#29273468 の詳細を知っていたからこそ発見できたものです。しかし、私がその詳細を知っていたのは偶然に過ぎません。一般の人が JVN#29273468 を読んでも、同種の脆弱性の発見や防止に結びつけることは難しいでしょう。攻撃手法まできちんと理解していないと、脅威を正しく理解したり、防御策を考えたりするのは難しいと思います。

というわけで、対応が完了した脆弱性については、同種の脆弱性の再発を防ぐためにも積極的に詳細情報を公表して欲しいなぁ、と個人的には思っていますが、難しいですか……。

情報の公開時刻は各者間で完全に同期させるのではなく、開発者側が数時間先行し、その完了を確認してからJPCERT/CC側が追随するという考え方のようです。たしかに、対策方法の詳細がもっぱら開発者側の公開情報内に含まれることを考えると、不慮の事故等でJVN分の情報が先行して露出した場合の危険性は容易に想像ができます。

Trac の時なんかはずいぶんタイムラグができてしまって、よく分からないことになっていましたが。複数のベンダーに影響する場合は、情報公開時期のハンドリングが大変らしいですね。

※たとえば、「JVN#465742E4 Wiki クローンにおけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」は公開日が2005年5月19日となっているのですが、良く読んでいくと Hiki の修正版リリースは情報公開日より前の 5月17日になっていたりします。中の人の苦労が忍ばれますね……。

「脆弱性届け出られ側のお話」にコメントを書く

前(古い): Let's Note + Vista が死ぬ?
次(新しい): 届出件数2007Q4