what if in fact it takes longer than three months to fix? A number of the serious examples here took longer than that. Would you advocate 90-day disclosure for those too? https://en.wikipedia.org/wiki/Responsible_disclosure …
-
-
Replying to @charlesarthur @steely_glint
They can decline to fix bugs, schedule fixes for future versions in years to come, assign one developer or invest millions and assign dozens. Those are all valid options. It can take years to walk across the country or you can take a flight and be done in hours.
1 reply 0 retweets 0 likes -
I think your real question might be "shouldn't it be illegal to discuss/review/criticize commercial products without permission from the vendor?", and I don't think so. I certainly want to hear about design flaws in the products I use, whether the vendor likes it or not.
1 reply 0 retweets 2 likes -
Replying to @taviso @steely_glint
I can see the benefits of disclosure, eg if you have something where the company is clearly *refusing* to fix it and it’s very obvious (eg many IoT flaws). I’m certainly not suggesting making it illegal to discuss. That’s a bad idea. It’s about balancing risk from disclosure.
3 replies 0 retweets 0 likes -
Replying to @charlesarthur @taviso
But then you get into the situation where say Google ships a mitigation to it's workforce for an external private vuln it has found/knows about - or advises customers not to use a product for 'unspecified reasons' => Unlevel playing field.
1 reply 0 retweets 1 like -
Replying to @steely_glint @taviso
why do we want to give people who are looking to exploit vulnerabilities - which I think we can agree is a bad thing? - a level playing field?
1 reply 0 retweets 0 likes -
Replying to @charlesarthur
Other way around. I want as many people as possible to be protected. If you encourage indefinite private vulns, then only the finder and the bad guys can protect themselves - the rest of us are unwittingly vulnerable - when we could switch to a different product
1 reply 0 retweets 1 like -
Replying to @steely_glint
I’m not encouraging indefinite private vulns. I’m wondering whether we haven’t seen clear examples (https://en.wikipedia.org/wiki/Responsible_disclosure …) where it takes longer than an arbitrary 90 days to fix things. Or, I dunno, not release POCs? That could help ameliorate effects too.
2 replies 0 retweets 0 likes -
Replying to @charlesarthur @steely_glint
Firstly, 90 days isn't arbitrary, we're experienced engineers who understand software extremely well. Secondly, PoC are necessary for those of us who actually work in security. There's a reason why metasploit is widely used by security professionals, and it's nothing but PoCs.
1 reply 0 retweets 1 like -
Replying to @taviso @steely_glint
ok. (Is there a reference for how 90 days was arrived at?) And on the “this is gonna take longer than 90 days” examples cited in Wiki (DNS/Spectre/Meltdown)? What’s your views on that? Would you have disclosed them anyway?
1 reply 0 retweets 0 likes
Let's just leave it here, every tweet is just asking me to answer the same question that I've already answered. The answer hasn't changed.
-
-
Replying to @taviso @steely_glint
I literally can’t see where you’ve answered it! I’ve gone back and looked. It’s a simple question. Would you have disclosed DNS cache poisoning after 90 days, even if they hadn’t fixed it? Y/N and we can depart on good terms.
1 reply 0 retweets 0 likes -
Replying to @charlesarthur @steely_glint
Tavis Ormandy Retweeted Tavis Ormandy
Tavis Ormandy added,
Tavis OrmandyVerified account @tavisoReplying to @charlesarthur @steely_glintNo, I think three months is far too long to sit on information about dangerous product design flaws. This view isn't shared universally, some people believe it's best to trust the vendor to act in your best interests. Others prefer autonomy and want to make their own decisions.1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.