2008年01月22日
■ 脆弱性情報公表の自由 〜 コントロールを取り戻せ
今日は日弁連のシンポジウムでいつもの話をしてきた。明日からSCIS 2008に行く。
ところで、先週、次のブログエントリが話題になっていた。
- JPCERT/CCとの「脆弱性情報ハンドリング」の記録, DSAS開発者の部屋, 2008年1月17日
私は「脆弱性研究会」の委員を務めているから内部の人と思われるかもしれないが、現場の業務に携わっていないし、研究会の席でもJPCERT/CCが製品開発者とどんなやりとりをしているかはあまり聞かされないので、上のような事例の公表はたいへん参考になる。
これを拝見して気になったのが次の点だ。
JPCERT/CCが脆弱性情報をハンドリングすることの目的は「脆弱性関連情報を必要に応じて開示することで、脆弱性情報の悪用、または障害を引き起こす危険性を最小限に食い止める」ことにあるため、三者が足並みを揃えて向き合う「公表日」までは決して脆弱性の存在を漏らしてはならないということですね。さらに、公表日に一般へ開示する情報はあくまでも脆弱性の概要であり、悪用される可能性のある詳細な情報は公表日以降も機密として扱わなければならない、と先方から説明を受けました。
JPCERT/CCとの「脆弱性情報ハンドリング」の記録, DSAS開発者の部屋
誰がそんなことを言っているのか。そんなルールはどこにもない。本当にJPCERT/CCの担当者がそんなことを言っているなら問題だ。
JPCERT/CCの「JPCERT/CC脆弱性関連情報取り扱いガイドライン Ver 1.1」にもそんなことは書かれていない。このガイドラインで、情報を伏せておくように書かれているのは、「脆弱性情報の一般公表日」までの間についてだけだ。
(p.9)
●当該脆弱性関連情報を、情報の一般公表日までは第三者に漏えいしないように管理する
(p.10)
■脆弱性情報の一般公表日の設定に際して
冒頭の「覚えて頂きたい事項」にて記述した通り、脆弱性情報には一般公表日が設定されます。製品開発者の方は、対策情報なども含む脆弱性関連情報の公表に関して、一般公表日を遵守してください。
(p.16)
●情報漏洩の防止について
以下の事項に関する情報の漏洩に関して留意し、関連情報の管理の徹底をお願いします。
JPCERT/CC脆弱性関連情報取り扱いガイドライン Ver 1.1, JPCERT/CC
- 一般公表日前の脆弱性関連情報
- 一般公表前の一般公表日時(日付、時間など)
- 一般公表日前の脆弱性に関する製品の対策情報
そもそも、情報を公表するという行為をいかなる正当性をもって他人が止められるのか。このことは、この届出制度が設計された際に、表現の自由との関係として議論されている。2003年度の「脆弱性研究会」の報告書に次の通り書かれている。
(2) 脆弱性関連情報の開示
脆弱性関連情報の開示に関しては、憲法第２１条の表現の自由との係わりを検討する必要がある。
憲法第２１条第１項において、「集会、結社、および言論、出版その他一切の表現の自由は、これを保障する」と記されている。脆弱性関連情報に関しても、それ自体を発表することは、表現の自由として、憲法上、保護されるべき権利として保証される。
しかし、公共の福祉の下、ある程度の表現の自由が制限されるとの議論もあり、本文書はこの点を強調し、発見者に対する協力を求めているものといえる。さらには、脆弱性関連情報を公表することによる製品開発者に対する名誉毀損や信用毀損といった観点での注意も必要である。具体的には、以下の通りである。
1) 脆弱性についての調査・報告は、その率直な交換により、ソフトウエアやウェブアプリケーションシステムのセキュリティが結果として強化され、向上するという側面がある
2) しかしながら、その情報については、悪用というデメリットがあるので、その点についての十分な配慮がなされるべきであり、その一つの方向性を提唱するのが、この民間ガイドラインといえる
3) また、情報自体そのような性格をもつので、発見者についても脆弱性関連情報の管理について真摯な態度が必要とされる
4) そのような真摯な態度を保つ限り脆弱性関連情報についての調査・報告は、社会的に有用なものと考えられる
5) しかしながら、管理について真摯な態度を欠く場合については、上述の限りではなく、そのような真摯な態度を欠く場合の具体的な例として以下がある
a) 脆弱性関連情報の公表は、その情報の内容が真実と異なることを知っていた場合、あるいは、真実である場合であっても、特定人の名誉を毀損する意図で公表がなされ、かつ、公共の利益と無関係である場合には、刑法の名誉毀損罪に触れる可能性がある
b) 特定人の信用を毀損する意図で事実と異なる脆弱性関連情報を、事実と異なると認識して公表がなされる場合には、刑法の信用毀損罪に触れる可能性がある
c) 一般的に要求される程度の注意をもって調査・検証することをせずに脆弱性関連情報であるとして公表し、かつ、脆弱性関連情報の開示に起因して損害が発生した場合、損害賠償責任などの民事責任を追及される可能性がある
情報システム等の脆弱性情報の取扱いに関する研究会 報告書, 〜 脆弱性関連情報流通の枠組み構築に係る提言 〜, 情報処理推進機構, 2004年3月
議論では、発見者に対して一般公表日以降も脆弱性詳細情報を公表しないように求められないかという点も検討されたが、詳細情報を技術者間で共有することが技術の進歩を促すという正当性もあるのだから、表現の自由にも鑑みて、公表を控えるようお願いできるのはせいぜい（JVNでの）一般公表日までについてだというのが結論だった。
もっとも、これは脆弱性発見者に対しての話である。発見者は情報を自力で発見ないし入手したのであるから、その情報の取扱に他人が口を挟むことは表現の自由に関係する。では、製品開発者はどうだろうか。製品開発者は他人から情報提供を受けるわけであるから、情報の提供元が契約なりで情報非公表を要求するということはあり得る。
ここで注意したいのは、製品開発者が情報提供を受ける際、単一ベンダー固有の脆弱性なのか、複数ベンダーに及ぶ脆弱性なのかの違いである。
複数ベンダーに及ぶ脆弱性とは、たとえばJVN#1BF8D7AA「LDAP サーバの更新機能におけるバッファオーバーフローの脆弱性」などが典型例である。日立製作所が発見した脆弱性が、日立の製品のみならず、Hewlett-Packard社や Netscape Communications社の製品にも存在した（US-CERT VU#258905参照）という事例であり、発見者からの情報をJPCERT/CCは富士通や日本電気などにも提供し、「富士通: 該当製品なし」、「日本電気: 該当製品なし」という情報がJVNで告知されている（JVN#1BF8D7AA参照）。
このようなケースにおいて、「該当製品なし」となった富士通や日本電気が、もし脆弱性詳細情報を公表するようなことがあったら、それはいかがなものか。日立や Hewlett-Packardが暴露されたくないと考えているときに、富士通や日本電気が公表してしまったら、「なんでそんなところに情報を提供するんだ！」と、JPCERT/CCは叱られることになるだろう。「暴露されるなら情報提供しないほうがいい」ということになりかねず、結果として、上記の例の富士通や日本電気らが情報を入手する機会を逃すことになってしまう。
したがって、このような場合には、情報の非開示を約束した上で情報提供をすることになる。このことについて、「JPCERT/CC脆弱性関連情報取り扱いガイドライン」にも次の記述がある。
規約への合意と規約の遵守
JPCERT/CCの脆弱性情報ハンドリングの枠組みにご協力頂ける場合、JPCERT/CCが用意する「JPCERTコーディネーションセンター製品開発者リスト登録規約」に合意して頂く必要があります。製品開発者の皆様には、本枠組みへのご参加と共に、上記規約を遵守して頂きますようお願いします。
公表日一致の原則
一般公表前の脆弱性関連情報をハンドリングする場合、脆弱性関連情報が一般に、また悪意のある第三者に漏れると、対策方法が整わない時点で、悪意のあるコード(攻撃コード) が開発され、流通し、システムの脆弱性への攻撃が始まる可能性があります。結果としてシステムに危険が及ぶ事態を招く可能性があります。特に、複数の製品が影響を受ける脆弱性の場合には、関係者間で一定の足並みをそろえることが重要です。
また、関係者間で調整した一般公表日を待たずに、単独で情報を公表することは、他の製品の利用者を危険にさらす可能性があります。情報開示の時期を誤った場合(単独での一般公表日前の情報公開を行った場合)、当該開発者が今後の脆弱性関連情報のハンドリングから外されるだけでなく、日本全体として公表前の脆弱性関連情報をコーディネーションできなくなる最悪のケースも考えられます。
それは理解できる*1。だが、冒頭の「HttpLogger」のクロスサイトスクリプティング脆弱性のケースは、単一ベンダーの脆弱性であり、話が違う。
製品開発者には元々、自身の開発製品を如何様にもする自由がある。製品のサポートを中止するのも自由であるし、利用者に使用を中止するよう呼びかけるのも自由だ。自身の開発製品の脆弱性について、詳細な原因を公表するのも自由であろう。仮に、詳細な原因を公表したことが原因で悪用が始まって、それが利用者からの信頼を損ねることになったとしても、そのような判断をした製品開発者の責任である。場合によっては、詳細な原因を公表することが利用者の信頼を集めることだってあり得る。
「HttpLogger」のケースで言えば、この「製品」*2はブログエントリがその配布ページになっているくらいに「as isベース」で配布されているものだ。利用者も、開発者からのサポートが十分でないことを覚悟の上で使用しているはずのものだろう。このようなノリのソフトウェアに対して、JPCERT/CCゴトキが「公表日以降も機密として扱わなければならない」などと言ってきたら、私なら、公然と無視するか、ふざけるなと抗議するか、規約への同意を拒否するだろう。
ここで構造的な問題を感じるのは、技術者の常識と非技術者の「常識」との乖離である。技術者は、脆弱性の詳細情報が将来のセキュリティを向上させることを肌で知っている。非技術者にその感覚が備わっているか私は疑わしいと思っている。私の昔からの感触ではJPCERT/CCの連中に技術者の魂を感じない。事務屋としか感じない。だから、今回の「公表日以降も機密として扱わなければならない、と先方から説明を受けました。」という話は、いかにもありそうな話だと感じる。
これが事実なら深刻な問題だ。脆弱性の詳細情報をどう公表して共有していくべきかというのは、現状では、単純な一つのルールには定まらないケースバイケースの話であって、誰もが納得する合意が形成されているわけではない。今後様々なケースを積み重ねていくことによって、これから技術者達が培っていく文化である。
それなのに、事務屋が現れ、杓子定規に「公表日以降も機密として扱うのがルールだ」と振りかざしたら、一部の技術者は「へえそういうものなんだ」と従ってしまうかもしれない。これから醸成されていくはずの文化が、事務屋によって勝手に方向付けられてしまう。
だからこそ、脆弱性研究会は「公表を控えるようお願いできるのはせいぜい一般公表日までについてだ」という結論を出しているのであって、ガイドラインでもそうとしか書かれていない。つまり、「公表日以降も機密」など、定規すら存在していない。
事務屋なら事務屋らしく規約通り黙々と従いやがれ。と言いたい。（事実なら。）
これは以前から脆弱性研究会でも意見していることだが、JPCERT/CCの脆弱性ハンドリング手順は、複数ベンダー事案を中心に定められていて、単一ベンダー事案（複数ベンダー事案とは様々な点で性質が異なる）に対する配慮が足りていない。「JPCERT/CC脆弱性関連情報取り扱いガイドライン」をぼんやりと読むと、「規約への合意と規約の遵守」だとか「機密情報として取り扱え」だとかいう部分ばかりが目に付く。よく読むと、これらは複数ベンダー事案を前提に書かれた文章だ。
複数ベンダー事案のハンドリング手順は、単一ベンダー事案の場合に比べて格段に重くなる。それは仕方のないことだ。しかし、JPCERT/CCの文書はこれらが区別なく書かれているせいで、単一ベンダー事案であっても重たい手順であるかのように読まれてしまう。「自分の勝手で公開している独自ソフトなのに……。なんでこんな重い手順に従わないといけないのか」という感想は当然出てくるわけで、こんな紛らわしい文書を単一ベンダー事案の際に見せてはいけない。
ところで、これに関連して思い出したのが、昨年4月のAPOPの脆弱性（JVNDB-2007-000295およびJVN#19445002）の件だ。
これはどういう話だったかというと、まず、この件には2つの発見が含まれており、1つはフランスの暗号研究者が発見した件（JVNDB-2007-000295）――(1)で、もう1つは電通大とNTTの暗号研究者らが発見した件（JVN#19445002）――(2)である。(1)は国際会議Fast Software Encryption 2007で論文発表されている。そして(2)は同じ会議のrumpセッションで発表されている。
- Message Freedom in MD4 and MD5 Collisions: Application to APOP, Gaetan Leurent ――(1)
- Practical Password Recovery on an MD5 Challenge-Response such as APOP, Yu Sasaki, Go Yamamoto and Kazumaro Aoki ――(2)-1
- Extended APOP Password Recovery Attack, Yu Sasaki, Lei Wang, Kazuo Ohta, Noboru Kunihiro ――(2)-2
(2)は2本立てになっており、(2)-1は、(1)と同一の発見を自分達も独立に発見していたという報告であり、(2)-2は、それに加えた新たな発見により、(1)よりもさらに効率的にパスワード解読されてしまうという報告となっている。
ここで注目したいのは、(2)-1のプレゼン資料の以下の部分である。
何が書かれているかというと、1枚目では、「論文投稿締切日より前に発見したが、投稿しなかった。それはなぜか。セキュリティの問題に配慮したからだ。」ということを言っており、2枚目で「日本における脆弱性取扱はこうなっている」という話が書かれている。
これにはゾッとしなかった。
暗号研究の分野で脆弱性情報について学会発表するのは当然のことではないか。公表することの得失の議論は、おそらくアプリケーションソフトウェアの分野より古くから展開されていたはずであり、むしろ、アプリケーション分野の「full disclosure」の精神は、暗号研究分野で培われた考え方に倣ったものだと私は理解していた。
「日本ではIPAに届けることになっているので」と、rumpセッションで語られたとき、他の国々の暗号研究者らはどう思っただろうか。「日本は愚かな国だ」と思われたりしていないだろうかと心配になった。
2003年度に脆弱性届出制度が設計された際、脆弱性研究会では、プロトコルや暗号アルゴリズムの脆弱性をどう扱うかについても論点となった。その結論は報告書に次のように書かれている。
2.1.2.適用範囲
（略）したがって、脆弱性が発見される可能性や発見された場合の影響規模を踏まえ、脆弱性関連情報の流通において扱うべき対象としては、ソフトウエア製品及びウェブアプリケーションを採り上げることが適当である（脚注14: 暗号アルゴリズムの脆弱性については、総務省及び経済産業省により推進されている暗号技術評価プロジェクト「CRYPTREC」の活動において対応がなされていること、一般に理論的要素が極めて強いことから、本枠組みでは積極的には扱わないこととする。ただし、既に普及している暗号ツールに重大な影響が及ぶ脆弱性が発見された場合には、本枠組みを活用することも考えられる）。
情報システム等の脆弱性情報の取扱いに関する研究会 報告書, 〜 脆弱性関連情報流通の枠組み構築に係る提言 〜, 情報処理推進機構, 2004年3月
最終的に、経済産業省告示では適用範囲が次の通りに定められた。
�検ニ楷霆爐療�用範囲
本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が不特定多数の者に影響を及ぼし得るものに適用する。
１．日本国内で利用されているソフトウエア製品
（ソフトウエア製品において通信プロトコル等の仕様を実装した部分を含む。）２．主に日本国内からのアクセスが想定されているウェブサイトで稼働するウェブアプリケーション
ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号
ここで注意したいのは、この仕組みは、基本的には個々のソフトウェア製品の脆弱性について取り扱うものであって、プロトコルについて「含む」と書かれてはいるものの、それは実装上の脆弱性を指すものである（微妙な表現になっているがそう書かれているように読める）ということだ。
広範に使われている汎用の通信プロトコルの仕様自体、あるいは暗号アルゴリズムに脆弱性が見つかったときに、JPCERT/CC経由で製品開発者にだけ情報を提供（しかも守秘義務を課して）したところで、問題解決に至るとは思えないわけで、情報を技術者や研究者で共有して皆で解決策を探る以外にないだろう。それは従前よりそのように行われてきたことであるし、そのような発見をする人は、従前より自力で、適切な場への情報提供や公表を行って、問題解決を図ってきたと思う。
もし、この脆弱性取扱の仕組みが、技術者や研究者らの情報共有にブレーキをかけるものとなっているなら、不本意なことであると私は思う。
一般に、「公表を控える」という発想は際限なく広がりやすい。具体的に評価した根拠を挙げずとも「セキュリティのため」の一言で、「公表を控える」ことは正当化されやすい。公表により安全が向上する側面があってもだ。「勇気を持って行動すること」に比べたら「とりあえず何もしないでおくこと」は断然楽なのであって、「セキュリティのため公表を控える」というのは実に都合がよい。ましてや、IPAやJPCERT/CCがそういうことを言っているらしいということになれば、どんどん情報非公開の文化へと墜落していくだろう。
今回明るみに出た、「詳細な情報は公表日以降も機密として扱わなければならないと先方から説明を受けた」という話が事実であるなら、極めて罪作りな話である。やめてもらわなければならない。
できれば忘れたかったけれど、いつかは触れなければならなかった問題。
高木浩光＠自宅の日記 - 脆弱性情報公表の自由 〜 コントロールを取り戻せ
DSAS開発者の部屋:JPCERT/CCとの「脆弱性情報ハンドリング」の記録
- はてなブックマークコメント [s/togetter.com/li/1017284] ×6 : 5, 1 (2019-12-18)
- はてなブックマークコメント [togetter.com/li/1017284] ×26 (2016-08-30)
- https://www.google.co.jp ×10 (2015-10-23)
- fc2 blog [himag.blog26] ×108 : 102, 2, 2, 1, 1 (2013-08-01)
- はてなブックマークコメント ×32 : 23, 8, 1 (2011-07-04)
- ココログ [stressfulangel cocolog] ×14 : 9, 5 (2008-08-05)
- ココログ [dole moe] ×8 (2008-04-18)
- http://klab.klab.org:88/trac/general/wiki/LoggerIntro ×7 (2008-02-29)
- http://dsas.blog.klab.org/archives/51180647.html ×4 (2008-02-14)
- http://blog.fuktommy.com/1201331090 ×10 (2008-01-27)
- http://flu.if0.org/~maro/j/diary/0801.html ×10 (2008-01-26)
- http://flu.if0.org/~maro/j/diary/ ×55 (2008-01-25)
- セキュリティホールmemo ×784 : 713, 59, 11, 1 (2008-01-25)
- http://pooh.gr.jp/archive-1-2008-01.html ×85 (2008-01-24)
- http://dsas.blog.klab.org/archives/51170870.html ×138 (2008-01-24)
- はてなブックマークコメント [http://dsas.blog.klab.org/archives/51170870.html] ×13 (2008-01-23)
- キーワード不明 ×11 / コントロールを取り戻せ ×10 / 脆弱性情報 ×10 / 脆弱性 公表 ×4 / 脆弱性 情報 ×4 / 公表の自由 ×3 / HttpLogger ×2 / 高木浩光 脆弱性報告 ×2 / Noboru Kunihiro ×2 / 自由 コントロール ×2 / しょこたん ×2 / 脆弱性 情報公開 ×2 / 公表日一致の原則 ×2 / JVNDB ×2