脆弱性情報データベースに登録された脆弱性、検証の結果誤りだったことが判明 9
ストーリー by hylom
これまた珍しい 部門より
これまた珍しい 部門より
2013年9月24日に脆弱性対策情報ポータルサイトJVNで公開された脆弱性情報JVNVU#99975381が、「正しくなかった」として10月7日に訂正されている。
問題となった脆弱性は、オンライン決済サービス「NETELLER」が提供している「NETELLER Direct」のPayment APIに関するもので、「HTTPリクエストの検証不備の脆弱性が存在します」というもの。しかし、検証の結果このレポートは正しくなかったそうだ。
もともと誤報は避けられない仕組み (スコア:2, 興味深い)
脆弱性関連情報のコーディネーションにおいては、
脆弱性発見者からの報告内容をコーディネーションを行なう調整機関が見て正しそうだと判断すれば脆弱性と判定する仕組みになっていて、
報告者以外の環境での再現が要件になっていない。
発見者から報告された脆弱性情報は、影響を受ける製品の開発者に報告される。
開発者の環境で再現した場合にはパッチなどの対策が作られる。
この場合、発見者以外の環境での再現が確認されており、脆弱性情報の信頼性は高い。
開発者の環境で再現しなかった場合や開発者が脆弱性でないと主張した場合には、
調整機関が脆弱性かどうかを判断する。このとき、追加の検証は要件になっておらず、
調整機関が「脆弱性がありそうだ」と机上で判断すれば、その脆弱性があるものとして扱える仕組みになっている。
このとき、報告者以外の環境で再現することを誰も検証していないまま、脆弱性情報が公表される。
つまり、報告者からの情報が間違いであったとしても調整機関に「正しそうだ」と思われれば脆弱性として扱われる。
発見者は匿名でも報告でき、誤報告に対するペナルティは無いので、それらしい情報をデッチあげればいくらでも脆弱性を捏造できる。
誤報や悪意によって報告された実在しない脆弱性であっても、開発者は検証や対策などの対応を要求され、対応コストが発生する。
開発者の環境で再現しない場合や開発者が脆弱性情報でないと判断した場合には、
報告者の報告内容が脆弱性でないことの証明がベンダに求められ、さらなるコストが発生する。
誤報は善意であっても悪意であっても開発者に大きなダメージを与える。
疑わしければ何でも報告したほうが良いという誤報上等の考えは開発者に大きな負担を強いることになる。
今回のトピックのケースでは、どういう経緯で誤報になったのかは不明だけれど、後の検証で誤りだとわかったということだから、
脆弱性情報の公表までに検証は行なわれていなかったということではないかと思う。
脆弱性情報ハンドリングでは、発見者以外の環境での検証が要件になっていなので、誤報は避けられないし、
悪意のある報告者によっていくらでも悪用できる仕組みになっている。
わかること (スコア:0)
・脆弱性レポートは真実か確認もされずに掲載されている。(速報性を重視？)
・検証は後からしているようで、間違った情報には間違っていた情報がわかる形で訂正される。
虚偽のレポートにより、信用問題などに発展しないだろうか？
Re:わかること (スコア:1)
虚偽のレポートにより、用問題などに発展しないだろうか？
バランス感覚でしょうね。
脆弱性によって、速報性を重視すべき場合もあるだろうし、時間をかけるべき場合もあるだろうし。
（ただ、脆弱性の種別を見誤るということはあるけど。例えば内部からのDoS可能性と思ってたら、外部からの乗っ取りが可能だったとか。）
発表される場や属性によっても、公式的・確定的事実として発表する内容もあれば、速報性重視・周知による多角的検証を促す内容もあるだろうし。
今回、2週間の猶予を持っても良かったのかといえば、決済サービスなのでそこまで猶予は無いだろうと思う。
とはいえJVNだからな、というのはる。
Re: (スコア:0)
速報性と信頼性を両立させるのは難しいなら並立させればいいと思う。
地震の規模みたいに速報(未検証)と確定(検証済み)のフラグを設定すればいいのでは？
Re: (スコア:0)
これだけで信用に足ると思えてしまうあたり、俺は色々と毒されているようだ。
JVNVUってことは (スコア:0)
CERT/CCのを日本語訳して出してるやつか
Re: (スコア:0)
だよね。
なんかもっともらしいコメントをつけてる人もいるけど、単に、
「CERT/CCが脆弱性としたからJVNも追随した」
「CERT/CCが誤りとして修正したからJVNも追随した」
ってだけのことなんじゃないかと。
むしろ (スコア:0)
Webアプリの脆弱性は開発元がこっそり直したり違うと言い張ったりしたらどうしようもないという事例だったりして。