アカウント名:
パスワード:
脆弱性関連情報のコーディネーションにおいては、脆弱性発見者からの報告内容をコーディネーションを行なう調整機関が見て正しそうだと判断すれば脆弱性と判定する仕組みになっていて、報告者以外の環境での再現が要件になっていない。
発見者から報告された脆弱性情報は、影響を受ける製品の開発者に報告される。開発者の環境で再現した場合にはパッチなどの対策が作られる。この場合、発見者以外の環境での再現が確認されており、脆弱性情報の信頼性は高い。
開発者の環境で再現しなかった場合や開発者が脆弱性でないと主張した場合には、調整機関が脆弱性かどうかを判断する。このとき、追加の検証は要件になっておらず、調整機関が「脆弱性がありそうだ」と机上で判断すれば、その脆弱性があるものとして扱える仕組みになっている。このとき、報告者以外の環境で再現することを誰も検証していないまま、脆弱性情報が公表される。つまり、報告者からの情報が間違いであったとしても調整機関に「正しそうだ」と思われれば脆弱性として扱われる。発見者は匿名でも報告でき、誤報告に対するペナルティは無いので、それらしい情報をデッチあげればいくらでも脆弱性を捏造できる。
誤報や悪意によって報告された実在しない脆弱性であっても、開発者は検証や対策などの対応を要求され、対応コストが発生する。開発者の環境で再現しない場合や開発者が脆弱性情報でないと判断した場合には、報告者の報告内容が脆弱性でないことの証明がベンダに求められ、さらなるコストが発生する。誤報は善意であっても悪意であっても開発者に大きなダメージを与える。疑わしければ何でも報告したほうが良いという誤報上等の考えは開発者に大きな負担を強いることになる。
今回のトピックのケースでは、どういう経緯で誤報になったのかは不明だけれど、後の検証で誤りだとわかったということだから、脆弱性情報の公表までに検証は行なわれていなかったということではないかと思う。
脆弱性情報ハンドリングでは、発見者以外の環境での検証が要件になっていなので、誤報は避けられないし、悪意のある報告者によっていくらでも悪用できる仕組みになっている。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
もともと誤報は避けられない仕組み (スコア:2, 興味深い)
脆弱性関連情報のコーディネーションにおいては、
脆弱性発見者からの報告内容をコーディネーションを行なう調整機関が見て正しそうだと判断すれば脆弱性と判定する仕組みになっていて、
報告者以外の環境での再現が要件になっていない。
発見者から報告された脆弱性情報は、影響を受ける製品の開発者に報告される。
開発者の環境で再現した場合にはパッチなどの対策が作られる。
この場合、発見者以外の環境での再現が確認されており、脆弱性情報の信頼性は高い。
開発者の環境で再現しなかった場合や開発者が脆弱性でないと主張した場合には、
調整機関が脆弱性かどうかを判断する。このとき、追加の検証は要件になっておらず、
調整機関が「脆弱性がありそうだ」と机上で判断すれば、その脆弱性があるものとして扱える仕組みになっている。
このとき、報告者以外の環境で再現することを誰も検証していないまま、脆弱性情報が公表される。
つまり、報告者からの情報が間違いであったとしても調整機関に「正しそうだ」と思われれば脆弱性として扱われる。
発見者は匿名でも報告でき、誤報告に対するペナルティは無いので、それらしい情報をデッチあげればいくらでも脆弱性を捏造できる。
誤報や悪意によって報告された実在しない脆弱性であっても、開発者は検証や対策などの対応を要求され、対応コストが発生する。
開発者の環境で再現しない場合や開発者が脆弱性情報でないと判断した場合には、
報告者の報告内容が脆弱性でないことの証明がベンダに求められ、さらなるコストが発生する。
誤報は善意であっても悪意であっても開発者に大きなダメージを与える。
疑わしければ何でも報告したほうが良いという誤報上等の考えは開発者に大きな負担を強いることになる。
今回のトピックのケースでは、どういう経緯で誤報になったのかは不明だけれど、後の検証で誤りだとわかったということだから、
脆弱性情報の公表までに検証は行なわれていなかったということではないかと思う。
脆弱性情報ハンドリングでは、発見者以外の環境での検証が要件になっていなので、誤報は避けられないし、
悪意のある報告者によっていくらでも悪用できる仕組みになっている。