水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2004年のえび日記 > 2004年9月

2004年9月

2004年9月30日(木曜日)

迷走する教訓

Internet Watch にも「レンタルサーバー会社の安全性を認証する第三者機関を～ACCS久保田理事 (internet.watch.impress.co.jp)」というのが出ましたね。

まず、今回の事件において問題となった、セキュリティホールのあるCGIプログラムを提供していたレンタルサーバー会社の責任については「現在のところ、実行犯である元京都大学研究員に対する刑事裁判がまだ決着していないため、法的責任については現在も検討が続いている状態」と同氏は語った。

以上、レンタルサーバー会社の安全性を認証する第三者機関を～ACCS久保田理事 より

裁判が結着していないことがどう関係するのか良く分からないですね。office さんが何をしたかということは、ACCS・ファーストサーバが管理責任を果たしていたかどうかということとは関係ないのではないでしょうか。office さんがアクセスしていなかったら「管理責任を果たしていなかったことが発覚しなかった」可能性は高いですが、だからといって「管理責任を果たしていた」ということになるわけではないでしょう。

それにしても「実行犯」ですか。まだ無罪が推定されているはずなのに完全に犯人扱いしてしまっているのは……まあ、アクセスしたこと自体は争っていないわけですし、それはそれで仕方ないようにも思います。しかし、この言葉から「奴 (officeさん) さえいなければ何も問題なかったのに」というニュアンスがにじみ出てしまっているような気がするのですよね。

その上で「レンタルサーバーを借りるときに、きちんとそのサーバー会社がセキュリティに対して適切な体制を整えているかをチェックしないと、実際に情報が漏洩した際にそのサーバー会社を選んだことに対して委託元としての法的な管理責任を問われる可能性が高いが、個々の企業にはそのようなチェックを行なうノウハウがないために実質的にはチェックは困難」と指摘。「そのような問題を避けるためにも、サーバー会社が適切な管理を行なっているかどうかを認証する第三者のチェック機関が必要だ」と訴えた。

以上、レンタルサーバー会社の安全性を認証する第三者機関を～ACCS久保田理事 より

なんかこれも論点がずれているような気がしますね。今回の話は別にファーストサーバのサーバにパッチが当たっていなくて root を取られたというような話ではないわけで、

というような話でしょう。

※ちなみにファーストサーバには当時から SSL のサービスはありましたので、SSL を使っていなかったのはファーストサーバ側の都合によるものではなく ACCS 側が (おそらくは費用と相談して) 選択した結果です。

このような話になることを避けるのに必要なのは「サーバー会社が適切な管理を行なっているかどうかを認証する第三者のチェック機関」なのですか? 今回 ACCS はたまたまサーバ会社が配布していた CGI を使っていましたが、これがそうではなくて、そこらで配布されているフリーの CGI を使っていたらどうでしょう。あるいはヨセフアンドレオンが自作していたらどうでしょう。 サーバ会社を監査して何か意味があるのでしょうか。

本当に必要なのは CGI の監査であり、Web サイトの監査でしょう。ここには当然 Web サーバの監査は含まれるでしょうが、サーバ会社の監査は必要ないはずです。

しかし調査報告書 (www.askaccs.ne.jp)はけっこうまともなことを言っていたと思うのですが、どうして理事はこうなってしまうのでしょうね。

※あるいは、久保田理事は故意に論点をずらしているのかなぁ、という気もします。「セキュリティがショボイサーバ会社が悪いハッカーに侵入された」というようなイメージを植え付けられれば、「ACCS は悪くない、仕方ない」という印象を持ってもらえそうですし。

関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / ファーストサーバ

2004年9月29日(水曜日)

まだダメ

だいぶ直したつもりなのに未だに固まるようですね。申し訳ないです。

ひとまず、負荷が高そうな日記再読込を少なくしてみるテストということで、日記にコメントがついても日記のデータをリロードしなくなりました。これには当然副作用があって、日記側に表示されるコメント件数が更新されない可能性があります。

というわけでけっこう大きな問題があるのですが、しばらくの間これで様子を見ることにします。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

不正アクセス禁止法に抵触しない程度の簡単なバックドアって?

更新: 2004年10月7日

「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る (www.itmedia.co.jp)。

