LHAって終わり?問題の些細な側面の補足

UNLHA32.DLL作者による開発停止から、VectorによるLZH受付の停止まで色々とLHAに関する動きが続いている。

LHAが海外主体の製品で対応されにくいというのは、まあそうかなという気分もしなくもなく、Windowsでも日本独自の対応でLHAフォルダに対応している位な知名度なので、長年使っている愛着はあるけれど、ZIPにしたいというのならばそれはそれで止める理由も特にない。

ただ、番号体系等何か誤解しているんだろうなあ、というIPA他の対応について少々つっこみたい点があり、一応そっちの業界なもので多少なりとも補足してみる。

まず、UNLHA32.DLL作者の報告で「JVNに報告」とあるがこれは正確ではない。届出対象は「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示第235号）により設置された、「情報セキュリティ早期警戒パートナーシップ」であり、その受付窓口がIPAとなる。

パートナーシップとして見ると各種団体が関連しており、直接的な関連だけでも、IPA(受付・分析)、産総研(分析支援)、JPCERT/CC(製品関連調整)とある。図としてはあまり見つけられなかったが、情報セキュリティ白書2009の最終ページなどに詳しい。もちろん、この先にベンダ側がおり、ウェブ運営者、国内ベンダ、海外CERT、企業内CSIRT、個人、etc..が案件ごとに関連する。

話題となっている、JVNはJVNのサイトにあるようにJPCERT/CC, IPAの共同運営する公表用のポータルサイトである。そのため、「ベンダー，JVN / IPA 等共に」というのは、JVNが判断する主体ではないので、まあJPCERT/CC, IPA(他関与した関連団体)共に、という意味に受けとっておくのが良いのであろう。この仕組み、セキュリティ専門家ですら関わらない人はほとんど知らないので、仕方がないところではある。

不受理については不明。報告の仕方によっては脅威が出せずにCVSS基本値がつかないこともある。例えば「アンチウイルスソフトが圧縮ファイルを見逃す」とかそういう具体的な脅威があやふやな方向に該当してしまったのかもしれない^[1]。

ついでに、各種番号について。JVNの脆弱性レポートの読み方を読むとわかるのだが、「JVNVU#〜」というのは海外のCERT/CC, US-CERTから来た情報である。脆弱性早期警戒パートナーシップ経由は「JVN#」、よって受付基準が違っていても仕方がない。「CVE で採用された事案 (CVE-2010-0098) 」ともあるが、このCVEは単なる共通番号であり、発行しているMIRTEに脆弱性を受付る窓口があるわけではない。ベンダやCERTが発行しようと申請すれば普通につく。実際、VN-JP(脆弱性早期警戒パートナーシップ経由)で公表されたMovable Typeの問題はCVE-2010-1985がついている。

分野の違う人に正確に書けといっても無理なのはわかっているし、正確でなくとも趣旨は十分わかるんだけど、まあ一応気になったので。補足でした。

関連記事:

• 対策してもらえる脆弱性情報公開の仕方
• トークナイゼーションによるクレジットカードの保護
• Amazon でウェブ検査販売

1. この場合、「(一般的に)アンチウイルスソフトがウイルスを見逃すのは脆弱性か?」という「ユーザからすれば検知100%未満は脆弱性」「対応していないものに対応できないのは仕様通り」という論争問題になりかねないので、受理不受理がどっちに転んでもおかしくはない。 [↩]