不適切な脆弱性情報ハンドリングが生んだ WordPress プラグイン cforms II のゼロデイ脆弱性

2012/02/15、 JVN から JVN#35256978: cforms II におけるクロスサイトスクリプティングの脆弱性 が公開されました。これはクレジットされているとおり、海老原と、同僚の渡辺優也君が勤務中に発見した脆弱性です。

脆弱性自体はどこにでもあるような普通の XSS ですが、実はこの脆弱性、 2010 年 10 月に exploit コードが公開され、それから 1 年 4 ヶ月後の 2012 年 2 月まで修正版が提供されていなかったものです。

このような危険な状態が長期間続いていたのには、様々な理由があります。ここでは、その説明と、どうすれば事態が防げたかということについて検討したいと思います。

脆弱性の概要

本題に入る前に、主に cforms II のユーザ向けに脆弱性自体の概要についてざっくり説明します。前述のとおり、未修正の状態で exploit コードが公開されたままになっていたため、ユーザの方は早急にアップデートをおこなうべきです。

この脆弱性は、特定のリクエストパラメータに含まれる、悪意のあるコンテンツがレスポンスに反映されるタイプの XSS 脆弱性 (いわゆる「反射型」) であり、被害者にリクエストを送信させさえすれば攻撃が成立してしまいます。攻撃者はログインユーザである必要がありません。

脅威について検討すると、まず、一般に説明されるように、以下の二点の存在が考えられます ( 『安全なウェブサイトの作り方』 第 5 版 p.22 より一部引用、要約)。

  • 本物サイト上に偽ページが表示されてしまうことによるフィッシング (phishing)
  • セッション ID が含まれる cookie を窃用されることによるセッションハイジャック

また、これは WordPress プラグインの XSS 脆弱性ですので、次の脅威の存在について検討する必要があります。

  • テーマ編集機能等を悪用した任意 PHP コード実行

WordPress は、テーマ機能を備えています。「テーマ」とは、レイアウトやページ部品など、 HTML 部品を出力する PHP スクリプトをディレクトリに集めたものです。必要に応じて、管理インターフェースから使用するテーマを選択することができます。

ところが、 WordPress にはこのテーマに含まれる PHP スクリプトをウェブインターフェース上から編集する機能が存在します。この PHP スクリプトがウェブサーバから書き込み可能である場合、攻撃者は XSS 脆弱性を悪用して管理者の cookie を窃用したのち、テーマ編集機能を利用し、テーマに含まれる PHP スクリプトに悪意のある PHP コードを含むことが可能ですので、注意が必要です。 (プラグインにも同様の編集機能はありますが、こちらはテーマと違い、書き込み可能にしているケースは少ないのではないでしょうか)

発見の経緯と誤情報

事の発端は、海老原が業務中にある自社サイトを訪れた際に、 WordPress とプラグインのバージョンが古いままになっていたのを見つけたことでした。

Secunia に掲載されている情報から、それらのバージョンに既知の脆弱性が存在することを確認し、使いやすそうな exploit が載っていた cforms II の XSS 脆弱性 (CVE-2010-3977) のアドバイザリ を説得材料として、そのサイトを新しく管理することになった渡辺君に対してバージョンアップを促しました。 [1]

ところが、渡辺君の確認作業によって、 なぜかバージョンアップ後にも exploit が機能してしまい、脆弱性が修正されていないことが明らかになりました

しかし、海老原が参照した Secunia のアドバイザリには、以下のように「v11.6 に上げることで解決する」旨が記されていました。

SOLUTION:
Update to version 11.6.1 or later.

[SA42006] WordPress cformsII Plugin "rs" and "rsargs" Script Insertion V および アドバイザリの Google キャッシュのキャプチャ

この情報を元に、 cforms II のチェンジログをたどり、 v11.6 でおこなわれた変更を確認すると、次のような記載が見つかりました。

*) other: plugged a potential (but unlikely to be exploited) security hole

—cforms II v11.6 の ____HISTORY.txt より引用

「悪用できそうにない (unlikely to be exploited)」? なにがなんだかわかりません。そこで、 v11.5 - v.11.6 間 [2] でおこなわれた修正を確認することにしました:

--- cforms-v11.5/lib_ajax.php       2009-09-18 10:29:06.000000000 +0900
+++ cforms-v11.6.1/lib_ajax.php     2010-09-22 07:41:54.000000000 +0900
@@ -627,16 +627,16 @@
            ###  always modified
            header ("Cache-Control: no-cache, must-revalidate");  ###  HTTP/1.1
            header ("Pragma: no-cache");                          ###  HTTP/1.0