500円の金券を配って終わり、という話ではない。ACCSは情報漏えいした方々の十字架を背負い続けるしかない

以上、「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る より

これはあてつけなのかなぁ。いやまあ、全く同感なのですけれども。

続いて、ネット情報セキュリティ研究会（NIS）技術調査部長の萩原栄幸氏は、「国内のWebサイトは脆弱すぎる」と指摘する。「ある有名大学のWebサイトに、不正アクセス禁止法に抵触しない程度の簡単なバックドアを仕掛けたところ、大学の教職員名簿がまるごと見えてしまった」（萩原氏）。

以上、「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る より

ええと……「不正アクセス禁止法に抵触しない程度の簡単なバックドア」っていったい何でしょう。バックドアを仕掛けたという言葉が文字通りであるのなら、それが簡単であったかどうかは違法性とは全く関係ないような気がしますけれども。

逆に、個人的には ng_file=csvmail.cgi のほうこそ「不正アクセス禁止法に抵触しない程度の簡単な」アクセスだと思うのですよね。ただのディレクトリトラバーサルですし。

※もしこれがバックドアだとしても、仕掛けたのは office さんではなく morikawaさんでしょうし。:-)

※2004-10-07 追記: IT Media の上記引用部分は修正され、「検索エンジンを利用しただけで、ある有名大学のWebサイトから大学の教職員名簿がまるごと見えてしまった」と改められました。また NIS/ネット情報セキュリティ研究会 (www.e-secure.jp)にも訂正のコメントが出ています (shinさん情報ありがとうございます)。

関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件

2004年9月27日(月曜日)

復活ならず

「@nifty パレットのセキュリティホール まとめ」が復活するかと思いきや……。

残念。

関連する話題: セキュリティ / IPA

.NET Framework のバージョンを調べる

例の GDI+ の脆弱性は .NET Framework にも影響します。最新の SP では対応されていますので、.NET Framework 1.0 なら SP3 に、.NET Framework 1.1 なら SP1 にする必要があります。

クライアントマシンは速攻でアップグレードしていますのでまあ問題ないと思うわけですが、ふと、「そういえばサーバにちゃんと SP 入れたっけ」という疑問を抱きました。そもそも .NET Framework のバージョンをどうやって確認できるのか良く分からなかったのですが、「.NET Framework に Service Pack がインストールされているかどうかを確認する方法 (support.microsoft.com)」というドキュメントの存在を教えてもらって解決。いや、解決したと思ったのですが……。

……いったい、誰に予想することができたであろうか。これが長い戦いの始まりであるなどと……。

ドキュメントで示されている確認方法は 3つ。

どの方法を使って調べても、バージョンは 1.1.4322.573 でした。該当ドキュメントの表によれば、これは SP1 の当たっていない .NET Framework 1.1 のバージョンです。

これはマズイ、と思って慌てて SP1 を拾ってきて当てようとしたのですが……。

SP1 は既にインストールされているとか言われましたよっ!?

無視してインストールし、その後再びバージョンを確認するも 1.1.4322.573 のままで変化なし。

……というわけでお手上げなので私の .NET の師匠であるむらまさ先生 (www.fprog.org)に相談してみたのですが、mscorcfg.dll ではなく mscorlib.dll のバージョンを調べると、ちゃんと 1.1.4322.2032 になっていることが判明。考えてみれば Configuration 自体は GDI+ の脆弱性には関係なく、mscorlib.dll が更新されていれば問題ないはずです。

そんなわけで、これで問題なかろうという結論に達しました。

※しかしこの MS のドキュメントの立場はいったい……。というかまあ、単純に間違っていると思うわけですが。

関連する話題: セキュリティ / Microsoft / .NET

2004年9月24日(金曜日)

修正話

いちおう安定してきたような気がするので、詳細ログを取るのをやめました。

日記にコメントをつけたりするとちょっと微妙な動作になりますが、これは負荷が高いため。

日記にコメントをつけると、日記のデータファイルのタイムスタンプが更新されるようになっています。これは古いキャッシュが破棄するためなのですが、そのためだけに 2メガ超の日記データがリロードされてしまうので効率が悪いです。

うまくキャッシュだけ破棄したい感じなのですが、キャッシュの仕組み自体が微妙なので見直したいところではあります。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

