9) CVE-2015-1641 - Type confusion in Microsoft Office's parsing of SmartTag elements. This issue was originally exploited as a 0day, but we don't have any attribution data available. For ASLR, the exploit used the fact that MSVCR71.DLL was loaded at a fixed address in Windows 7.
-
Show this thread
-
10) CVE-2018-7600 - This was a remote code execution vulnerability in Drupal, also known as Drupalgeddon. Attacker-controlled content could be evaluated as PHP. This issue was trivially exploitable, since attackers could call PHP's exec function with arbitrary parameters.
1 reply 1 retweet 21 likesShow this thread -
Out of the ten CVEs listed, six were originally exploited as 0day, and four were trivially exploitable (three logic bugs, and one target with no DEP/ASLR). What does this tell us?
3 replies 6 retweets 42 likesShow this thread -
Opportunistic attackers are either waiting for bugs that require no additional R&D (design flaws, logic bugs, other easily exploitable conditions), or waiting for fully developed and reliable exploits to become available (typically when a 0day is leaked or detected).
1 reply 10 retweets 55 likesShow this thread -
Importantly, attackers aren't using publicly disclosed security research in the same way that they used to, except when a bug is extraordinarily trivial to exploit. And the chances that we can stop attackers from learning about those bugs through patch analysis is very low.
3 replies 11 retweets 49 likesShow this thread -
Even if all security researchers globally stopped publishing technical data on their discoveries, and also agreed never to publish patch analysis or binary diffing results, attackers would still have a plentiful supply of exploits that were originally detected as 0day.
1 reply 13 retweets 53 likesShow this thread -
I'd quickly note that Project Zero has disclosed technical details for over 1700 bugs, and none of our issues are in the top 10. On the flip side, there is a huge defensive benefit from sharing data about how different attacks work and how to build structural defenses for them.
2 replies 7 retweets 66 likesShow this thread -
A lot of vendors have asked us to redact technical details from our bug reports at various points. I understand where this comes from -- fear of the unknown, fear that their users will be harmed, and fear of bad press for their product. Let's not make decisions based on fear.
1 reply 7 retweets 43 likesShow this thread -
Observable user harm is disproportionately coming from the fallout of 0day exploits being leaked/detected, and from a handful of trivially exploitable bugs. It's not coming from security researchers disclosing messaging app bugs, browser exploits, or kernel priv-escs.
1 reply 10 retweets 47 likesShow this thread -
These disclosures still have an important purpose: raising awareness about the capabilities of 0day exploits, teaching the next generation of researchers, driving change at vendors/OSS projects, motivating follow-up research/investment, etc.
1 reply 3 retweets 35 likesShow this thread
But it's very rare that a vulnerability disclosure meaningfully increases attacker capability, relative to their existing capability. And compared to silent fixes or non-disclosure, the net result of vulnerability disclosure is overwhelmingly better for defensive outcomes.
-
-
So on the sweeping claims of irresponsible disclosure, emotion-driven policy making, assumptions of bad faith. Let's talk about models, data, and forecasting instead. I think we can make some very good predictions about which CVEs are likely to cause significant user harm.
2 replies 6 retweets 34 likesShow this thread -
Finally, let's redirect some of that energy towards the attackers who develop and deploy (often recklessly deploy) 0day exploits, which leads to many years of unintended fallout and expensive cleanups after their exploits are leaked or discovered. The damage is enormous. [END]
3 replies 6 retweets 51 likesShow this thread
End of conversation
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.