-                   $func_name = $_GET["rs"];
+                   $func_name = sajax_sanitize( $_GET["rs"] );
            if (! empty($_GET["rsargs"]))
-                           $args = $_GET["rsargs"];
+                           $args = sajax_sanitize( $_GET["rsargs"] );
            else
                $args = array();
        }
        else {
-                   $func_name = $_POST["rs"];
+                   $func_name = sajax_sanitize( $_POST["rs"] );
            if (! empty($_POST["rsargs"]))
-                           $args = $_POST["rsargs"];
+                           $args = sajax_sanitize( $_POST["rsargs"] );
            else
                $args = array();
        }
@@ -651,6 +651,14 @@
        exit;
    }

+   ### sanitize
+   function sajax_sanitize($t) {
+           //$t = preg_replace('/\s/', '', $t);
+           $t = str_replace('<php', '', $t);
+           $t = str_replace('<?', '', $t);
+           return $t;
+   }
+
    ###  javascript escape a value
    function sajax_esc($val)
    {

開いた口がふさがりません。どこをどう見ても XSS 脆弱性の修正には見えませんよね。

なんとなく、任意 PHP コード実行の脆弱性に対処したつもりっぽい差分に見受けられますが、(このコードが有効に働く場面があったとして)そのような脆弱性は存在していませんし、当然、これでは XSS に対してまったくの無力です。

ということで、この CVE-2010-3977 の XSS 脆弱性への対処が当時の最新版 (v12.2) においてもおこなわれていないことを確認し、 2011/12/16 に IPA の脆弱性窓口への届出をおこない、 4 営業日後の 2011/12/22 に取り扱い開始、そして 2012/2/13 に修正版リリース [3] [4] がおこなわれ、 2012/2/15 に JVN で告知されることになりました。 (日付はすべて日本標準時)

報告者への事情聴取結果

この事態に気がついたとき、以下のような出来事が起こっていたのではないかと予想していました。

  1. 発見者が XSS 脆弱性の情報を開発者に通知
  2. 開発者はその XSS 脆弱性の情報を誤読し、 PHP コード実行の指摘だと勘違い
  3. 「そんな脆弱性ないのになあ」と訝りながら、とりあえずの修正を施した v11.6 をリリース
  4. 実際には脆弱性が修正されていないことを確認せずに、報告者は脆弱性情報を各所に通知し、 Bugtraq と full-disclosure に exploit 付のアドバイザリを投稿

しかし、脆弱性情報が公開された経緯については、どうもこの想像とは違っていたようでした。

この脆弱性が本当に修正され、 JVNSecunia から本件についての情報が公開された後、 Bugtraq および full-disclosure で、 元の報告者に対して質問を浴びせ 、何がおこったのかを確認したところによると、

Actually, the developer reply was:

(拙訳: 実は、開発者の返答は、)

"No one else ever complained about this problem and we have millions of users, so we are not fixing it"

(拙訳: 「数万のユーザを抱えているが、この問題について苦情を受けたことはないので、修正しないことにする」)

Full Disclosure: Re: Fwd: 0-DAY XSS of cforms II is now fixed after a year and four months (was Re: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977)

おそらく開発者は報告者の言う意味がわからずに "we are not fixing it" と言ったものの、「やっぱり一応やるだけやっておくか」と気変わりして、先述の無意味な修正を施したのでしょう。

報告者はこの問題が「修正」されたことには海老原の指摘まで気づかなかったようです。つまり、 Secunia が提示していた事実と異なる解決方法は、報告者によって提供されたものではありえず、単に Secunia 自身の責任による誤情報だったようです。

そうして、開発者の修正拒否を受け、 (「修正」版が提供されたことは知らないまま) 報告者は公開に踏み切りました。その理由として以下が説明されています。

I always coordinated vulnerabilities I disclose, but in case the developer decides that millions of users never reported and thus, the issue is not really a problem, I just go ahead and publish so the users can decide what to do. This is an open-source project, so any user that is security-aware could apply a patch themselves.

(拙訳: 私は調整の上で脆弱性を公開しているが、このケースでは、数万のユーザからの報告がなかったからといって、開発者はこれが問題ではないと決めつけたため、私はただ、ユーザが自分で何をするかを決められるよう、公開に踏み切っただけだ。これはオープンソースプロジェクトであり、セキュリティに関心のあるユーザはパッチを自分たちで適用することができる)

Full Disclosure: Re: Fwd: 0-DAY XSS of cforms II is now fixed after a year and four months (was Re: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977)

果たして、この行動に問題はなかったと言えるでしょうか。

各者の問題点と改善策

これまでの各者の行動や言動を振り返り、問題だったと思われる点、および改善策について検討していきます。

なお、ここで検討する以外にも、開発者の行動については、以下のようによくないと思われる点がいくつか見られました。

  • 脆弱性情報の告知がリリースノートに限られている。これは 『情報セキュリティ早期警戒パートナーシップガイドライン』 の「付録 5 ソフトウェア製品開発者による脆弱性対策情報の公表マニュアル」において望ましくない公表例として掲載されている典型例 [5]
  • 脆弱性修正のみの差分を入手することが難しい [6]
  • (それなりの規模の OSS を除いて、用意していないことのほうが多いのだが) 脆弱性の報告窓口が用意されていない [7]

これらの事項については、今回の問題に直接の影響を与えているわけではないので、詳しくは触れないことにします。

[開発者]ぞんざいな初期対応

報告者によると、開発者に対して「exploit コード付きで報告した ( I sent to the developer a complete advisory, including the exploit code. )」ということなので、それを見るなり試すなりすれば、 XSS 脆弱性であることや、どういう修正をおこなう必要があるかは想像できるはずで、間違っても先に示したような修正にはなりません。

にもかかわらず現実にあのような意味不明な修正となってしまった原因としては、 XSS についておそらく理解していなかったか、報告を適当に流し読みした可能性があります。 exploit も当然試していなかったのでしょう。

これはいただけません。

公開ソフトウェアの開発者として、不明瞭な内容の質問やバグ (?) 報告を日常的に受け取っているであろうことは想像に難くありません [8] ので、まったく気持ちがわからないでもないのですが……報告の内容がよくわからないのであれば、質問を返すなど、理解をするための努力をおこなうことが必要だと思います。

もちろんこれは普通のバグ報告においても言えることですが、悪用の危険があるセキュリティ脆弱性であればなおさらです。特に脆弱性報告の場合、無下にされたり、対応が極端に遅かったりすると、修正前に情報が公開されてしまう可能性があります。すべて順調に事が運んだ場合に比べると危険にさらされるユーザが増えることになりますが、報告者としては、ぐずぐずしている間に脆弱性を悪用されてしまわないよう、危険を被るユーザが一定数出ることは承知の上で情報を公開しているはずなので、一概に悪いことであるとは言えません。

脆弱性報告に対する真偽や修正の必要性の判断は、通常のバグ報告以上に慎重かつ迅速におこなわれるべきで、間違っても今回のような対応をするべきではありません。

[報告者]脆弱性報告が適切でなかったおそれ

報告者の行動についても見てみます。

まず、報告者がどのように脆弱性を報告したのかが気になるところです。 この点について質問したのですが 、いまのところ返答は得られていません。実際に内容を確認しないことには断言できませんが、報告に不足があった可能性が考えられます。

開発者が修正の必要性を感じず、かつ PHP コード実行の脆弱性と誤解されたということは——たとえば、脅威など、脆弱性自体の一般的な説明に漏れがあったのでしょう。

海老原の提示した脆弱性レポートでは、以下の点に触れています。

  • 脆弱性の種類
  • 脆弱性の脅威
  • 再現方法
  • 脆弱な箇所と理由
  • 現在の状況 (v11.6 での修正が適切でなかったこと、 exploit コードが公開されていることなど)
  • 修正方法の案

このレポートでは漏れていましたが、脆弱性を確認したバージョンも含める必要のある情報だと思います。

ちなみに、 IPA の脆弱性届出窓口に届出をおこなう際、報告は 規定の様式 に従っている必要があります。その様式に含まれる要素として以下があります。

  • 脆弱性を確認したソフトウエア等に関する情報
  • 脆弱性の種類
  • 再現手順
  • 再現の状況(再現性についての設問)
  • 脆弱性により発生しうる脅威
  • 回避策
  • 検証コード

JPCERT/CC が開発者に連絡する内容がどのようなものかについては知らないのですが、おそらく届出内容に基づいたレポートを作成することになるでしょうから、海老原の提示したレポートと内容としては近いものになるのでしょう。 [9]

報告の受け取り手が必ずしも Web アプリケーションセキュリティに関する一般的な知識があるとは限りません [10] から、海老原の脆弱性レポート (+ 確認バージョン) と IPA の様式の両方に共通して存在する要素については漏らさず記載するのが望ましいと思います。 [11]

開発者に脆弱性を報告する際のガイドライン的なものがあれば有用だと思うのですが、存在しないんでしょうかね……。提出するレポートについては OVAL とか参考になるかなと思って軽く調べましたが、これを使って書いても要件にあうものにはならないっぽい気がします。

[報告者]公開したアドバイザリの内容が不明瞭

報告者が Bugtraq や full-disclosure に公開したアドバイザリの内容が不明瞭であるのも、大きな問題であると考えています。

I never said the bug was patched...

(拙訳: 私はこのバグが修正されたとは言っていないんだけど……)

Full Disclosure: Re: Fwd: 0-DAY XSS of cforms II is now fixed after a year and four months (was Re: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977)

ということですが、 Full Disclosure: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977 を読んでわかるとおり、彼は 「この脆弱性が修正されていない」とも言っていません

アドバイザリの内容を要約すると以下のようになります (Cross Site Scripting であることはタイトルでしか説明されていません)。

  • v11.5 で問題を確認したが、他のバージョンにも影響があるだろう
  • lib_ajax.php が作成するデータは POST リクエストによって作られるが、 rsrsargs パラメータは検証されていないために、コードを挿入することが可能である
  • exploit コード
  • クレジット

先述したように、ユーザが適切な行動をおこなえるように情報公開に踏み切ったということで、その行動理念自体は立派だと思うのですが、このアドバイザリがその理念に則ったものであると言えるかどうか疑問です。

この件においては、「修正されていない」というステータスを示すことがきわめて重要です。その情報がなければ、ユーザはアップデートさえしていれば問題ないと受け取るでしょう。 Secunia の誤情報もその点を明確にしなかったことから来ていると考えられます。

2012/02/27 に full-disclosure で公開された、 Webglimpse というプロダクトのブルートフォース攻撃および XSS 脆弱性に関するポストにおいては、以下のような説明がなされています。

Developers of Webglimpse were informed as this time, as four previous times, but they ignored all of the warnings and haven't fixed all these holes (at least officially).

(拙訳: Webglimpse の開発者は今回と、それ以前に 4 回ほど連絡を受けているのだが、彼らはすべての警告を無視し、かつ、これらの欠陥はすべて修正されていない (少なくとも表立っては))

full-disclosure を購読している Webglimpse の利用者は、この文を読み、自らが影響を受ける脆弱性について、なにがしかのアクションを起こすことができるでしょう。しかし、 cforms II の件では、あのアドバイザリを見ただけでは、その必要があるかどうかがわかりません。

Secunia などのセキュリティ関連機関が掲載する誤情報

今回の件について、 Secunia は「v11.6 にバージョンアップすれば解決する」との誤情報を流しました。現在は修正されているので、 Google キャッシュのキャプチャ画像を以下に提示します。

SA42006 の修正前情報のキャプチャ

おそらく、

  • CVE では v11.5 が脆弱であると説明されている
  • cforms II v11.6 がリリースされている (し、 "plugged a potential ... security hole" という記述がチェンジログにある)

などの点からそのように推測したのでしょう。筋の悪い推測であるとは思いませんが、実際にはハズレでした。このように確たるソースのない情報が掲載されうるとなると、もうどう対処していいのかわからないです。

現に海老原は、この Secunia の情報を見て、 cforms II のバージョンを上げるべきであると判断しました。そのとき、 Bugtraq に行って報告者のアドバイザリ (と exploit) を見たのは偶然でしかなく、危うく修正されていないことを見逃すところでした。

この手の誤情報といえば、先日の日記『 勝手に訂正: 「PHP における SQL インジェクション攻撃を行われる脆弱性 (JVNDB-2012-001388)」 』で指摘した、 PHP の開発中バージョンと一部のディストリビューションの配布するパッケージでしか存在しなかったバグが、さもリリース済みの各バージョンに存在する問題であるかのように、 CVE を含む複数のサイトが告知した問題が個人的には記憶に新しいです。こちらは脆弱でないバージョンが脆弱扱いされていたというもので、今回の問題とは逆ですね。

この PHP の一件のように、CVE の時点で間違われるとどうしようもないのですが……ジャストアイディアですが、たとえば、 JVN iPedia などで脆弱性に関する検証レポート (JPCERT/CC によるものでもいいし、有志からのものでもいい) を掲載するというのはどうでしょうか。現状のように JVN で公表された情報の再編だったり、海外の記事の翻訳だったりするだけ (もちろん日本の状況にあわせて内容や CVSS スコアは調整しているでしょうけど) というのも芸がないですし、その種の検証情報が参照しやすい形で示されていれば、情報の価値も高まるし、よいのではないでしょうか。

その「セキュリティ」は誰がために

ということで、このエントリでは、 1 年 4 ヶ月も放置された cforms II の不幸な脆弱性を通して、報告への対応方法、情報公開の在り方などについて検討しました。

ところで、海老原は Full Disclosure: 0-DAY XSS of cforms II is now fixed after a year and four months (was Re: cforms WordPress Plugin Cross Site Scripting Vulnerability - CVE-2010-3977) のなかで、 "ALL SECURITY RESEARCHERS" [12] に対して以下のような問いをおこないました。

For what do you research security? What is your "security"? To protect people from threat? Or throw people into crisis?

(あなたはなんのためにセキュリティを研究 [13] しているのか? あなたにとっての「セキュリティ」とはなにか? 人々を脅威から救うためのもの? それとも人々を危機に陥れるためのもの?)

Do you recognize effects of your halfway job like this case?

(今回のケースのような雑な仕事がどういう影響をおよぼすか認識しているのか?)

Please reconsider this.

(どうかもう一度考えてみてください)

これに対する報告者の返答が以下になります。既に引用した文も含まれていますが、再掲します。

We have a responsibility with the users. If the user is not aware that a vulnerability exists and is ignored by the vendor, he will never have the power to decide.

(拙訳: 我々はユーザに関して責任がある。もしベンダが無視した脆弱性の存在についてユーザが気づいていない場合、ユーザは決定権を持ち得ないことになる)

Informing and sharing information is the responsibility of the researchers. I always coordinated vulnerabilities I disclose, but in case the developer decides that millions of users never reported and thus, the issue is not really a problem, I just go ahead and publish so the users can decide what to do. This is an open-source project, so any user that is security-aware could apply a patch themselves.

(拙訳: 情報を通知、共有することが研究者にとっての責任だ。私は調整の上で脆弱性を公開しているが、このケースでは、数万のユーザからの報告がなかったからといって、開発者はこれが問題ではないと決めつけたため、私はただ、ユーザが自分で何をするかを決められるよう、公開に踏み切っただけだ。これはオープンソースプロジェクトであり、セキュリティに関心のあるユーザはパッチを自分たちで適用することができる)

海老原としては、この報告者の意見に賛同しないわけではありません。必ずしも修正前の脆弱性の情報を公開するべきではないと考えているわけでもありません。単純に、できるだけ多くの人を救える方法をその時々で選択するのがよいと考えています。

今回の件では、最初から開発者に脆弱性を修正してもらえれば、より多くのユーザが幸せになれるはずでした。まずそこを目指すように努力するべきで、一度不適切な返答を得たからといって、開発者からの修正が望めないと判断してしまうのは、いささか早計に過ぎるのではないかと思います。

仮に開発者に修正させるのが難しかったとして、広く世間に情報を公開するのはよい行動でしょう。しかしその目的はなんでしょうか? 「ユーザが適切な行動をおこなえるように」? であれば、ユーザが行動するために充分な情報を提供する必要があるはずで、その点をおろそかにしている限り非難されてしかるべきです。自分が誰を相手に情報を公開するのかを見失ってはいけません。

先ほどの "ALL SECURITY RESEARCHERS" に対する問いは自分自身への問いでもあります。海老原は職業としてセキュリティを専門としているわけでも、セキュリティ関連のポストに就いているわけでもありません。しかし、セキュリティ関連の情報を収集し、業務上必要なものを社内にシェアするくらいのことはやっていたりますし、仕事でおこなわれる諸々について、セキュリティの観点からいろいろ口を挟んだりもしています。それはいったい何のためなのか——利用者の利益を保護するためなのか、それとも単に自らの知的好奇心を満たすためなのか——忘れないように、常に適切な行動をしていきたいものです。

[1]WordPress 等のバージョンアップを怠っていたことについて、渡辺君に責任はないことを念のため明確にしておきます。
[2]「修正」がおこなわれたのは v11.6 ですが、この「修正」によりエンバグしたために、開発者は v11.6.1 をリリースしました。 v11.6.1 はそのエンバグの対処しかおこなわれていないため、この記事では基本的に v11.6 を「修正」済みバージョンとしてみなすことにします。
[3]取り扱い開始から修正まで時間が掛かっていますが、これは開発者の責任ではなく、 このようなこと があったからです。
[4]修正箇所になぜか ## Kousuke Ebihara という小っ恥ずかしいコメントがありますが、これは海老原が書いたコメントではないことを念のため明言しておきます。できれば取り除いてもらいたいのですが、どう言ったものか悩んでそのままにしてあります。時が経てばそのうち消えるのではないでしょうか……
[5]

「望ましくない公表の例 (2)」です。

望ましくない理由として、以下のように説明されています。

新バージョンのリリース情報が、一般的な機能改善だけを目的としたものか、脆弱性修正を含むかを、利用者には容易に判別できません。

—『情報セキュリティ早期警戒パートナーシップガイドライン』 第 7 版 p.33

[6]ソースコードが zip アーカイブでしか配布されておらず、バージョン管理ツールのリポジトリ (ソースコードツリー) なども公開されていません。脆弱性単体の修正パッチも提供されていません。脆弱性修正のみのリリースなどがおこなわれているわけでもないため、ユーザは、脆弱性の対処に最低限必要な差分のみを適用して急場をしのぐという対応をとることが難しくなります。
[7]

『情報セキュリティ早期警戒パートナーシップガイドライン』 では、 JPCERT/CC との情報交換をおこなうための窓口を設けておくことを推奨しています。が、 JPCERT/CC との連絡用のみならず、セキュリティ上の問題の報告を受け付ける窓口としてなんらかの手段を用意、明示しておいた方がいいように思います。

cforms II が公開されている http://www.deliciousdays.com/ というサイトは、 cforms II の開発者のみによって運営されているサイトではありませんでした。 About の説明を見るに、開発者は技術的な支援をしているだけで、サイトの内容にはノータッチなのでしょう。

おそらく、そのために、 Contact には以下の一文が記されています。

You should refrain from contacting us at all, if…

(略)

  • you have a CFORMS related question (see here instead)

ところが、今回、 JPCERT/CC はこのページに記載されている連絡先にコンタクトをとり、「製品開発者から返答がないが引き続き連絡を試みている」などとのたまっていたのです。しかし、わざわざ断りを入れていることから、 cforms II に関する質問はフィルタリングされてしまい、読まれてすらいない可能性が充分に考えられます。これでは連絡のつけようがないでしょう。

まあこれについては単に JPCERT/CC が悪いって話なのですが、セキュリティ上の問題の連絡窓口さえ明示してあれば、こういう事故も防げてみんなハッピーだなと思う次第です。

ちなみに海老原が脆弱性を連絡する際は、以下のフローをたどることにしています。

  • 専用の窓口が見つかった場合はそこに連絡
  • 見つからなかった場合で、適切なハンドリングをしてくれそうな開発者に直接連絡する手段がある場合はそこに連絡 (特に OSS の場合)
  • これといった連絡手段も持っていない場合は、サポート用の窓口で適切な連絡先を訊ねる
[8]もちろん、どのような内容であれ、報告をいただけることは開発者にとって力となります。自らのソフトウェアが実用されていることを実感できる瞬間ですし、開発項目を決定する上での貴重な参考情報となるからです。
[9]

情報セキュリティ早期警戒パートナーシップに基づく脆弱性ハンドリングの下、製品開発者として対応をおこなったことはありますが、そのときは、

  • 報告者から直接連絡を受けていた
  • 迅速なリリースをおこないたかったので、報告者のアドバイスに基づき、 JPCERT/CC にこちらからコンタクトした

ということで、 JPCERT/CC の作成するレポートを受け取っていません。

[10]今回の場合、開発者は趣味でしかプログラミングをやっていなかった可能性さえあります。
[11]もちろん、一部要素を省略しても開発者に齟齬なく伝わることが明らかであれば問題ありませんが。
[12]Full Disclosure や Bugtraq なのでこのように書きましたが、「情報セキュリティに関わるすべての人」くらいが意図した意味合いです。
[13]もともと意図したところは「研究」の指す範囲よりも広い。
comments powered by Disqus

Recently entries