2004年9月23日(木曜日)

セッション固定攻撃

IEやMozillaなどにセキュリティ・ホール，なりすましを許す可能性あり (itpro.nikkeibp.co.jp)……って非常に興味深い話ですね。Session Fixation (セッション固定) というのは知りませんでした。

当然、某所ではこれが楽勝でできるので再びピンチ。

そして、以前検証用に作成した「Cookie 操作装置」という CGI が攻撃に使用できる可能性があることが分かったので、とりあえず動作しないようにパーミッションを落としておきました。

関連する話題: セキュリティ

2004年9月22日(水曜日)

誕生日

今日はボブサップの 30歳の誕生日ですよ、なんと。

関連する話題: 出来事

2004年9月19日(日曜日)

まだまだ修正中

デッドロックの件ですが、lock をやめたら泥沼化した原因が発覚しました。単純に Moniter.TryEnter した後で Monitor.Exit するオブジェクトを間違えていたようです。

というわけでこれで直ったはずなのですが、本来ならそういう間違いをしていれば SynchronizationLockException という例外が throw されるはずなので、なにかもっと別の原因があるのかもしれません。あるいは System.Threading.Monitor じゃなくて System.Threading.ReaderWriterLock を使った方が良いのかもとかいろいろありますが、まあとりあえずこれで様子見ということで。

ついでに IT Media にリンクしない機能の実装を見直し。ついでに、他サイトへのリンクの後ろにはドメインを表示するようにしてみました。

あと hatomaru.dll のバグとしてはキャッシュ関係がおかしいことが判明していて、If-Modified-Since つきのリクエストに対して

という現象が発生することがあります。単純にステータスコードが逆になっているわけではなくて、正しく応答できる場合もあったりするので微妙です。この辺をちょっと見直そうかなと。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

2004年9月15日(水曜日)

まだ修正中

泥沼中。

とりあえず詳細なログを取って調べたところ、MessageParser が呼ばれるたびに ngurl.xml が更新されているとみなされて Table のロックとリロードが発生していることが判明。一回のセッションで 10回くらい呼ばれたりしているし……。

※ちなみに ngurl.xml というのは IT Media にリンクしない機能を追加したときに追加した、リンク禁止 URL のデータです。

これは単純なバグだったので修正しました。これでロック回数がメチャクチャ減ったはずなので、かなり死ににくくなったはず (しかもかなり速くなったはず)。ひょっとすると完全に直ったのかも。……直っているといいなぁ。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

わかりにくい MS04-028

MS04-028 (www.microsoft.com) ですが、Windows XP SP2 の環境で Windows Update すると、パッチが当たる……と思いきや、こんな不吉としか思えないダイアログが。

[このソフトウェアツールによって、実行中の Microsoft ソフトウェアにセキュリティ上の脆弱性が含まれている可能性のあることが検出されました。このセキュリティ上の脆弱性を修正するセキュリティ更新プログラムを Microsoft から入手することができます。 このセキュリティ上の脆弱性や、これに対処するために必要なセキュリティ更新プログラムに関する詳細情報を入手したいですか? [いいえ] をクリックした場合、今後この画面は表示されません。]

で、「はい」を押すと「JPEG 処理 (GDI+) のセキュリティ更新プログラムでコンピュータを更新する方法 (www.microsoft.com)」に遷移。

一瞬意味が分からなかったのですが、要するにこういうことみたいですね。

まあ Windows Update しただけでは Office が更新されないという問題がありますので、それに対するソリューションなのだろうと思いますが、ちょっと混乱しますね。出るメッセージをもう少し工夫できなかったのでしょうか。

そのリンク先のページも微妙で、

Windows XP または Windows Server 2003 以外の Windows のバージョンのユーザー

って、Windows XP のユーザは対象なのか対象でないのか分かりにくいです。たぶん「対象でない」が正解だと思いますが……。

まとめるとこんな感じ?

関連する話題: セキュリティ / Microsoft / Windows / Windows XP / Microsoft Office

2004年9月14日(火曜日)

ここぞという時のフロッピーディスク

スラッシュドットで「フロッピーはまだ必要か? (slashdot.jp)」という話が出ていますが、今日まさにフロッピーディスクのお世話になる出来事が。

