解説
事の発端
発端となったのは公式フォーラム、8月27日の投稿。kosugiatkips氏より、「これらのプラグインには脆弱性がある。アンインストールすべき」と、特定のプラグインを名指しで脆弱性情報公開。
「先に作者に知らせるべきでは」との意見が上がったが、「コアじゃないから外した方が手っ取り早いし安全。アイテム(コンテンツ)が失われるわけではないから、なんとでもなる。外せないようなプラグイン入れるときは事前に注意深く検証すべき」と突っぱねる。しかし現実的には専門的な検証技術を持たないNucleusユーザ(CMSユーザ)も多い。外したくても外せない構成のサイトもあるだろう。このため議論はやや紛糾傾向で進行する。
経過
8/30 - 報告者であるkosugiatkips氏により、新トピック「セキュリティクイズ」が立てられる。意図が分かりにくいという指摘を受け、やや紛糾。
8/30 - 議論を通じて、専用MLの立ち上げが提案される。
8/31 - セキュリティ対策MLが立ち上げられ、活動を開始する。
9/1 - 藤咲氏のアイデア提案を受け、一連の脆弱性の多くを解決することを目的としたパッチプラグイン「NP_PatchBlogid(後にNP_0PatchBlogidに改名)」の開発が始まる。たたき台となるVer0.1をkosugiatkips氏が作成。
9/1 - 作者のjun氏自身により、今回の脆弱性報告に暫定的に対応したNP_MultiTags・NP_Analyze・NP_MultiBlogs・NP_SCをリリース。
9/2 - 大御所サイト「サイケデリックビビアン」、NP_TitleList・NP_ShowBlogs2.01_forSubCategories・NP_ShowBlogsByDateのセキュリティアップデート後にサイト閉鎖。前後して、今回明らかになった脆弱性に対する具体的な対応方針についてコミュニティより公式なアナウンスがリリースされる。対策MLではパッチプラグインの開発が進行。一日でも早い公開を目指し非常に活発なデバッグ作業が昼夜を問わず繰り広げられた。
9/4 - パッチプラグイン完成の見通しが立つ。公開手順などを巡り、開発と並行の上で意見交換が始まる。
9/5 - Kimitake氏より、コア側での対応提案。パッチプラグインとの併用推奨。自ら手を加えたglobalfunctions.phpをたたき台とし、チェック作業が始まる。
9/6 - 対策MLの成果として、プラグインとコアの脆弱性を解決するプラグイン(NP_0PatchBlogid)リリース。
9/6 - 同日。Kimitake氏より、修正版コアを非公式ながら「Nucleus 3.23 日本語版sp1」としてリリース。
9/8 - 同じくKimitake氏より、修正版コア「Nucleus 3.23 日本語版sp2」リリース。
9/10 - コミュニティとしては目先の対策については課題を処理できたものと判断し、次の段階である広報活動の具体化についての議論が開始される。この広報活動により、Nucleusに潜む脆弱性への注目を促し、リスクが身近なところにあることを広く意識させる狙いがあった。もちろんこれはNucleusに限った話ではない。また、すでにクラックを受けているサイトには今回のパッチプラグインは無力だ。この段階で安心せずに実態を洗い出そうという狙いもある。しかしデリケートかつ難度が高い話題であるため、この後10日近くに渡って議論は紆余曲折を続ける。
8/30 - 議論を通じて、専用MLの立ち上げが提案される。
8/31 - セキュリティ対策MLが立ち上げられ、活動を開始する。
9/1 - 藤咲氏のアイデア提案を受け、一連の脆弱性の多くを解決することを目的としたパッチプラグイン「NP_PatchBlogid(後にNP_0PatchBlogidに改名)」の開発が始まる。たたき台となるVer0.1をkosugiatkips氏が作成。
9/1 - 作者のjun氏自身により、今回の脆弱性報告に暫定的に対応したNP_MultiTags・NP_Analyze・NP_MultiBlogs・NP_SCをリリース。
9/2 - 大御所サイト「サイケデリックビビアン」、NP_TitleList・NP_ShowBlogs2.01_forSubCategories・NP_ShowBlogsByDateのセキュリティアップデート後にサイト閉鎖。前後して、今回明らかになった脆弱性に対する具体的な対応方針についてコミュニティより公式なアナウンスがリリースされる。対策MLではパッチプラグインの開発が進行。一日でも早い公開を目指し非常に活発なデバッグ作業が昼夜を問わず繰り広げられた。
9/4 - パッチプラグイン完成の見通しが立つ。公開手順などを巡り、開発と並行の上で意見交換が始まる。
9/5 - Kimitake氏より、コア側での対応提案。パッチプラグインとの併用推奨。自ら手を加えたglobalfunctions.phpをたたき台とし、チェック作業が始まる。
9/6 - 対策MLの成果として、プラグインとコアの脆弱性を解決するプラグイン(NP_0PatchBlogid)リリース。
9/6 - 同日。Kimitake氏より、修正版コアを非公式ながら「Nucleus 3.23 日本語版sp1」としてリリース。
9/8 - 同じくKimitake氏より、修正版コア「Nucleus 3.23 日本語版sp2」リリース。
9/10 - コミュニティとしては目先の対策については課題を処理できたものと判断し、次の段階である広報活動の具体化についての議論が開始される。この広報活動により、Nucleusに潜む脆弱性への注目を促し、リスクが身近なところにあることを広く意識させる狙いがあった。もちろんこれはNucleusに限った話ではない。また、すでにクラックを受けているサイトには今回のパッチプラグインは無力だ。この段階で安心せずに実態を洗い出そうという狙いもある。しかしデリケートかつ難度が高い話題であるため、この後10日近くに渡って議論は紆余曲折を続ける。
9/11 - Kimitake氏より、修正版コア「Nucleus 3.23 日本語版sp3」リリース。一部の怪しげなアクセスパターンを検知した際に、管理操作履歴に記録を残す仕様が追加された。
9/12 - 脆弱性に対応したNP_LatestWritebacks v1.1リリース。
9/18 - 脆弱性に対応した NP_IncludeEX 0.31 リリース。
9/20 - 脆弱性に対応したNP_ShowBlogs 2.6リリース。
9/12 - 脆弱性に対応したNP_LatestWritebacks v1.1リリース。
9/18 - 脆弱性に対応した NP_IncludeEX 0.31 リリース。
9/20 - 脆弱性に対応したNP_ShowBlogs 2.6リリース。
9/22 - しばらく間を置いてトラブル発生。大御所サイト「Nucleusの使い方」で配布されているプラグインはセキュリティアップデートを行なったはずだが、あるルートを通じて「まだ対応不足」と指摘を受けたらしい。作者としてはこれ以上の対応は難しいと判断、プラグインの配布を中止。解決されていない問題があるらしいという情報を受けて、混乱が広がり始めた。
9/23 - 2chで呼びかけ。誰かが裏ヌー(現ヌー配)立ち上げ。
9/24 - 「Nucleusの使い方」間もなくサイト閉鎖(9/24)。これを機にNucleus界への影響は一気に拡大。コミュニティ側で予定していた広報活動の準備はいったん保留とし、一連の件に関する事情説明を最優先課題とする。いったい何が起きたのか？
9/23 - 2chで呼びかけ。誰かが裏ヌー(現ヌー配)立ち上げ。
9/24 - 「Nucleusの使い方」間もなくサイト閉鎖(9/24)。これを機にNucleus界への影響は一気に拡大。コミュニティ側で予定していた広報活動の準備はいったん保留とし、一連の件に関する事情説明を最優先課題とする。いったい何が起きたのか？
9/24 - ２ちゃんねるのNucleusスレッドではWP（wordpress）へ移ります、さよなら」的なメッセージが増えつつあり。(※9/29日補足・一時的なものだったようで、現在は収束している)
9/25 - 脆弱性に対応した NP_MapBlog 0.81 をリリース。
9/25 - 脆弱性に対応した NP_NucBB 0.971 をリリース。
9/26 - 公式フォーラムに一般ユーザーによりNucleusの現状を憂えるトピックが立つ。
9/27 - Nucleusの使い方に、今回の件に関して、事の発端となった報告者とプラグイン作者の間に起きていたやり取りが掲載される。後述の「真偽不明の噂」は、少なくとも1件は実際に行われていた事実であると分かる。作者自らが明らかにしたところによると、脆弱性の発見の事実はないらしい。解決しかけていたことを思うと残念だ。どんなメールを送ってレンタルサーバ管理者に対応を迫ったのかしらないが、まったく余計なことをしてくれた。
9/27 - 脆弱性に対応した NP_IncludeEX 0.32 リリース。
9/27 - 脆弱性に対応した NP_LinkCounter 0.31 リリース。
9/28 - 問題提起を始めた本人のサイトも閉鎖。同日、まみおさんのサイトでプラグイン配布一時停止のお知らせ。今回は具体的なお膳立てのうえでのアナウンスであり、心強い。一刻も早くすべてのプラグインの再配布が実現し元の状態に戻ることを期待。なお現時点でもコミュニティからは公式な事情説明はないが、サボっている訳ではないことは名無しの傍観者である私が証言したい。
9/28 - 脆弱性に対応した NP_GoogleMaps 0.93 をリリース。
9/29 - ヌー配フォーラムのトピックにて Kitsune氏より
9/25 - 脆弱性に対応した NP_MapBlog 0.81 をリリース。
9/25 - 脆弱性に対応した NP_NucBB 0.971 をリリース。
9/26 - 公式フォーラムに一般ユーザーによりNucleusの現状を憂えるトピックが立つ。
9/27 - Nucleusの使い方に、今回の件に関して、事の発端となった報告者とプラグイン作者の間に起きていたやり取りが掲載される。後述の「真偽不明の噂」は、少なくとも1件は実際に行われていた事実であると分かる。作者自らが明らかにしたところによると、脆弱性の発見の事実はないらしい。解決しかけていたことを思うと残念だ。どんなメールを送ってレンタルサーバ管理者に対応を迫ったのかしらないが、まったく余計なことをしてくれた。
9/27 - 脆弱性に対応した NP_IncludeEX 0.32 リリース。
9/27 - 脆弱性に対応した NP_LinkCounter 0.31 リリース。
9/28 - 問題提起を始めた本人のサイトも閉鎖。同日、まみおさんのサイトでプラグイン配布一時停止のお知らせ。今回は具体的なお膳立てのうえでのアナウンスであり、心強い。一刻も早くすべてのプラグインの再配布が実現し元の状態に戻ることを期待。なお現時点でもコミュニティからは公式な事情説明はないが、サボっている訳ではないことは名無しの傍観者である私が証言したい。
9/28 - 脆弱性に対応した NP_GoogleMaps 0.93 をリリース。
9/29 - ヌー配フォーラムのトピックにて Kitsune氏より
junさんにお願いして、ご本人によるプラグイン最新修正版をまとめていただきました。これら最新版プラグインは、junさんご自身によって可能な限りのセキュリティ修正が施されてあります。今後ヌー配でセキュリティ修正を加えるため、何らかの形で公開したいと思います。
という内容のトピが立つ。現状「なんらかの形」を ヌー配フォーラム上で議論するべく 立てられたトピなので 実際のファイル自体はまだアップされていない。作者であるJun氏の意見も 「セキュリティ面での検証or改定」用というスタンスらしく、実際のサイトでの運用は勧めていない。
とにかく どういう形にせよ議論が進まないことには公開方法も決まらないので、多くの意見が寄せられる事を願うばかりだ。
そして同日、Nucleus(JP)フォーラム ： 一プラグイン作者の独り言に Jun氏自らの提案トピが立つ。ここでは詳しい内容はリンク先を参照されたし。この投稿は、事態がすでに快方に向かっていることを象徴するものとなった。
9/29 - 新プラグイン「NP_CheckPlugins」リリース。作者はKatsumi氏。プラグインのデバッグ作業を補佐するもので、グローバル変数・スーパーグローバル変数・SQLクエリをハイライト表示する。
9/30 - hsur氏作のプラグイン7点が一挙にセキュリティアップデート。
9/30 - 27日からjun氏のサイト「Nucleusの使い方」に掲載されていた、kosugiatkips氏との間で起きていたやりとりに関する記述がなくなる。もともと「当面の間公開」という前提だった。ほんの数日間の掲示ではあったが、裏事情を察するには十分だった。
9/30 - hsur氏作のプラグイン7点が一挙にセキュリティアップデート。
9/30 - 27日からjun氏のサイト「Nucleusの使い方」に掲載されていた、kosugiatkips氏との間で起きていたやりとりに関する記述がなくなる。もともと「当面の間公開」という前提だった。ほんの数日間の掲示ではあったが、裏事情を察するには十分だった。
真偽不明の噂
kosugiatkipsがプラグイン開発者のサイトのサーバー会社に通報し、閉鎖を余儀なくされたという噂がある。1件はjun氏。閉鎖には至ってないがもう1件ある。いずれ明らかになるだろうが、今ここでは伏せておく。
※[補足(9/29)] この件に関して、MLを通じてkosugiatkips氏本人からのコメントが得られた。jun氏以外の１件については「寝耳に水」とのこと。kosugiatkips氏は関わっていないと考えられる。
※[補足(9/29)] この件に関して、MLを通じてkosugiatkips氏本人からのコメントが得られた。jun氏以外の１件については「寝耳に水」とのこと。kosugiatkips氏は関わっていないと考えられる。
考察
この脆弱性情報勧告は、「道義的には正しい、がその手順的は誤っている」という正誤を同時に含んでいる。結果、プラグイン作者の大至急全対応という過負荷、開発モチベーションの低下を必然的にもたらし、プラグイン配布中止やサイトの閉鎖となった。建設的な議論の進め方を採るべきであったと思われるが実際の経過は、後の影響を想定できなかったかもしくは無視という、告発に近いものだ。突然起きた開発者損失という事態は、Nucleusユーザの失望と不安を大きく煽るものとなった。
ホワイトハッカー的な行為については、適切な方法で通知してくれれば、我々は必ず受け入れていたはずだ。他者の人権や社会的環境のことは視野になく、単純に“セキュリティ”のことしか考えることのできない幼稚な研究者こそ、ネットワーク社会で最も迷惑な存在ではないだろうか。
幼稚なセキュリティ研究者こそがネット社会で最も迷惑な存在より
ここで引用されているACCSの事件は「サイバーノーガード戦法」として知られる考え方の一つであるため、責任を報告者側に取らせたい関係者に熱狂的に受け入れられることとなった。
例）http://hiro.intlcafe.info/item/1804 (参照先の記事にコメントを書いた人物の必死ぶりが見て取れる）
現在においても、バグやセキュリティについてフォーラムやブログ、２ｃｈで語ることは
例）http://hiro.intlcafe.info/item/1804 (参照先の記事にコメントを書いた人物の必死ぶりが見て取れる）
現在においても、バグやセキュリティについてフォーラムやブログ、２ｃｈで語ることは
「脆弱性を公開し、それを通知してあわてふためくところを見て楽しむという側面が絶対にあったはずだ。」
というノーガード戦法の妄想の元に中傷の対象となり、あらん限りの暴言を吐くことが許容される雰囲気がNucleusの現状である。
Nucleusについて脆弱性を発見したならあたたかく見守っておくか、確証があるならIPAに届け出る等の対応が必要である。
Nucleusについて脆弱性を発見したならあたたかく見守っておくか、確証があるならIPAに届け出る等の対応が必要である。
現在ある課題
- 脆弱性のあるプラグインのセキュリティアップデート手順確立
（※現在使用中のサイトなどもあると思われるので、静か、かつ迅速に行う必要有り）
- ユーザー離れ、開発者離れの食い止め
（※悪い脆弱性情報勧告手順のため、Nucleus界への最悪影響となっている。
双方いなけりゃ存在意味なんて無いよ？開発進展なんて最低よ？）
双方いなけりゃ存在意味なんて無いよ？開発進展なんて最低よ？）
- 第２のk手順阻止の検討
今考えつくのは、
（１）ユーザーがプラグイン開発者へ簡単にメールを送れるようなメールフォームを、簡単に設置できるプラグイン、各国言語を選択可能版、プルダウン式で定型文など？またはこれの代替手段。
（２）プラグイン開発でのセキュリティに関する知識蓄積？
（１）ユーザーがプラグイン開発者へ簡単にメールを送れるようなメールフォームを、簡単に設置できるプラグイン、各国言語を選択可能版、プルダウン式で定型文など？またはこれの代替手段。
（２）プラグイン開発でのセキュリティに関する知識蓄積？
Nucleus 3.31 sp3に見るセキュリティ問題への対応
- アイテムが削除する権限を持たないはずのメンバーにより削除されてしまう危険性
- この問題の原因をソースレベルで解析してみると、システム特性が原因であることが見て取れる。
- アイテム管理に関するコード中、AutoDraft絡みで発生したが、権限チェックや動作フローがまとまっていない。
- 現状のコアでは開発者が神経質にチェックしても、アイテムの作成・変更・削除がどこでどのように行うというポリシーを読み取ることはできない。
つまり、行き当たりばったりというのが共通の意見となるだろう。アイテムの削除ができてしまうという脆弱性はほんの数行で発生したかのように見えるかもしれないが、実はこのようなシステム特性によるものと言える。
このような脆弱なシステム構造が即、Nucleusの問題点となるわけではないが、過ちに学ぶ姿勢は必要であろうと思われる。ところが、どんなに脆弱なシステム構造をとっていても、それらを指摘する声を封殺していれば、見掛け上は安全であるかのように振る舞うことができる。
それが、NucleusJPの考える安全性の実態であり、すべてであるともいえる。
- この問題の原因をソースレベルで解析してみると、システム特性が原因であることが見て取れる。
メンテナンス性を配慮した設計なら、アイテムに対する直接の実行の直前には必ずパラメーターチェック、セキュリティチェックをかける。ユーザー向けのエラーメッセージの育成は適切な場所で行う。という普通に行うべきことが行われていれば、このような脆弱性は発生する隙がない。
すでに動いているコアの修正を簡単に行うことはできないのは道理であるから、このことは技術的理解だけを行い、今後の糧とすることが望まれる。
すでに動いているコアの修正を簡単に行うことはできないのは道理であるから、このことは技術的理解だけを行い、今後の糧とすることが望まれる。
- メディアマネージャにおける脆弱性について
- 長い間凍結されていた、MEDIA.php media.phpだが、ようやく3.31sp3で改造がなされた。
それ以前のように、collection偽装によって、権限をまたいで任意のフォルダにアップロードできたり、といった問題点に対応したのだという。
しかし、アイテム削除に関する脆弱性で得たはずの教訓はまったく生かされていない。MEDIAクラスを作成しているということは、MEDIAクラス内でセキュリティ実装が行われるべきだが、メソッドの提供が行われているのみで、メディア追加の実行時にはチェックされていない。
media.phpというフロントエンドにcollectionチェックの実装を依存してしまっている。これでは、アイテム削除のときの脆弱性埋め込みと同じ現象の温床になってしまう。これは早急に対処すべきだろう。
また、MEDIAクラスのcollectionチェックには穴がある。権限のないフォルダを有効にしてしまう脆弱性は健在である。
- 長い間凍結されていた、MEDIA.php media.phpだが、ようやく3.31sp3で改造がなされた。
なぜこのようなソースが改訂版としてリリースされうるのか、その理由は知る由もない。 sp3は残念な結果に終わった。それだけは言えるだろう。
※この記事は常に適宜編集を求めています。help！
また、問題が一段落した後も、コアに同様のセキュリティホールが生まれた。一連の問題から何も学んでいないのだろう。
