Twitter | Search | |
Ben Hawkes
Project Zero team lead
626
Tweets
326
Following
29,036
Followers
Tweets
Ben Hawkes Jun 29
Excited to welcome to Project Zero today! A keen viewer might have noticed that Ned was previously working with us on a 20% project, but now will be joining the team full time. Welcome, Ned!
Reply Retweet Like
Ben Hawkes retweeted
James Forshaw Jun 17
Released a short write up about the FF sandbox escape from last month. Includes details of how I was able to add a new feature to the Chromium sandbox to allow Mozilla to fix the issue without losing performance.
Reply Retweet Like
Ben Hawkes retweeted
Brandon Azad Jun 11
I've compiled a summary of every original public iOS kernel exploit from app context since iOS 10, describing the high-level exploit flow to get stable kernel read/write. The trends of how these exploits have evolved over time are quite interesting:
Reply Retweet Like
Ben Hawkes retweeted
Ivan Fratric Jun 4
Reply Retweet Like
Ben Hawkes May 23
When a pwnie just isn't enough -
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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]
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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).
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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?
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
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.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
8) CVE-2017-8759 - Code injection vulnerability in Microsoft's SOAP WSDL parser. Again, the preferred delivery mechanism was through Microsoft Office documents. This issue was originally exploited as a 0day by BlackOasis.
Reply Retweet Like
Ben Hawkes May 19
Replying to @benhawkes
7) CVE-2018-4878 - Use-after-free in Adobe Flash's MediaPlayer DRM Listener. This issue was originally exploited as a 0day by ScarCruft/APT37/Reaper. This issue was commonly exploited via Office documents (remember that Flash became sandboxed in Chrome in late 2016).
Reply Retweet Like