Windows がセーフモード + コマンドプロンプトでしか起動しなくなり、ネットワークカードも CD-ROM ドライブも認識しない……などという事態になると、もうフロッピーディスクしかないでしょう。やっぱりいざというときにはまだ使えるのかな、という感じです。

関連する話題: 出来事

修正中

ロックに失敗したらロックを諦めて例外を出すようにしたところ、例外がぞろぞろと。そりゃそうか。

どうも spam 判定ルーチンで死んでいるようなので、その辺りをこちょこちょと修正してみました。これで直ると良いのですが、全く自信なし。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

2004年9月13日(月曜日)

脆弱性届出話

更新: 2004年11月4日

「脆弱性情報届出制度は運用しながら改善を～パネルディスカッション (internet.watch.impress.co.jp)」という話ですが、

9月8日時点でのユーザーからの届出件数は、ソフトウェア製品15件、Webアプリケーション71件の計86件に上っており、うちソフトウェア製品1件（ウイルスバスター・コーポレートエディション）、Webアプリケーション5件について脆弱性の修正が完了したとのこと。

以上、脆弱性情報届出制度は運用しながら改善を～パネルディスカッション より

前に報道されていた話と比較すると、

というところでしょうか。後者はたまたま今回は言っていないだけという可能性もありますが、何となくそうではない気がします。

当然というか問題点がいろいろ出ているようで、

そして、実際に制度を運用してみての感想として、早貸氏は「Webアプリケーションの場合、同一プログラムを複数のサイトで利用しているケースも少なくなく、そういったケースでは1つ脆弱性が見つかると、利用しているサイトの数だけ届出が来てしまう」「Webサイトに連絡先メールアドレスが書かれていても、管理者がそのアドレス宛のメールを読んでいないケースが多く、その場合は連絡先の電話番号などをいちいち調べなければならず面倒」などといった問題が出ていると語った。

以上、脆弱性情報届出制度は運用しながら改善を～パネルディスカッション より

まあ前者は「頑張ってください」というより他ないですね。端から見て何が届け出られているのか分からないので、どうしようもありません。ひょっとすると、某サーバ屋のアレなんかみんなして届け出ていたりするのかもしれない……と思ったりするわけですが、だからといって「きっと届け出られているだろうから良いだろう」というのも外れているかもしれないわけで。届出の情報が公開されない限り、重複は回避できないでしょう。

それから後者、これ、悲しいことにホントに連絡が取れない場合というのが実際にあるようですね。その場合は

本件、以下の理由により取扱いを終了することになりましたので、ご連絡いたします。

理由:

ウェブサイト運営者と連絡を取るために、当該サイトの脆弱性関連情報通知先に連絡をしましたが、期限内に返信がなかったため、ウェブサイト運営者と連絡が取れないものと判断しました。

……ということになるのですが、そうなったときに発見者はどうすれば良いのかというのが気になるところです。

密かに修正ということはもう期待できませんので、放置なのか、公開なのかの二択になると思いますが……当然、発見者は放置したくないから届け出ているわけでして……情報を公開したほうが良いものかどうか悩みます。

ただし、未解決の課題として、高木氏は「ベンダーによる脆弱性情報の告知方法のガイドラインができておらず、依然としていわゆる『ヤミ改修』のような行為が行なわれる危険性は減っていない」「脆弱性情報の発見者が情報を公開する場合のガイドラインがないため、同じような欠陥を防ぐために必要なフルディスクロージャーをいつになったら行なっていいのかがわからない」「そもそも『不正アクセス行為に当たらない脆弱性の発見方法』が明確化されておらず、どこまでの行為が許されるのかがわからない」といった問題を列挙した。

以上、脆弱性情報届出制度は運用しながら改善を～パネルディスカッション より

これは激しく同意で、私も一番気になっているところです。高木さんは流石に発見者の気持ちが良く分かっていらっしゃるようで。

しかし少なくとも最初の項目については、ガイドラインで「個人情報漏洩の時は情報を公開する必要がある」としているわけです。逆に言えば、それ以外の時は公開しなくて良いということですから、むしろ制度として「個人情報が漏洩していない場合はヤミ改修で良い」と認めているものだと理解していました。

