co3k.org

脆弱性の概要

本題に入る前に、主に 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 付のアドバイザリを投稿

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

この脆弱性が本当に修正され、 JVN と Secunia から本件についての情報が公開された後、 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]

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

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

ということで、このエントリでは、 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]	もともと意図したところは「研究」の指す範囲よりも広い。