アカウント名:
パスワード:
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
功名心だけでなく、利用者の安全のためにも公開が必要なんですよ。自分が見つけられたのだからクラッカーも(既に)見つけている可能性がある。だから修正パッチがあるなら適用すべきだけと、無いなら製品の利用を控えるなどの運用面での対策が必要になる。
運用面での対策は情報が届かなかった利用者には効果がないが、アンテナを張っている利用者の危険を減らすことが出来る。修正パッチは運用面での対策よりも広い対象に効果があり、デメリットの有る運用面での対策を必要としなくなる。すでに脆弱性が悪用されている可能性がある以上、どちらかの対策は一定日数内に実施される事が望ましい。修正パッチのほうが効果的だからできるだけ修正パッチを待つが、間に合わなければ運用面対策を公知する。#3486064が言うようないつまでも修正が適用されない状態を避けるためのプレッシャーとしても意味がある。
それと、発表者にネームバリューがあれば運用面での対策をより効果的に普及させる効果もある。それによって発表者の評価が上がれば、次のパッチが遅れた脆弱性においても運用面での対策を加速させられる。
一定日数で足切りしての脆弱性公開は、利用者にもメリットが有るんですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
脆弱性をわざわざ公開するやり方って (スコア:0)
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
Re:脆弱性をわざわざ公開するやり方って (スコア:0)
功名心だけでなく、利用者の安全のためにも公開が必要なんですよ。
自分が見つけられたのだからクラッカーも(既に)見つけている可能性がある。
だから修正パッチがあるなら適用すべきだけと、無いなら製品の利用を控えるなどの運用面での対策が必要になる。
運用面での対策は情報が届かなかった利用者には効果がないが、アンテナを張っている利用者の危険を減らすことが出来る。
修正パッチは運用面での対策よりも広い対象に効果があり、デメリットの有る運用面での対策を必要としなくなる。
すでに脆弱性が悪用されている可能性がある以上、どちらかの対策は一定日数内に実施される事が望ましい。
修正パッチのほうが効果的だからできるだけ修正パッチを待つが、間に合わなければ運用面対策を公知する。
#3486064が言うようないつまでも修正が適用されない状態を避けるためのプレッシャーとしても意味がある。
それと、発表者にネームバリューがあれば運用面での対策をより効果的に普及させる効果もある。
それによって発表者の評価が上がれば、次のパッチが遅れた脆弱性においても運用面での対策を加速させられる。
一定日数で足切りしての脆弱性公開は、利用者にもメリットが有るんですよ。