もっとも、脆弱性によって個人情報が漏洩したかどうかというのは非常に微妙な部分があります。たとえば XSS などはセッション Cookie が盗まれてセッションハイジャックが行われる可能性があり、ログインによって個人情報が閲覧できるなら、個人情報漏洩の可能性もあるはずなのです。しかし実際にはロクな調査もしないで、「XSS がありましたが実害なし」などという判断をして終了ということになるケースがほとんどです。XSS が発覚しても、「この XSS は Cookie を使ってログインするサーバとは別のサーバのものなので、セッションハイジャックのおそれはありません」などと言ってもらえれば、それはそれで安心できると思うのですが……。

※そう言ってもらえない場合というのは、漏洩の可能性が否定できない = 情報公開しようねということになるはず。

ちなみに、届け出られて修正された脆弱性が 5件あるということですが、そのうちの 1件は某 ISP (ニフティではありません) の検索フォームの XSS です。これも全く情報公開された形跡がないですね。

あと、面白いと思ったのは脆弱性情報の届出状況のグラフ (internet.watch.impress.co.jp)。所々にぼこっと大きな山ができているのは、「貯めていたものを一気に吐き出した」人がいるからなのかなぁと思ったり。手持ちの脆弱性がたくさんある場合は、まとめて一度に送るでしょうからね。

※2004-11-04 追記:「某サーバ屋のアレ」は届け出てみたところ、普通に取り扱われて普通に修正の連絡を受けました。つまり、私以外の誰も届け出ていなかったものと思われ……「誰かが届け出ているだろう」という発想はしちゃ駄目みたいです。

関連する話題: セキュリティ / IPA / 思ったこと / 情報セキュリティ早期警戒パートナーシップ

2004年9月11日(土曜日)

デッドロック対策

デッドロックの原因は全く分かりません。クリティカルセクションの中で別のロックを要求しているような部分はないし……。

とあえず後ろ向きの対策として、ロックが必要なところで頑張りすぎないようにしてみました。

try{
    if(!Monitor.TryEnter(target, DataConst.LockInterval))
        throw new LockFailException("ロックに失敗しました。");

    ……クリティカルセクション……

} finally {
    Monitor.Exit(target);
}

こんな感じ。ちなみに LockFailException はカスタム例外です。DataConst.LockInterval の値は定数で、とりあえず 5000 にしてあります。5秒待ってロックできなかったら諦めて、例外を吐いて終了する感じ。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

2004年9月10日(金曜日)

デッドロック

掲示板書き込みのファイル保存処理を非同期にしたのですが、にもかかわらず ThreadAbortException が発生。CPU 使用率 100% で書き込み不能状態が続いていました。解決していたと思っていただけにがっくり。

こうなると、どこかでデッドロックが発生しているのではないかという疑いが濃厚です。というか、ロックの仕組みをあんまりちゃんと理解しないで lock ステートメントを使っているのが問題のような気がしますが。

……ともあれ、まだ「突然書けなくなる」現象は直っていないようです。ごめんなさい。

関連する話題: プログラミング / C# / えび日記 / hatomaru.dll

バカ日本地図が本に

ちょっと前の日記で触れた借力(ちゃくりき) (www.chakuriki.net)のバカ日本地図がやじうま Watch (internet.watch.impress.co.jp) で紹介されていますね。本が出た (www.amazon.co.jp)のだそうで。

関連する話題: 出来事

人狼戦術考

しつこく「人狼BBS (ninjinix.x0.com)」を読んでいます。参加する気はないので、考えたことなどを気楽にメモしておきます。

個人的にはこう思います。

私が村人なら、勝つためにまず以下の取り決めをします (ただしこれは狩人・共有者が存在する場合)。

この三点を徹底すれば、初日に一人だけ名乗り出た能力者は本物とみなすことができます。本人を白確定できますし、その能力も信用できるということになります。複数が名乗り出た場合も、その中に確実に本物が含まれていると考えることができます。

※個人的に霊能者の能力は役に立たないと思っているのですが、一人だけ名乗り出れば白確定ですので、手数を無駄にせずに白確定者を増やすことができます。複数名乗り出ればグレー濃厚ですので、どちらにしても意味はあります。また、後になって人狼や狂人が霊能者を騙ることを防ぐことができます (初日に名乗り出るしかなく、様子を見て臨機応変に名乗り出るかどうか決めるという選択肢がなくなる)。

その上で、こう運用します。

能力者が複数名乗り出た場合は、こう対処します。

※占い対象を公表すると人狼はそこに襲撃をかぶせるかもしれませんが、大きな問題はないと考えます。そのぶん既存の白確定者が喰われなくなるので、白確定者の数を維持できます。また、そもそも狼にヒットしている場合は喰われない訳ですし、狩人のファインプレーもあり得ます。

これで村人の勝率はかなり上がると思うのですが、占い師の偽物が出ないと人狼はほぼ負け確定になりますので、確実に偽占い師が登場します。そこで占い師の襲撃に成功したりすると、いつものような混乱の泥沼にはまっていく可能性があります。……というか、是非そうなって欲しいですね。やっぱり疑惑が疑惑を呼ぶ展開が面白いわけで……。

関連する話題: 思ったこと

2004年9月9日(木曜日)

人狼考

やっばり「人狼BBS (ninjinix.x0.com)」を読んでいます。

いろいろな村で、偽物の占い師よりも本物の占い師のほうが怪しく見える (と私には思える) のが興味深いです。

このゲームでは本物も偽物も等しく疑われるわけですが、本物が疑われると「本物なのに何で信じてくれないんだ!」と思ってしまうのでしょう。偽物は疑われても「当然疑われるだろうなぁ」と思って平然としていられます (しかも人狼なら相談相手もいます)。その結果、本物が感情的になって支離滅裂になり、偽物のほうが冷静でいるというのも十分にある話でしょう。

関連する話題: 思ったこと

2004年9月7日(火曜日)

人狼

むらまさ先生 (www.fprog.org)が紹介していた「人狼BBS (ninjinix.x0.com)」が面白くてはまっています。といっても参加しているわけではなくて、過去ログを読んでいるだけなのですが、それでも十分楽しめます。勉強になるし。

関連する話題: 出来事 / 思ったこと

2004年9月5日(日曜日)

StackOverflowException

HTML リファレンスを作っているのですが、System.StackOverflowException などという不吉な名前の例外が出てしまったりして。

種類 System.StackOverflowException の例外がスローされました。

ドキュメントを見るとこんな感じ。

保留状態のメソッド呼び出しが多くなりすぎ、実行スタックがオーバーフローした場合にスローされる例外。

まあそのまんまスタックオーバーフローなわけですが、再帰処理が無限ループしているのかしら。

関連する話題: プログラミング / C#

2004年9月4日(土曜日)

昆虫

なんとなく激写してみたので。

いや、ただのハエですけど。

関連する話題: 写真

2004年9月1日(水曜日)

SP2 でファイアウォールがリセット

私のマシンでは IIS の FTP サーバが動いていたりするのですが、何故かうまくファイルを転送できなくてちょっと戸惑いました。

いや、何故も何も原因は明らかに Windows ファイアウォールで、「例外」にポート 21 を指定したらすぐに解決したのですが……以前はファイアウォール有効かつ 21 と 80 と 8080 は穴開けという設定にしていたので、SP2 インストール後もそうなっているものとばかり思っていました。

以前の設定が引き継がれないというのも変な話ですが、よくよく考えると、元々ファイアウォールを使っていなかった人もデフォルトでファイアウォール有効になるような方針ですから、そのポリシーで行けばリセットされて当然なのかもしれません。

関連する話題: Microsoft / Windows / Windows XP

脆弱性届出は 67件

「IPAへのぜい弱性情報の届け出，開始から2カ月弱で67件に (itpro.nikkeibp.co.jp)」だそうですが、67件という数字には驚きました。思ったより少ないですね。

67件の内訳は，ソフトウエア製品のぜい弱性の届け出が14件，Webアプリケーションのぜい弱性の届け出が53件。Webアプリケーションのぜい弱性のうち，5件はすでにWebサイト運営者により修正が完了したか，もしくは修正されその確認が行われている段階という。

以上、IPAへのぜい弱性情報の届け出，開始から2カ月弱で67件に より

そして修正されたのが 5件、すなわち 1割ですか。まあ、届け出てから 1ヶ月以上経ってから取扱い開始になったりすることもあるようですので、もう少し気長に待ってみた方が良いのかも知れません。

関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ

最近の日記

関わった本など